nesdev.org

I've said in earlier posts how I thought it would be really cool if 2D systems were still being made, I thought it would be fun to think of outrageous ideas for a 2D system. I always thought the Neo Geo's sprite linking system was really cool, and I wondered if maybe you could take it a step further. You would have it to where you have one normal sprite, that has a register that says how many sprites after it it would use. Every sprite after the controller sprite has its x and y values added to the first one for something like hardware metasprites. The console would support sprite scaling, so you could have it to where the first sprite has a register that holds a number that gets added to the sprites position to find a center position for scaling, and it would automatically move all the sprites so that they are still linked together. This would also work for rotation. This example I gave probably doesn't make any sense from a hardware perspective, but it would still be cool. (To me, at least.)

The GBA was pretty "modern", then came the DS which added extended palettes.

If you excluded the DS' 3D engine (which you can easily do by ignoring it altogether), the DS actually makes for a mean 2D machine. If you were able to dedicate a system like it to 2D only, I'm sure you could easily have increased the sprite limit in VRAM/OAM. Though I still can't think of what I'd do beyond 128.

Anyway, some things I'd like to see in a 2D only system (in addition to what the GBA and DS already offer):

* More color SFX options. The GBA had something that affected green values for pixels (it's undocumented by Nintendo). It'd be interesting to have individual RGB intensity controls for trippy effects. It would also be nice to have some presets like filters, e.g. sepia, black and white, that sort of stuff. Sure you can just swap a bunch of palettes yourself, but that's more work to do.

* Individual Rotation/Scale parameters for sprites. The GBA and DS lack these; they can only be set for groups of sprites.

* Optional decimal based sprite coordinates.

* This is going to sound crazy, but it would be cool if you could just point to a memory location (in the hardware's fast RAM) for an OAM entry. When you want to change what your OAM looks like, just specify a different address. I'd use it to simplify animation routines, e.g. the first sprite in OAM could be animated by just increasing the address (assuming the data at the address is correct of course).

I was going to write a giant post, but my father said I had to go to the store, and when I came back, it logged me out and erased my message! I was going to say that when I said "modern", I meant like today modern. I was thinking about it running at 4K (but having it able to run at lower resolutions also) and maybe using 64x64 as a tile size instead of 8x8, because it would by about the size of one pixel on the NES or SNES. Here's a 64x64 black square on a 3840x2160 picture to show you the size.
(The size of the picture has been reduced, but it is still proportionally correct.)

Espozo wrote:I was going to say that when I said "modern", I meant like today modern.

So, basically any PC, minus the GPU's ability to render 3D. In that case, there's really not much to say. "Modern" systems today are less about things like hardware-based features (e.g. SNES Color Math/GBA SFX) and more about delivering on software and hardware specifications, in my opinion (Nintendo's system run contrary to this, however; they're very much about hw-based features). I can't really think of any "outrageous" ideas because you're pretty much not going to be limited unless you want to do something really ridiculous. I guess with today's hardware, nothing in the 2D realm seems "crazy" anymore. You just have the hardware resources to do (almost) whatever you want.

In light of your clarification, I guess just having a 2D system with things like OAM and BG maps built into its hardware would be more than enough. Consider that the 3DS lost these, so if you want to make your own 2D only game, you have to spend time to develop a system that recreates tile-based BGs, sprites, and all of that good stuff. I miss having the hardware itself deal with these things, but you do gain much more freedom (sprites can be whatever size you want, no more dealing with metasprites).

The only other thing I can say is pixel shaders.

Can we hide that gigantic image? It breaks the layout of the thread.

rainwarrior wrote:Can we hide that gigantic image? It breaks the layout of the thread.

Sorry about that. How do you hide the image though?

Shonumi wrote:in my opinion (Nintendo's system run contrary to this, however; they're very much about hw-based features). I can't really think of any "outrageous" ideas because you're pretty much not going to be limited unless you want to do something really ridiculous.

I guess that's why I always thought the Game Cube looked better than the original Xbox, even if it is supposedly less powerful. If I were to make a system, it would be something more like an extremely beefed up system from the 90's in that it is very based on hardware features. I can think of several ridiculous things, like not having BG layers and only relying on sprites, not unlike the Neo Geo. You would use 64x64 sized sprites and would make all the backgrounds by chaining sprites together. I'm sure 30 BG layers made out of sprites and several large explosions flying all over the screen at 4K would require some decently powerful hardware. All the sprites have access to rotation and scaling, and maybe could have sprites be 6bpp, 8bpp, 10bpp, or 12bpp. None of this would be difficult at all? Maybe I've underestimated modern hardware... At any rate, it could at least be Game Cube strength if it could handle it, but it would need a lot of memory to hold all the animation, if it doesn't use something like cartridges...

Espozo wrote:Sorry about that. How do you hide the image though?

Edit post and turn it into a link?

Well, the GC hardware is hardly modern though. It's old enough to fit some youngster's definition of "retro". You can easily buy an ARM device that will offer more hardware resources at a lower price (including inflation) GC level hardware is fairly outdated, although there are plenty of neat features the GC/Wii Flipper chip have (take a look at some of the articles on the Dolphin Emulator's website, .org not .com).

I think a lot of people overestimate how taxing 4K content really is. Even assuming a 24-bit RGB framebuffer, a 4K image will only occupy a fraction of VRAM if you throw even something like 512MB of memory at this theoretical system. 1GB has been common in many GPUs for a while now. You have a very large sandbox to play in if you're just doing 2D stuff. You'll probably even end up using less memory since the whole point of having tile-based graphics is to reuse elements frequently, when applicable. The CPU more than anything would be an issue if you started drawing thousands of sprites on screen. I'm thinking about all of those collision detections in something like a bullet-hell game. But there's always going to be a limit on how many objects any game's engine can handle. Today's GPUs, even some of Intel's IGPs and ones you find in mobile ARM platforms, just laugh at 4K if you take 3D rendering out of the equation.

If it really is going to be modern, it should let me use whatever USB controller I want, as long as it has enough buttons. Not related specifically to 2D systems, but it's always been an advantage PCs, Android consoles, and emulators had that I wish my 360 and PS3 had

Sik wrote:

Espozo wrote:Sorry about that. How do you hide the image though?

Edit post and turn it into a link?

I just shrunk the picture so it's only 20% its original size.

Shonumi wrote:Consider that the 3DS lost these, so if you want to make your own 2D only game, you have to spend time to develop a system that recreates tile-based BGs, sprites, and all of that good stuff.

Which isn't hard, given the existence of New Super Mario Bros. 2 and Super NES emulators for GP2X.

you do gain much more freedom (sprites can be whatever size you want, no more dealing with metasprites).

You might still need metasprites if you want to conserve texture memory. This would become especially important with 4K-class (3840x2160) output surfaces, which have two orders of magnitude more pixels than classic LD sprite systems such as Super NES, Genesis, and Neo Geo. And at that point, it might be useful to add support for Gouraud shading and Bezier clipping paths so you can render vector animations like SWF, SVG, and HTML 2D canvas. But someone would probably just abuse it to make 3D, at which point you're back to just making a 3D GPU.

Shonumi wrote:The CPU more than anything would be an issue if you started drawing thousands of sprites on screen. I'm thinking about all of those collision detections in something like a bullet-hell game.

I was thinking of 65,536 sprites, but they are only 64x64, which is roughly about 8x8 in size on the NES or SNES so tons and tons of them would be used to create BG layers, and almost all objects will be made of several of them. Maybe the sprite system should be less advanced in that sprites only have the option to be placed right or down from the controlling sprite like they are on a 64x64 pixel grid? You would have a register for how many sprites vertically you want and one for how many you want horizontally, so you could have things like 320 x 512 and 704 x 640.

tepples wrote:add support for Gouraud shading and Bezier clipping paths so you can render vector animations like SWF, SVG, and HTML 2D canvas. But someone would probably just abuse it to make 3D, at which point you're back to just making a 3D GPU.

That's exactly what I'm afraid of. I don't want to have each corners of sprites to be manipulated like the Sega Saturn either, because it will just end up being 3D like it was. The only thing I want is to have sprites rotated, and shrunk and expanded horizontally or vertically.

teeples wrote: Which isn't hard, given the existence of New Super Mario Bros. 2 and Super NES emulators for GP2X.

The level of difficulty isn't my main concern, just the fact that I need to make my own system at all. Doing that takes time, and it's not necessarily time I'd like to spend if hardware can do it.

teeples wrote: You might still need metasprites if you want to conserve texture memory.

I was thinking more from the perspective of what I've done in PC games using SDL (and 3DS homebrew as well). I don't touch texture memory directly; I just store graphics as an array of bytes in RAM and write them to the framebuffer accordingly using priorities. In most systems nowadays, you'll have plenty of RAM to play with (my Odroid U2 has 2GB alone, smaller than a credit card without the heatsink/metal casing), so even large-scale 4K graphics can be stored there. If you build the output image pixel by pixel before sending it off to the GPU as a texture, you'll more or less have consistent texture memory usage. Admittedly, that's not how many people make their games (per-pixel I mean) but it's always one option.

Shonumi wrote:it should let me use whatever USB controller I want, as long as it has enough buttons.

How would it know which button is the Start button, just to let you into the menu so you can set up the other buttons? It's not like Xbox 360 controllers where XInput guarantees a particular mapping of button numbers to physical positions.

As for making your own tile map system: That's something the hardware vendor would provide to developers in an example project.

I just store graphics as an array of bytes in RAM and write them to the framebuffer accordingly using priorities.

Are the systems fast enough to do this sort of software rendering at 2160p and 60 Hz? I thought the idea of keeping them in CHR RAM texture memory was so that the GPU would have them available without having to steal so many cycles from the CPU.

tepples wrote:Shonumi wrote:it should let me use whatever USB controller I want, as long as it has enough buttons.How would it know which button is the Start button, just to let you into the menu so you can set up the other buttons? It's not like Xbox 360 controllers where XInput guarantees a particular mapping of button numbers to physical positions.As for making your own tile map system: That's something the hardware vendor would provide to developers in an example project.

How about just using a controller that comes with the system? I would probably be set up just like the SNES's controller. As long as the controller fits in the controller port, it doesn't matter how the buttons are mapped, you could make an adapter for a different controller if you really want to, as long as it's wired. (I hate wireless controllers, unless they have the battery life of my GameCube wavebird.)