nesdev.org

tepples wrote: 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.

We're talking about this "modern" system right? Not confusing it with the 360 or PS3 I mentioned (for which regular USB controller support is a pipe-dream). Have the player map them out, just like most emulators and most PC games. The player could use the controller included with the system to navigate to a menu, then swap in a new controller and use that as the default once mapped. The system's kernel should be able to handle input from the controller. If it's Linux based, it shouldn't be an issue for most controllers out there.

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

I'm unaware of Nintendo having done that with the 3DS though, or even other systems like the GC.

tepples wrote: 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.

Most mid-range CPUs handle this easily. I've only ever done single-threaded software rendering, but this sort of serial task is ripe for multithreading. The thing is that most of the PC hardware I've worked with just has enough bruteforce to not give another thought. If you botch up the rendering code (not being efficient about which pixel has the highest priority) then you easily run the risk of slowing down things. The best system I've had to date stores a cache of portions of the screen that are known not to change between frames, which vastly reduces the CPU overhead.

Shonumi wrote:The player could use the controller included with the system to navigate to a menu

Which means you'd need to contract with someone to manufacture the controllers.

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

I'm unaware of Nintendo having done that with the 3DS though, or even other systems like the GC.

I take it you haven't seen the official SDK. But then neither have I.

The best system I've had to date stores a cache of portions of the screen that are known not to change between frames

I'm aware of dirty rectangle systems. But good luck finding an area that you can cache if you're doing even the most basic of parallax scrolling. Have you played the "Snow Barrel Blast" level in the first Donkey Kong Country?

tepples wrote: Which means you'd need to contract with someone to manufacture the controllers.

Or just go with a mouse and keyboard based menu system if you're going to be no-frills like so many Android consoles. Works well enough with many Mini-PCs where they assume nothing about what the user's specific end goals are. But I thought we were talking about a hypothetical "modern" console. Contracting for manufacturing anything would be a given, yes?

tepples wrote: I take it you haven't seen the official SDK. But then neither have I.

The GC and 3DS SDK have been leaked for quite a while. Not that I ever touched either myself, but I've asked around with the people who've poked them. I can contact someone specifically about the 3DS if you can wait for a response.

tepples wrote: I'm aware of dirty rectangle systems. But good luck finding an area that you can cache if you're doing even the most basic of parallax scrolling. Have you played the "Snow Barrel Blast" level in the first Donkey Kong Country?

I don't play DK games actually (a crime to be sure ) but I'm pretty familiar with many cases where caching isn't applicable. A good priority system makes bruteforcing things possible under reasonable circumstances. Trying to account for thousands of objects doesn't work well. Hundreds sure, but eventually I do hit a hardware limit.

This topic is right up my alley! I'd like to propose an alternative to interpreting 'modern' as 'matching the capabilities of a modern computer or console'. As Shonumi said, "So, basically any PC, minus the GPU's ability to render 3D." Here is my proposal:

PocketEngine is a modern GBA-inspired graphics core. It has selectable output resolutions of 256x144, 256x160, and 256x196, although built-in upscaling allows for better rendering at scaled resolutions.

• 4 backgrounds, available regardless of what features are enabled...
  ... which can be rendered as Text and Bitmap bitmaps
  ... with Affine Rotation-Scaling
  ... with width and height selectable 16tiles to 128tiles (128px to 1024px).
• 128 (possibly 256 Sprites)...
  ... which can be rendered as Text or Bitmap sprites
  ... with Affine Rotation-Scaling
  ... with width and height selectable from from 1tile to 8tiles (8px to 64px) dimensions.
• Tiles can be paletted (4-bit or 8-bit) or true color (4byte ARGB). Palette colors are 4byte ARGB as well.
  ... Backgrounds and sprites can all blend with each other.
  ... A fixed-function blender allows for normal, additive (multiply), subtractive (screen), and 'hued' blending (colors the pixels of a sprite or background with an additional ARGB hue value).
• 4mb of VRAM for tile/bitmap graphics.
  ... However, each background can only use 1mb of VRAM.
  ... Likewise, sprites can only exist within 1mb of VRAM.
  ... This addresses performance concerns: allows for better cacheing of the tileram.
• With regards to affine rotation-scaling, all inputs are floating point, although internally the background and sprite rendering engines use fixed point for speed.
• If left unmentioned, all other features that the GBA has (mosaic, windowing, etc) are implemented in PocketEngine.

PocketEngine could be attached as a software renderer library to any other program. So it could be run as the front end for any compatible program or any (fast enough) hardware.

pops wrote:256x144, 256x160, and 256x196

That doesn't sound modern at all. This is just "retro without all the annoyances".

tokumaru wrote:

pops wrote:256x144, 256x160, and 256x196

That doesn't sound modern at all. This is just "retro without all the annoyances".

This conflates 'modern' with 'high resolution'. The resolution at which a game is rendered is only one artistic choice among many, just like the choice of 2D instead of 3D. A game like Swords and Sworcery could easily be described as both retro and modern.

Why then the low resolution? Two reasons:

First, like the vast majority of people on this forum, I love pixel art. It's an art style that allows an artist to abstract the subtleties a designer doesn't want to give away or specify. It also reminds me of the games that I played as a kid, which earns it uncounted extra points. The specs for the proposed PocketEngine would provide a platform for making games in this style, without - as you correctly pointed out - 'all the annoyances'.

Second, the low resolution comes from an awareness that despite the endless power of today's CPUs, there's still a limit as to how fast a software renderer can do its thing, particularly if we're allowing unlimited alpha blending and the required read-write of a pixel or line in the graphics buffer[*]. My proposed spec would certainly run quickly on both yesterday and today's computers.

[*] And particularly if I'm the one programming the thing!

Would the 2DS be considered a modern "2-D" console? Or perhaps the 3DS (any variety) on 2-D mode? --ShaneM, the Master of ASM

ShaneM wrote:Would the 2DS be considered a modern "2-D" console? Or perhaps the 3DS (any variety) on 2-D mode? --ShaneM, the Master of ASM

That's an interesting question. Certainly, you can 'emulate' tile-and-sprite-based systems using 3D hardware (as noted above, the 3DS doesn't include the GBA/DS tile-mapped hardware, so a recreation of a NES game on 3DS/2DS hardware would require some kind of graphics emulation). And a game rendered in 3D can still include only 2D mechanics and thus be considered 2D ('Splosion Man). But of course, a game rendered using only 2D functionality can include elements of depth both in graphics and mechanics (in retrospect, mode7 seems to have been meant for this kind of game!). Space Harrier for the Sega Master System, and 3-D World Runner for the NES certainly seem 3D enough to me.

I consider any computer without 3D transformation/projection hardware capabilities to be 2D. Of course, Doom and Quake run just fine on computers like I've just described. So really, it's a matter of personal preference as to what makes a '2D system'.

pops wrote:This conflates 'modern' with 'high resolution'.

Actually, it conflates "modern" with the "possibility of using high resolutions".

The resolution at which a game is rendered is only one artistic choice among many

Exactly! And by restricting the resolution so much you're making several other types of artistic styles impossible. With high-resolution graphics I could do hand-drawn sprites, or go for a pixelated retro look. At low resolutions I can only go for pixelated.

A game like Swords and Sworcery could easily be described as both retro and modern.

Yes, I agree that a game can still look modern even if it's pixelated, if you include enough modern elements of other kinds, but this thread is about a modern 2D system, and I'm of the opinion that such a system should be able to support other kinds of modern art styles.

Not to take away from your product, it's certainly very interesting, I just wouldn't call it modern when it's obviously catering to the niche market of pixelated games.

First, like the vast majority of people on this forum, I love pixel art. It's an art style that allows an artist to abstract the subtleties a designer doesn't want to give away or specify. It also reminds me of the games that I played as a kid, which earns it uncounted extra points. The specs for the proposed PocketEngine would provide a platform for making games in this style, without - as you correctly pointed out - 'all the annoyances'.

I have nothing against pixel art, I absolutely love it, but a modern 2D system should be able to handle more than that to be called modern, IMO.

Second, the low resolution comes from an awareness that despite the endless power of today's CPUs, there's still a limit as to how fast a software renderer can do its thing

A modern 2D system wouldn't have to use a software renderer, so this is a limitation you imposed on yourself. This is fine, because this is your product and you're designing it around a particular art style that you're fond of. I'm just arguing it's not a general purpose 2D system, and you probably never wanted it to be that anyway. I just figured I'd say something because I thought the thread was about imagining where we'd be with 2D systems if the world hadn't switched to 3D.

I didn't mean to be rude or anything, so sorry if my comments came off that way. It's just that the "what if" nature of this thread gets me thinking about art styles that have been poorly explored by professional game makers because 3D is easier, such as large, fluid hand-drawn sprites and backgrounds.

Yes, I agree that a game can still look modern even if it's pixelated, if you include enough modern elements of other kinds, but this thread is about a modern 2D system, and I'm of the opinion that such a system should be able to support other kinds of modern art styles.

That's a very good point! Not that it would fully encompass your concerns, but you've inspired me to allow resolution doubling in my software renderer (so a max resolution of 512x386). Which, of course, means more time spent optimizing. Which, come to think of it, sounds like fun!

... the "what if" nature of this thread gets me thinking about art styles that have been poorly explored by professional game makers because 3D is easier, such as large, fluid hand-drawn sprites and backgrounds.

If the gaming industry was full of games as gorgeous as the most recently released Rayman, I'd be ecstatic! I love gorgeous hand drawn art - one of my best friends is a digital artist, and I would love to see his art in motion. On a related note, I wonder how much less expensive it is to create beautiful hand-drawn worlds versus modeling huge 3D environments. I know the AAA industry is in a sad state, but it's been that way since the mid-90's, if not earlier. I wonder if things would be any different in your hypothetical 3D-less universe.

I do know that Kirby's Adventure on the 3DS/2DS does indeed have 3-D mode. So I'm not sure if this is an example of a rewritten classic with 3D features or an emulator setting within the WAD file. This is a game I don't have on VC so I can't say for sure like I was able to do with some other games in an earlier thread. --ShaneM, the Master of ASM

"WAD file" makes me think of Doom, despite Wii app packaging using the same extension. And if you have Lynx-style sprite scaling and Mode 7-style background rotation, you're very close to Doom anyway.

But for the direction that hand-drawn sprites could go, see any later CPS or Neo Geo fighting game.

Wasn't the Lynx capable of rendering triangles? That would put it beyond Doom (although I wonder about the resulting framerate).

I really don't get it, but why would having triangles be any better than squares? If you had a cube, it would take 12 triangles, but with squares, it would only take 6. Anyway, with a square, you can always make 2 of the coordinates exactly the same for a triangle. I know the Doom engine can't really do anything too fancy with polygons or whatever, (I think I remember hearing that you couldn't look up because the textures get all messed up?) but the Sega Saturn can, and that's where I hear the most complaining.

Espozo wrote:I really don't get it, but why would having triangles be any better than squares? If you had a cube, it would take 12 triangles, but with squares, it would only take 6. Anyway, with a square, you can always make 2 of the coordinates exactly the same for a triangle. I know the Doom engine can't really do anything too fancy with polygons or whatever, (I think I remember hearing that you couldn't look up because the textures get all messed up?) but the Sega Saturn can, and that's where I hear the most complaining.

A polygon defined by three vertices always represents a single plane. Not so with a polygon defined by four vertices. Lighting and texturing non co-planar vertices is much more difficult than doing the same with co-planar vertices. Unless, of course, you render the quad as two tris. In which case, you might as well be rendering tris to begin with.

It is also easier to run scan conversion on tris than quads.

The Doom renders functions use ray-casting (see toku's comment below, I'm wrong).