How many sprites can the Neo Geo update per frame?

[TmEE]

The Mega Drive only supports 16 (or 20) sprites per scanline, possibly because their sprite attribute table is in VRAM and has to share bandwidth with the BG layers. But the tiles-per-line limit is only slightly lower at 32 (or 40), resulting in 100% line coverage for the Mega Drive in both modes, versus 106.25% line coverage for the SNES.

MD VDP actually uses both VRAM and internal cache which is updated during writes to sprite list in VRAM (so simply changing sprite list location will not update that internal cache). Internal cache contains Y coordinate, link value and size and it is used to determine visible sprites for the next line getting drawn. At the same time X coord and tile info from VRAM list (according to previously stored visible sprites info) gets read and stored so that when the line ends, rendering can immediately begin using the stored info. Sprites are rendered into an internal line buffer during line blanking period, and shown during active line while also getting erased so that rendering can be done again next blanking. There aren't enough VRAM access slots to have larger coverage of sprites even if remainder of the render process somehow allows extended coverage. An extra sprite with a few tiles of extra pixels on a line would have been very nice ~

[NeoOne]

It also stops the main program on the SNES, since there's only one CPU data bus. The PPU can still render pixels, and HDMA overrides regular DMA. The audio subsystem is also quite separated. Afaik the DMA transfers just activate the /rd control line of one device and the /wr control line of another device, so it transfers 8 bits at once per memory cycle.

I didn't know that. I just assumed the whole point of DMA was to allow direct memory access so the CPU could do other things!

I find it fascinating that, on 2D systems, the sprite line buffer is the closest equivalent to the flexible framebuffers of 3D systems (PSX and above). The tile slices are simply blitted into it, there's no fancy logic that decides which one has priority (which is what probably happens with the backgrounds).

I love sprites because coming from computers where you often have to draw to the screen with the CPU yourself - It's so nice to be able to draw objects for "free" by comparison. Yes like you say, on Neo Geo the sprite priority is just the order they are stored in VRAM. This is probably the case for most systems I imagine.

Yeah, but it's always worth remembering that the number of cycles can't always be compared, you really have to translate them to nanoseconds. The Genesis, for all its much-touted speed, has the same or slower ROM access speed (but twice the bandwidth).
The 65xxx systems also have several stages in their memory transfers, but those are not coupled to clock ticks.

Yes that's true. All systems have their quirks/bottlenecks. But purely on the CPU - you can get a 6502 as fast as a 68000 in terms of clock speed (e.g. PC Engine CPU) so the 68000 does seem slow at certain things in comparison in that case

Racing games could use that technique too.

Oh yes. On racing games it's not as obvious though. I have actually used that technique myself on Neo Geo actually. Moving on the Y axis as well as the more standard X. You can do some cool things with that!

[creaothceann]

I just assumed the whole point of DMA was to allow direct memory access so the CPU could do other things!

On the SNES it's for speed. The 65c816 core already has two block move opcodes, but they take 7 CPU cycles (each of which can be 6, 8 or 12 master clock cycles) per byte. DMA takes a fixed rate of 8 master clock cycles per byte.

All systems have their quirks/bottlenecks. But purely on the CPU - you can get a 6502 as fast as a 68000 in terms of clock speed (e.g. PC Engine CPU) so the 68000 does seem slow at certain things in comparison in that case

I'm not sure but it seems that CPU speed is mostly a matter of how big the electrical lines and components are. Larger wires need more time before the electricity sloshing around in them stabilizes its level. So perhaps Hudson Soft was able to use a chip fab that could do smaller lithographic processes, while Nintendo wanted (or had) to use older, cheaper technology.

[NeoOne]

Yes it did seem like sprites were expensive back then (I guess you also need a certain amount of speed/memory bandwidth to display lot of them per line).

The S-PPU uses the active display portion of the line to scan OAM (which is separate from VRAM) to collect a list of up to 32 sprites that overlap the next scanline. VRAM is simultaneously occupied entirely with loading background layer map and tile data, with the fetch pattern depending on the BGMODE setting. Then, during HBlank, the S-PPU starts loading sprite tile data from VRAM and rendering it into a line buffer; there's enough time allocated for this in HBlank for 34 8-pixel tile rows to be rendered before background layer data loading has to start again.

The SNES GPU hardware is pretty good really. Just a shame the CPU was not faster. 32 sprites is not bad! I suppose the biggest advanatage the MD has is it can display at 320 x 224 resolution which is the same as many arcade machines and much more standard than the SNES resolution

The strangest story is on the PC Engine where they put a soft-limit on how many sprites developers could display per line!. NEC/Hudson were worried that accessing the VRAM too fast would cause the memory to produce the wrong values, so they soft-limited the speed which meant less sprites per line. But the guy who made R-type ignored this, which caused some arguments within the company. When they made the US version of R-Type, they put the limit back in place and so there is a lot of sprite flicker on that version of the game!

After a certain number of years they did lift this limit because there was never really any problem in the first place

The NES did it that way. It was a cost-saving measure, because the wider cartridge connector was cheaper than a large pool of VRAM would have been. I'm not sure what the thought process was when they decided not to allow that on the SNES - perhaps they wanted to allow developers to use compressed graphics and/or software-rendered framebuffers without having to stick a bunch of expensive RAM on the cartridge, and giving the S-PPU full access to VRAM and full access to cartridge-based CHR ROM/RAM would have been a bit much..

YES! This is what I think all the 8-bit computers did with their cartridges (there are games and word processors you can get for C64, ZX Spectrum etc on cartridge). They just replace an area of memory with the cartridge ROM. Then the CPU just treats that area as normal memory pretty much

Like you say though, its probably just because the graphics chips on consoles needs an ultra fast area of memory to read from (VRAM) so ordinary memory space is no good. And it would be more expensive to sort out general access for that

That's the advantage of arcade hardware. You can take a hit like that and keep going strong. A 2.68 MHz 68000 would have been horrible for raster interrupts (though I suppose that was never a real risk, as the 68000 can operate much faster than the 65C816 on the same memory spec)...

Yes I don't think a 68000 that slow was possible. Because it was designed to run faster from the get-go. Otherwise it would be too slow even without the interrupts. I think the first ever 68000 in 1979 was 4Mhz slowest version

Isn't Copper capable of precise mid-scanline writes? I seem to recall it pulling off stuff the SNES couldn't do, at least not without reengineering it to not need pixel-perfect raster effects...

Yes I think so. Although you cant do actual pixel by pixel changes as far as I am aware. The Amiga only had 8 sprites (16 pixels x 256 pixels) but it could use the copper to repeat them horizontally. And they could be broken down/reused into 128 sprites, with a lot of restrictions. Some games would even make a full screen parallax layer using them (R-Type 2, Jim Power + Risky Woods are examples of this)

https://codetapper.com/amiga/sprite-tr ... sky-woods/

I remember reading they even managed to use the Copper to do full screen rotation and zooming. The guy claimed it was more flexible than SNES Mode 7 but it wasn't as fast to do. Not sure how it worked, maybe it wrote to the blitter every line? I do know though that Brian the Lion used that technique for rotating objects in the game

Yes. As I've mentioned, there are way too many bullets to use hardware sprites for them, so I draw them into a framebuffer with the Super FX. Normally one would use a background layer to display a Super FX framebuffer. But a bunch of stages and bosses in this game have backdrop effects that can only be properly achieved with Mode 7, and Mode 7 only gives you one BG layer*: the affine layer. So to overlay the Super FX framebuffer on the Mode 7 backdrop, I have to use a grid of large sprites as a fake second layer..

I am wondering what this game is with all these bullets and mode-7 style effects?! Whatever it is, on the SNES it will definitely be impressive!

It is Mode 7. There's X scaling going on. And look at that detail level - doing that with a raster racer technique would have taken a huge amount of ROM and probably more DMA bandwidth than they had.

I didn't know that! I just assumed it was designed well to look like proper scaling. I'm sure I've seen it in a shooter on a different system. For some reason I think its PC Engine but I might be wrong. It could have been an arcade game

Lots of demos use Mode 7 in fun ways. The demo I linked earlier as an example of changing OBSEL wrong (Magical by First Try) does so to support a fullscreen sprite backdrop so as to use Mode 7 for the text scroller and logos, which allows some fancy distortions to be performed at high speed.

yes I watched that demo. It reminds me of a lot of Neo Geo demos - not very impressive if you don't know what's actually going on. Most people will just think - oh he's just doing some Mode 7 effects in front of a standard background.

This is actually my favourite demo on Neo Geo (there aren't many to choose from) because it blew me away when I saw it.

https://www.youtube.com/watch?v=3Hkv4fKAroo

The Neo Geo has no screen memory (everything comes from ROM and is drawn into a line buffer) so real 3D should not be possible. Maybe 5 years later I found out - it isn't real 3D at all - just a clever animation. Oh well.

Much later, I did start to work on a real 3D cube (using raster interrupts) but I only got so far as drawing single polygons. I hope to go back to it after this project. A guy who is a better coder than me, has used my technique to make an actual rotating 3d cube (at 60fps), so I know its possible. I just want to do it myself It takes me a long time because I still have to learn stuff as I go along.

[Pokun]

Yes like you say, on Neo Geo the sprite priority is just the order they are stored in VRAM. This is probably the case for most systems I imagine.

Yep pretty much. Game Boy is a notable exception where sprites with a lower X-coordinate has priority over other sprites, which is pretty weird as sprites that moves upwards may get priority. Game Boy Color fixes this by adding a register for choosing if you want your GBC game to use the X-coordinate to decide priority or use the sprite number (the order in the sprite attribute table) to decide like on most other systems.

The SNES uses the lower sprite number as usual, but it also has a register for setting which sprite number is to have the highest priority, and that way it offers a hardware solution to sprite shuffling without actually having to move around the sprite data in the sprite attribute table in order to alternate which sprites are dropped when there are too many at a time.

[turboxray]

The SNES GPU hardware is pretty good really. Just a shame the CPU was not faster. 32 sprites is not bad! I suppose the biggest advanatage the MD has is it can display at 320 x 224 resolution which is the same as many arcade machines and much more standard than the SNES resolution

32 sprites for the line might sound impressive, and it is.. if-and-only-if you're running with almost all 8x8 sprites (i.e. bullet hell shmup or game with lots of sprites for debris). Which like 99.99% of your games are not. Because you're going to hit that sprite pixel line limit waaay before you hit the 32 sprite per line limit. What makes this "32" number mostly irrelevant, especially given the 2 size per frame limit. The MD might only have 20 per line in H40 mode, but the fact that you have 16 sizes ranging from 8x8 to 32x32 all in 8px increments - all available on the frame/screen is the biggest advantage the MD has over the PCE and SNES. Even in MD H32 mode, it still out performs the SNES here. The 1.06% sprite pixel overdraw of the SNES means nothing here. MD's biggest advantage is that it's a sprite monster capable of its generation (NG aside haha).

The strangest story is on the PC Engine where they put a soft-limit on how many sprites developers could display per line!. NEC/Hudson were worried that accessing the VRAM too fast would cause the memory to produce the wrong values, so they soft-limited the speed which meant less sprites per line. But the guy who made R-type ignored this, which caused some arguments within the company. When they made the US version of R-Type, they put the limit back in place and so there is a lot of sprite flicker on that version of the game!

After a certain number of years they did lift this limit because there was never really any problem in the first place

Just to add clarity on this. This is in reference to the higher dot clock modes. Low res is 5.37mhz dot clock, and this vram setting has nothing to do with this and isn't an issue for these games.

Mid res mode is a 7.16mhz pixel dot clock.. and you can set VRAM speed (2x slower) individually for sprites and bg tile fetches. The VRAM(SRAM) in the PCE/SGX is 120ns. The mid res dot clock access is 139ns. The PCE is unique in that you can define the frame of active video both horizontally (8px segments) and vertically (line segments). Thus you can define how long Hblank is. If you run vram at 7.16mhz / 2, then there won't be enough time to fetch all sprite cells for sprite pixel line limit during hblank - you'll get dropped cells, artificially creating a smaller line limit. To get around this, you can reduce the active line width. Every 8px allows two 16px cells to be fetched. There are a mix of games that enable it or run at full vram speed. It's not some blackout period or such where all games had the slower vram setting. Matter of fact, a number of games (vertical shmups) had either direct options or cheat codes that allowed the games to run in mid res mode for a more squished screen - and didn't set the vram to slower mode. IREM continued to use the full vram speed.

You have RType US that was adjusted for the slower vram settings, but also Ninja Spirit US which runs it at full speed. Funny thing about Rtype port; the Japanese version runs at 352x224 resolution - so when the US port enacted the slower vram settings, they attempted to do what I described above - reduce active area to give back more hblank time. So the US version is 336x224. Still not enough but an improvement. But what they didn't bother doing.. was culling the sprites on the right hand side for this new smaller active area. On the PCE.. ALL sprites are evaluated on the line. It doesn't do auto-culling like the SNES (which again, is more if an aid to over come the SNES OAM format. Culling is trivial to do on the PCE/MD).. so any higher priority sprite that is off-screen can cause sprites on screen to potentially drop out. Culling your sprites is important hahah. Speaking of which, I have a hack of US R-Type running in 368x224 at full vram speed. The funny thing about R-Type CD.. is that they brought in the US source code that had the crippling vram settings and lower FOV. Talk about lazy or inept/clueless. So the JP Hucards are a better gaming experience than the JP CD game.

320 x 224 resolution which is the same as many arcade machines

The only arcade system that runs a 6.7mhz pixel dot clock AFAIK, or close to it, is the System-16. Others run either square pixels (NG, Konami, etc) at ~6mhz... or go the higher route ~8mhz (the "384px" res). Even the NG, with its 304px wide screen.. only the centered ~288pixels are in same active line area as the MD's 320px.. the rest is just overscan. I get what you mean, but it's not the "same".. but it is a good mid-way point for conversions. You can run square pixels conversions directly but with a skinnier perspective (and more FOV), or if you did have to down scale - you have more resolution to work with (colors being the biggest issue).

I didn't know that! I just assumed it was designed well to look like proper scaling. I'm sure I've seen it in a shooter on a different system. For some reason I think its PC Engine but I might be wrong. It could have been an arcade game

Metamor J, but it doesn't do any scaling.. it's just a fixed X offset pattern down the screen to give it the curve perspective and uses H-Int color updates as well. Scrolling the screen vertically gives it a rotation illusion. SNES RKA uses something like this as well IIRC.

The SNES uses the lower sprite number as usual, but it also has a register for setting which sprite number is to have the highest priority, and that way it offers a hardware solution to sprite shuffling without actually having to move around the sprite data in the sprite attribute table in order to alternate which sprites are dropped when there are too many at a time.

More of an aid needed on the SNES because of the high/low OAM format. Doing this manually on other systems is trivial, but not so on the SNES.

A side note in relation to that feature: in Axelay, the fire boss, they use this to get around sprite cell drop out. The two large arms, as they overlap, blowout the sprite pixel line limit. The z-fighting on the arms tho looks bad (because it's not a 60hz two cycle switch). But here's the kicker.. they wouldn't have needed this if the SNES didn't have the odd quirk of dropping cells in reverse order (highest priority cells get dropped first instead of lower priority). PCE and MD drop the lowest priority cells.. like you would want. That means the overlapping sections.. that are mostly hidden by the top priority sprites, would drop out on the PCE/MD. I.e. much less visually noticeable. And you could detect for this and just cycle those lower priority sprites if you wanted. The only thing that sorta saves the scene on the SNES, is that the player object typically can't be near the arms (the overlapping part) when this happens because of the damage threat, so you can't see the effect of cycling on it.


You know, it's kinda funny to see in some circles (mostly C64 and SMS) that the NES is "cheating" because of mappers. Even though most don't even know what the mappers actually do. But NES and NG share more similarity in the fact that both had the graphics ("vrom") on the cart - and both use "mappers" to expand the range. The SNES/PCE/MD don't have anything like that.. but the PCE has a full huge backplane expansion bus. It's insane what pins were brought out to the expansion connector... but even they didn't bring any of the VDC memory connections out to it. So while hucard definitely wasn't going to have vram lines extended to the cart port, they could have on the PCE expansion port - and they didn't. Makes the NES and NG pretty unique.

[SNES AYE]

I suppose the biggest advanatage the MD has is it can display at 320 x 224 resolution which is the same as many arcade machines and much more standard than the SNES resolution...

MD's biggest advantage is that it's a sprite monster capable of its generation (NG aside haha).

Yes, that 320×224 resolution really makes it much easier to directly port assets from quite a few other systems of the era, which often output games at 320×224 (or lower). Even when porting from systems with higher resolutions, 320×224 is generally high enough to look very close in most cases. I suspect many more casual players don’t even realize that many Genesis ports from the arcades still have lower horizontal resolution and view compared to the original arcade versions, in addition to the other more obvious compromises.

I personally think the sprite pixel-per-scanline limits and the horizontal resolution of the Genesis were two of its biggest strengths during that generation. The Neo Geo’s sprite capabilities were even more impressive and immediately apparent at a glance. At the same time, most games consisted not just of sprites but also multi-layered backgrounds. In this regard, the SNES truly excelled, more than any other console of that era. The Neo Geo, with its peak sprite capabilities for a home console, also did an impressive job of faking multiple overlapping background layers while handling many large, animated sprites on-screen—making it a true sprite powerhouse above all other systems of the time.

Each system had its own strengths: the Genesis for sprites, the SNES for backgrounds and special effects, and the Neo Geo for sheer sprite power. The PC Engine wasn’t necessarily the peak in any single area, but it was a remarkably solid all-around system for its time—especially considering it wasn’t designed to directly compete with the Genesis, SNES, or Neo Geo, but rather the humble NES. That it performed so well, to the point that most casual players would never question its rightful place among the generation’s other greats, is genuinely impressive.

For me personally, the SNES stood out for its special effects, which included complex multi-colored transparency (the first console to properly support this), dual color windows, mosaicing, built-in Mode 7 (meaning it could be used at full resolution at 60fps), high-fidelity column scrolling, a maximum resolution of 512×448i, HDMA (a very powerful and versatile feature), and even support for Dolby Surround sound (again, the first console to do so).

Ultimately, it’s the combination of these strengths that makes each system unique, and the games that fully leverage these capabilities are the ones that truly shine. The Neo Geo was a total powerhouse in terms of sprites, and its abilities in that regard were unmatched by any home console of the generation. I haven’t read every comment, so I don’t know if anyone answered how many sprites it could update per frame, but I wouldn’t be surprised if the number was very high—or if the end result was ultimately untouchable by any other system of the era. It really was a sprite beast.

A side note in relation to that feature: in Axelay, the fire boss, they use this to get around sprite cell drop out. The two large arms, as they overlap, blowout the sprite pixel line limit. The z-fighting on the arms tho looks bad (because it's not a 60hz two cycle switch). But here's the kicker.. they wouldn't have needed this if the SNES didn't have the odd quirk of dropping cells in reverse order (highest priority cells get dropped first instead of lower priority). PCE and MD drop the lowest priority cells.. like you would want. That means the overlapping sections.. that are mostly hidden by the top priority sprites, would drop out on the PCE/MD. I.e. much less visually noticeable. And you could detect for this and just cycle those lower priority sprites if you wanted. The only thing that sorta saves the scene on the SNES, is that the player object typically can't be near the arms (the overlapping part) when this happens because of the damage threat, so you can't see the effect of cycling on it.

This is an interesting example. I personally expect it would be possible for someone to tweak the sprites—whether their sizes, exact positioning, or both—along with smarter use of the background layers, including the third layer, to eliminate most, if not all, of that flicker. I even suspect there might be some broken code contributing to the issue. But of course, without a working example of some alternate version, this remains pure speculation and a bit of wishful thinking on my part.

[lidnariq]

The MD might only have 20 per line in H40 mode, but the fact that you have 16 sizes ranging from 8x8 to 32x32 all in 8px increments - all available on the frame/screen is the biggest advantage the MD has over the PCE and SNES. Even in MD H32 mode, it still out performs the SNES here.

Only in terms of CPU load! Which is huge, but still. The MD only has time for 32 8px slivers (H32) or 40 8px slivers (H40). If you use sprites wider than 16px, you'll run out slivers before you run out sprites, much like the SNES.

[SNES AYE]

The MD might only have 20 per line in H40 mode, but the fact that you have 16 sizes ranging from 8x8 to 32x32 all in 8px increments - all available on the frame/screen is the biggest advantage the MD has over the PCE and SNES. Even in MD H32 mode, it still out performs the SNES here.

Only in terms of CPU load! Which is huge, but still. The MD only has time for 32 8px slivers (H32) or 40 8px slivers (H40). If you use sprites wider than 16px, you'll run out slivers before you run out sprites, much like the SNES.

It’s a maximum of 20 sprites per scanline on the Genesis in H40 mode (covering 320 pixels), 16 in H32 mode (covering 256 pixels), 32 on the SNES (covering 272 pixels), and 16 on the PC Engine (covering 256 pixels), correct? What is the limit on the Neo Geo?

A side note in relation to that feature: in Axelay, the fire boss, they use this to get around sprite cell drop out. The two large arms, as they overlap, blowout the sprite pixel line limit. The z-fighting on the arms tho looks bad (because it's not a 60hz two cycle switch). But here's the kicker.. they wouldn't have needed this if the SNES didn't have the odd quirk of dropping cells in reverse order (highest priority cells get dropped first instead of lower priority). PCE and MD drop the lowest priority cells.. like you would want. That means the overlapping sections.. that are mostly hidden by the top priority sprites, would drop out on the PCE/MD. I.e. much less visually noticeable. And you could detect for this and just cycle those lower priority sprites if you wanted. The only thing that sorta saves the scene on the SNES, is that the player object typically can't be near the arms (the overlapping part) when this happens because of the damage threat, so you can't see the effect of cycling on it.

Following up on my comment above, I’m curious how it might be possible to approach the Axelay fire boss on the PC Engine. Would it work combining the boss’s body and head—which are on a separate background layer on the SNES—with the PC Engine’s single background layer, using animated tiles or palette cycling for the wavy flowing lava (likely altering the overall effect somewhat)? Or would it be best to try and render the entire body and head plus all the arm segments using only sprites? Fitting the whole boss within the PC Engine’s 20 sprite and 256 sprite-pixels per scanline limits seems like it would be quite challenging. Do you think the PC Engine’s sprite ordering—where dropout works in reverse compared to the SNES—might fully compensate for that?

I don’t think the Genesis would have any trouble replicating this boss scene—maybe with a slight adjustment to the colors. As for the Neo Geo, I have to assume it would handle it with ease. Of course, with the SNES version, I’d expect a modern developer remaking that boss battle today could take full advantage of the third background layer, which is almost entirely unused in the current build (aside from the status bar). It could be used for a layer of semi-transparent flames waving in front of the boss, an additional appendage that doesn’t affect the sprites-per-scanline limit, or something similar.

[tepples]

The limit of Neo Geo's sprite unit is 96 sprites covering 96×16 = 1536 pixels per line if not using shrinking. This is enough for 505% coverage of its nominal 304-pixel width, roughly tied with Super NES mode 0. A 16x1-pixel sliver can optionally be compressed horizontally, and unlike on the Game Boy Advance, this doesn't use up more of the quota because rotation is unsupported. Thus the limit is actually 1536 texels.

In front of all this is a non-scrolling, high-priority, 4bpp "fix" layer. This puts its overall coverage (fix + 505% sprites) ahead of the SNES, as you don't need to reserve most of a generic layer for the status bar.

[turboxray]

The MD might only have 20 per line in H40 mode, but the fact that you have 16 sizes ranging from 8x8 to 32x32 all in 8px increments - all available on the frame/screen is the biggest advantage the MD has over the PCE and SNES. Even in MD H32 mode, it still out performs the SNES here.

Only in terms of CPU load! Which is huge, but still. The MD only has time for 32 8px slivers (H32) or 40 8px slivers (H40). If you use sprites wider than 16px, you'll run out slivers before you run out sprites, much like the SNES.

I mean, that was my point. On the SNES, you're going to hit that line limit way before you are in the sprite per line limit. 8x8 gets you there.. but 16x16 means it will only fetch 17 sprites and their cells out of 32 sprite it isolated. If you pair up 16px with an 8px to make a 24px, it's only going to fetch 11 out of 32, with a drop on the last 8px of the pair. Etc. So the 32 sprites per line advantage over 20 is mostly moot - outside those rare use cases. Don't get me wrong, I'll take it over not having it. And my personality type, on the SNES I'd find a way to use/flex it whenever I can. But I'm not going to sweat not having it on the MD - if anything I'm gonna flex multiplexing sprites.

The Neo Geo, with its peak sprite capabilities for a home console, also did an impressive job of faking multiple overlapping background layers while handling many large, animated sprites on-screen—making it a true sprite powerhouse above all other systems of the time.

Pet peeve: It's not "faking" anything. It has chained mode for sprites, specifically for this task. It's better to think of what the NG does is an "object" map or system, vs a traditional tilemap system.. but it's a layer for the purpose of being a layer ("background").. is just formed differently. Matter of fact, having a layer from an object map/system is more flexible/capable than a tilemap is many ways.

You've been asking for numbers, so I'll post some. The sprite line limit is 1536 pixels for the NG, and 96 sprites for the line. The base resolution (active area of pixels) is 304px. In order to seamlessly horizontally scroll series of sprites across the screen without breaking up - it's 320px. The smallest size sprite cell on the NG is 16px wide. 304/16 = 19.. but you need +1 for the scrolling transition.. so 20. You need 20 horizontal 16px wide cells to build a scrolling BG layer. So if you built 3 BG layers.. that's 60 16px cells per line limit: 960px out of 1536px. That's leaves 36 sprites on the line (or 16x cells) left over.. or a line limit of 576 pixels. And again, that assumes layers that are 100% solid across the screen but we know that scenario is less likely for 3 overlapping layers - so you'll actually get more left over for sprites in a practice. We don't really care about height, because the limitation is line fetching. But height can be up to 512px columns. And like tepples mentioned; there's also a static "status" layer on top.

Same pet peeve when people say "fake parallax". It's technically all fake. Line splitting sections of the tilemap for different speeds? That's not actual parallax.. that's an approximation of it (i.e. fake). So it's either parallax (some approximation of it) or it's not (completely flat). And if it is parallax, then it's simply how "complex" is the parallax is in capability. Not "it's fake because it's using sprites or animated tiles" or whatever. If you believe that it's fake, then following that logic MS-DOS games are 100% fake everywhere because it's just the cpu writing pixels to a bitmap buffer.

For me personally, the SNES stood out for its special effects, which included complex multi-colored transparency (the first console to properly support this), dual color windows, mosaicing, built-in Mode 7 (meaning it could be used at full resolution at 60fps), high-fidelity column scrolling, a maximum resolution of 512×448i, HDMA (a very powerful and versatile feature), and even support for Dolby Surround sound (again, the first console to do so).

We're in a technical forum.. no need to do the whole list spiel. And a nit pick: the snes doesn't have "support" for Dolby Surround. It just happens to have fine pan support for the channels. The PCE can technically do it as well (and the waveform inversion too for the alt channel).

This is an interesting example. I personally expect it would be possible for someone to tweak the sprites—whether their sizes, exact positioning, or both—along with smarter use of the background layers, including the third layer, to eliminate most, if not all, of that flicker. I even suspect there might be some broken code contributing to the issue. But of course, without a working example of some alternate version, this remains pure speculation and a bit of wishful thinking on my part.

I don't think there's any broken code here. The problem is directly the reverse sprite cell drop-out of the SNES, and Konami cycling the OAM order to at least show the sprites. It sounds like a simple problem, but it's not. I think you can mitigate it better if you detected and drop sprites yourself, and also in combination with cycle-order certain sprites yourself manually rather than globally doing it. SA-1 would definitely help out in that respect - maybe even going further and doing some realtime composition of sprites for each arm (it moves slowly enough)

The PC Engine wasn’t necessarily the peak in any single area, but it was a remarkably solid all-around system for its time—especially considering it wasn’t designed to directly compete with the Genesis, SNES, or Neo Geo, but rather the humble NES. That it performed so well, to the point that most casual players would never question its rightful place among the generation’s other greats, is genuinely impressive.

"The PC Engine wasn’t necessarily the peak in any single area"

That's just willful ignorance. The PCE has 32 sixteen color subpalettes.. vs 16 or 4. That's definitely peak. 99% of your games are going to use subpalettes, and 32 is twice what the SNES had. It doesn't matter that it doesn't result in more colors possible (unique color count) due to the smaller main palette, because it still translates into color flexibility and freedom. Having more subpalettes means having less dependency between sprites or tiles having to share colors - you have more independent color freedom without having to resort to 8bit color or whatever. That's peak.

The PCE has two resolutions that are higher than the MD. And has an actual higher "usable" resolution than just 5.37mhz dot clock (that 99% of the snes games use). And its highest res mode is actually true high res because it applies to sprites and background detail (not a mix like the SNES). It also has an extremely flexible active frame design - you can build out the active display to go well into the overscan area. That stuff is fixed on the MD/SNES. I patched R-Type to run at 368x240 on the PCE. That's well above the SNES and MD. The frame design capability is just way beyond what the SNES and MD offer (in that they really don't offer anything like it). That's peak.

The PCE's 8bit cpu running at 7.16mhz can do bounding box collisions faster than the 68k clocked in the MD. It might be by a hair or two, but it's a there. That's peak.

The PCE also has the highest MIPS.. peak MIPS!

The PCE has the largest "usable" sprite size out of all three systems: 32x64. And it's used a LOT in games (and not just for cut scenes or whatever). SNES has 64x64, but it's not practical at all. That's peak.

The PCE's VRAM-VRAM DMA is faster than the MD's, and the snes doesn't even have it. That's peak.

The PCE is the only system out of the three that leaves VRAM read/writes open during active display. That's not peak? You can transfer like up to 30k per frame (at 100% cpu usage hahah, but it's there). A lot of PCE games write to vram during active display. That's peak.

Its expansion bus is also peak. The sharpness of detail on its composite output is also peak. Maybe a little too peak haha. I prefer a slightly softer look.

"especially considering it wasn’t designed to directly compete with the Genesis, SNES, or Neo Geo, but rather the humble NES"

That's a funny way to look at it. The 3DO was nex-gen.. it was only competing with 16bit systems when it came out, but that doesn't make it not nex gen system. The Megadrive was also competing with the Famicom... I mean everything was competing with that juggernaut. The PC-Engine wasn't ONLY meant to compete with the Famicom (that would actually be the Master System). The PCE basically formed the base-line for the nex gen consoles - they are mostly an extension of THAT system; performance, sprite capability, color, palettes, vram, etc. The PCE shares a LOT in common with those systems than anything like the Famicom or Master system. And while history didn't take this route, the PCE's expansion bus has everything you need to add video upgrades to the system. It's pretty insane what they put on the expansion connector... and then outright ignored haha - Sega wished they had done that with their expansion port. If I wanted to add 15bit color to the PCE.. it's pretty easy to do. HDMA to the PCE? Doable. Translucency/color-math? Doable. Etc.

[SNES AYE]

The limit of Neo Geo's sprite unit is 96 sprites covering 96×16 = 1536 pixels per line if not using shrinking. This is enough for 505% coverage of its nominal 304-pixel width...

Very impressive. I wish I could’ve afforded a Neo Geo back in the day.

Pet peeve: It's not "faking" anything. It has chained mode for sprites, specifically for this task. It's better to think of what the NG does is an "object" map or system, vs a traditional tilemap system...

You’ve made some very interesting points here. PC Engine was great.

[turboxray]

Following up on my comment above, I’m curious how it might be possible to approach the Axelay fire boss on the PC Engine. Would it work combining the boss’s body and head—which are on a separate background layer on the SNES—with the PC Engine’s single background layer, using animated tiles or palette cycling for the wavy flowing lava (likely altering the overall effect somewhat)? Or would it be best to try and render the entire body and head plus all the arm segments using only sprites? Fitting the whole boss within the PC Engine’s 20 sprite and 256 sprite-pixels per scanline limits seems like it would be quite challenging. Do you think the PC Engine’s sprite ordering—where dropout works in reverse compared to the SNES—might fully compensate for that?

I don’t think the Genesis would have any trouble replicating this boss scene—maybe with a slight adjustment to the colors. As for the Neo Geo, I have to assume it would handle it with ease. Of course, with the SNES version, I’d expect a modern developer remaking that boss battle today could take full advantage of the third background layer, which is almost entirely unused in the current build (aside from the status bar). It could be used for a layer of semi-transparent flames waving in front of the boss, an additional appendage that doesn’t affect the sprites-per-scanline limit, or something similar.

I missed this. Yeah, Genesis would be fine. To get that contrasty look, they don't use a lot of red shades. Same for both lava and the boss. It would be pretty much how the SNES is setup.

PCE would be interesting. I'd have the boss body as a BG layer. I'd have him drawn vertically stretched, so that when the fixed curve Y pattern that makes the lava curve, makes him look normal. I'd probably cheat the top half of the lava split is with smaller 80x64 pattern or such (because you can't see much of the lava anyway, since he's covering up the top half the screen), but keep the bottom half of the screen the same as the snes version. On the PCE, I can draw 'bitmap' lines, so I can re-create the X wavey-ness in software on the pattern itself, as well as the "scrolling" of it downwards. That just leaves the outline of his main body, where I would need to do manual composition against the 8x8 tile edges against this pattern. ~8 red colors are in the fire layer, and 7 red-orange colors around his outline section should be fine to no bust the 16 color limit. Since I have control over the repeating section, I can make the necessary offsets to compensate for when scrolling the "boss" BG layer left or right, in that he moves left or right without the fire layer moving with him. Probably do a checkboard pattern around his head/top screen and the tiles in that area, and use an H-int to change the two colors every lines. 60hz cycle the XOR pattern for good measure. I'd reduce the HUD. There's only 1player anyway, so I'd remove that graphic, the high score (only the current score is important). Since they would be sprites, I'd probably alternate at 60hz for the score and for weapons display. And the rest is just normal sprites. Oh yeah, last thing.. since the PCE has more than enough BG palettes, I'd duplicate sections of the tilemap with different assigned subpalettes - and change that on a per line basis recreating the SNES fade effect of the horizon and roll-off on the fire split.

[SNES AYE]

Following up on my comment above, I’m curious how it might be possible to approach the Axelay fire boss on the PC Engine. Would it work combining the boss’s body and head—which are on a separate background layer on the SNES—with the PC Engine’s single background layer, using animated tiles or palette cycling for the wavy flowing lava (likely altering the overall effect somewhat)? Or would it be best to try and render the entire body and head plus all the arm segments using only sprites? Fitting the whole boss within the PC Engine’s 20 sprite and 256 sprite-pixels per scanline limits seems like it would be quite challenging. Do you think the PC Engine’s sprite ordering—where dropout works in reverse compared to the SNES—might fully compensate for that?

I don’t think the Genesis would have any trouble replicating this boss scene—maybe with a slight adjustment to the colors. As for the Neo Geo, I have to assume it would handle it with ease. Of course, with the SNES version, I’d expect a modern developer remaking that boss battle today could take full advantage of the third background layer, which is almost entirely unused in the current build (aside from the status bar). It could be used for a layer of semi-transparent flames waving in front of the boss, an additional appendage that doesn’t affect the sprites-per-scanline limit, or something similar.

I missed this. Yeah, Genesis would be fine. To get that contrasty look, they don't use a lot of red shades. Same for both lava and the boss. It would be pretty much how the SNES is setup.

PCE would be interesting. I'd have the boss body as a BG layer. I'd have him drawn vertically stretched, so that when the fixed curve Y pattern that makes the lava curve, makes him look normal. I'd probably cheat the top half of the lava split is with smaller 80x64 pattern or such (because you can't see much of the lava anyway, since he's covering up the top half the screen), but keep the bottom half of the screen the same as the snes version. On the PCE, I can draw 'bitmap' lines, so I can re-create the X wavey-ness in software on the pattern itself, as well as the "scrolling" of it downwards. That just leaves the outline of his main body, where I would need to do manual composition against the 8x8 tile edges against this pattern. ~8 red colors are in the fire layer, and 7 red-orange colors around his outline section should be fine to no bust the 16 color limit. Since I have control over the repeating section, I can make the necessary offsets to compensate for when scrolling the "boss" BG layer left or right, in that he moves left or right without the fire layer moving with him. Probably do a checkboard pattern around his head/top screen and the tiles in that area, and use an H-int to change the two colors every lines. 60hz cycle the XOR pattern for good measure. I'd reduce the HUD. There's only 1player anyway, so I'd remove that graphic, the high score (only the current score is important). Since they would be sprites, I'd probably alternate at 60hz for the score and for weapons display. And the rest is just normal sprites. Oh yeah, last thing.. since the PCE has more than enough BG palettes, I'd duplicate sections of the tilemap with different assigned subpalettes - and change that on a per line basis recreating the SNES fade effect of the horizon and roll-off on the fire split.

It sounds like you’ve got some really interesting ideas for pushing the PC Engine and getting very close to the original SNES version. I’d love to see you actually build this, because having a real example on the PC Engine would make it much easier to visualize the final result—it’s hard to picture exactly how it would look right now. I think many fans would love to see a boss like that running on the hardware. Even if it never gets made, it’s a compelling exercise in thinking about how such things might be approached. It could also be useful for analyzing how a roughly similar modern approach on the SNES might use a single layer for both the boss and the background, potentially freeing up the two additional background layers for other purposes. That would be fascinating to see as well. And, just for fun, I’d love to see a Neo Geo version that uses giant sprites, scaling, and all the system’s tricks to really impress.

Interestingly, it’s possible to create a surprisingly good-looking version of the boss’s head, body, and background using only the SNES’s 2bpp BG3 layer. This approach naturally omits effects like the boss’s movement or lava scrolling and waving in the image below for now, but the sky gradient at the top could still be handled with HDMA to change the single palette entry on each scanline, while the rest of the scene here relies on a single black backdrop color plus the three regular colors available in each palette:

Boss 2bpp.png

It makes me wonder whether most of the boss and background could realistically be rendered on a single 2bpp layer on the SNES—possibly with motion too, albeit at a slightly coarser level than the original. It might still hold up visually once the full-color arm and hand segments are added on top. Doing so would free up two full 4bpp layers for other uses. Alternatively, you could just use a full 4bpp layer for the combined boss and background if that makes more sense, leaving one 2bpp and one 4bpp layer free.

And, imagining something like that could be made to work, here’s a potential little hack to help with a portion of the sprite flicker: the second and forth segments of the left arm would use the two spare layers. The hands could also temporarily switch to those BG layers when raised in a position where they appear in front of multiple arm segments:

BG arm segments.png

Of course, if the existing sprite flicker is considered acceptable—and perhaps could be slightly addressed in other ways—those two full background layers would remain free for whatever purpose.

I’m not entirely sure all of this would be fully feasible exactly as described, but it’s an interesting exercise in thinking about alternative approaches on the SNES.

Anyway, I’ll leave it at that and let people get back to discussing the Neo Geo’s ability to update so many sprites per frame.

[Pokun]

More of an aid needed on the SNES because of the high/low OAM format. Doing this manually on other systems is trivial, but not so on the SNES.

Not so trivial on the MSX2 either. The MSX1 has monochrome sprites so only one color, but the MSX2 VDP has a new sprite mode with a sprite color table which is always right before the sprite attribute table in VRAM. The SCT has 16 bytes for each sprite (because it specifies colors and attributes for each line of the sprite) and if shuffling the SAT, the SCT has to be shuffled too so that sprites keeps their colors and attributes.