How many sprites can the Neo Geo update per frame?

[93143]

Yes the Art of Fighting and Samurai Shodown games are also very famous for this.

Don't forget the legendary Waku Waku 7...

The SNES Art of Fighting ports used Mode 7 to replicate the zoom effect, with the fighters composed of small sprites which were masked in software so they wouldn't overlap when scrunched together. It works pretty well.

Unfortunately Mode 7 has a hard limit of 256 8x8 tiles in VRAM at the same time, so the backgrounds had to be simplified.

[Señor Ventura]

Unfortunately Mode 7 has a hard limit of 256 8x8 tiles in VRAM at the same time, so the backgrounds had to be simplified.

Multiplexing tiles is the way...

[93143]

Unfortunately Mode 7 has a hard limit of 256 8x8 tiles in VRAM at the same time, so the backgrounds had to be simplified.

Multiplexing tiles is the way...

How? The SNES can load less than half an 8bpp tile per HBlank, and only if there are no sprites on the next line and you don't need HDMA for anything else. Obviously useless for a fighting game with large sprites. And since Mode 7 doesn't allow you to rebase the tile pool (it's hardwired to the bottom of VRAM), you're stuck with whatever's in there until the next VBlank.

This isn't a problem in any other mode, of course; they can all do 1024 tiles per layer, with flipping, and you can modify the tile base address mid-render. But Mode 7 has unique requirements and restrictions to go with its unique capabilities.

The Neo Geo can't scale graphics up, but the tile restrictions are somewhat less onerous...

[Pokun]

A disadvantage (+ advantage!) of the Neo Geo cartridge system is that all graphics are displayed straight from the ROM. This is very fast (you never need to move any graphics to VRAM first) but it means you can't edit any graphics or make your own bitmaps. If you want a bitmap you can actually change, you have to do your best to fake it with sprites or/and palettes.

And you can't just replace the character ROM with RAM to turn character patterns re-definable like commonly done on NES?

[Señor Ventura]

Unfortunately Mode 7 has a hard limit of 256 8x8 tiles in VRAM at the same time, so the backgrounds had to be simplified.

Multiplexing tiles is the way...

How? The SNES can load less than half an 8bpp tile per HBlank, and only if there are no sprites on the next line and you don't need HDMA for anything else. Obviously useless for a fighting game with large sprites. And since Mode 7 doesn't allow you to rebase the tile pool (it's hardwired to the bottom of VRAM), you're stuck with whatever's in there until the next VBlank.

This isn't a problem in any other mode, of course; they can all do 1024 tiles per layer, with flipping, and you can modify the tile base address mid-render. But Mode 7 has unique requirements and restrictions to go with its unique capabilities.

The Neo Geo can't scale graphics up, but the tile restrictions are somewhat less onerous...

The thing is not to tansfer 8BPP tiles, but uptdating the attribute list of the mode 7 plane, the trick is to preload your tiles in VRAM and then update the Mode 7 tilemap (attribute table), possibly using a triple-buffered layout (one group of tiles for the top of the screen, other for the mid, and another for the bottom). That way you’re only moving a few hundred bytes per region instead of full graphics, and you can give the illusion of more complex backgrounds.

Further more, you can use an supporting processor to accelerate the process (or maybe only an sram, or sram+SA-1, or whatever).


Possibly we could talk about 350 or even 400 tiles instead of only 256.



This is a thing to polish, but there is a way (i hope).

[93143]

the trick is to preload your tiles in VRAM and then update the Mode 7 tilemap

No, you don't understand.

Sprite multiplexing works* because the limit on sprite count is the length of the sprite attribute table. For example, a SNES physically only has enough OAM for 128 sprite definitions, and a Mega Drive in H40 mode will never scan and process more than 80 entries in the SAT. Thus, changing the SAT while rendering (if you can pull it off) can result in extra sprites by repurposing entries that have already been used further up the screen.

Background layers don't work that way. There are 16384 entries in the Mode 7 tilemap - far more than necessary to enumerate 256 unique tiles (and, just to note, far more than necessary to cover the screen without repeating areas of the tilemap, unless you zoom out much further than the Art of Fighting games do). The limiting factor for BG layers is the data format of the tilemap, and the question is: how many unique tile indices can exist given the number of bits available in each tilemap entry to specify them?

(The analogous restriction in the SNES sprite system is not the 128-sprite limit but the 16 KB sprite tile data limit. You can bust this limit by changing the tile lookup base addresses midscreen, but see below for why a similar trick cannot work for a Mode 7 BG layer.)

In the case of SNES Mode 7 (other BG modes work differently), the tilemap entries are 8-bit. You can only specify tile indices between 0 and 255. This means that modifying the tilemap cannot possibly affect the number of tiles Mode 7 can access at one time.

That by itself wouldn't be a showstopper, because normally (i.e. in all other BG modes and even the sprite system) the tile pool's base address can be changed, resulting in those tile indices suddenly pointing to a different part of VRAM. But in Mode 7, you cannot change the tile pool's base address. Tile data is hardwired to start at the bottom of VRAM.

There is nothing you can do about this. Mode 7 is locked to 256 tiles in one frame unless you update the tiles themselves during HBlank, which is very slow and is wildly impractical in basically every type of game for reasons I have already alluded to.


* on systems where it does, which the SNES... may be one of, but probably only with impractically precise timing due to how OAM access works

...

It was not my intention to hijack a Neo Geo thread. I merely wanted to supply a potentially interesting fact that related peripherally to the discussion.

[TmEE]

And you can't just replace the character ROM with RAM to turn character patterns re-definable like commonly done on NES?

As far as RAM would go, there's no CPU access to the graphics bus from what I know, but it isn't impossible to connect CPU bus to any of the other buses on the cartirdge but if that is done already I have no idea. Commercial games did not do such stuff. I'm not sure what banking mechanisms are available and if games even needed any, the address space in the graphics buses is pretty large.

[Señor Ventura]

the trick is to preload your tiles in VRAM and then update the Mode 7 tilemap

No, you don't understand.

Sprite multiplexing works* because the limit on sprite count is the length of the sprite attribute table. For example, a SNES physically only has enough OAM for 128 sprite definitions, and a Mega Drive in H40 mode will never scan and process more than 80 entries in the SAT. Thus, changing the SAT while rendering (if you can pull it off) can result in extra sprites by repurposing entries that have already been used further up the screen.

Background layers don't work that way. There are 16384 entries in the Mode 7 tilemap - far more than necessary to enumerate 256 unique tiles (and, just to note, far more than necessary to cover the screen without repeating areas of the tilemap, unless you zoom out much further than the Art of Fighting games do). The limiting factor for BG layers is the data format of the tilemap, and the question is: how many unique tile indices can exist given the number of bits available in each tilemap entry to specify them?

(The analogous restriction in the SNES sprite system is not the 128-sprite limit but the 16 KB sprite tile data limit. You can bust this limit by changing the tile lookup base addresses midscreen, but see below for why a similar trick cannot work for a Mode 7 BG layer.)

In the case of SNES Mode 7 (other BG modes work differently), the tilemap entries are 8-bit. You can only specify tile indices between 0 and 255. This means that modifying the tilemap cannot possibly affect the number of tiles Mode 7 can access at one time.

That by itself wouldn't be a showstopper, because normally (i.e. in all other BG modes and even the sprite system) the tile pool's base address can be changed, resulting in those tile indices suddenly pointing to a different part of VRAM. But in Mode 7, you cannot change the tile pool's base address. Tile data is hardwired to start at the bottom of VRAM.

There is nothing you can do about this. Mode 7 is locked to 256 tiles in one frame unless you update the tiles themselves during HBlank, which is very slow and is wildly impractical in basically every type of game for reasons I have already alluded to.


* on systems where it does, which the SNES... may be one of, but probably only with impractically precise timing due to how OAM access works

...

It was not my intention to hijack a Neo Geo thread. I merely wanted to supply a potentially interesting fact that related peripherally to the discussion.

As i understand, you can't change the table attribute itself, but you can update the tile already instaled in vram by swapping memory positions, and here hdma has registers for that, right?.

Time ago it was part of a debate around here.

[93143]

As i understand, you can't change the table attribute itself, but you can update the tile already instaled in vram by swapping memory positions, and here hdma has registers for that, right?.

That sounds comprehensively wrong on all points, although your terminology is so weird it's hard to say for certain. I hope you aren't reading my posts through a machine translator.

It seems like you don't understand how tilemaps work. Maybe brush up on that first, and hopefully the explanation I've provided will make sense.

[NeoOne]

Yes the Art of Fighting and Samurai Shodown games are also very famous for this.

Don't forget the legendary Waku Waku 7...

The SNES Art of Fighting ports used Mode 7 to replicate the zoom effect, with the fighters composed of small sprites which were masked in software so they wouldn't overlap when scrunched together. It works pretty well.

Unfortunately Mode 7 has a hard limit of 256 8x8 tiles in VRAM at the same time, so the backgrounds had to be simplified.

Yes I'm a big fan of Waku Waku 7 - especially the scatting (vocal!) on the player select screen

I wish Neo Geo had more into-the-screen racing games that used sprite scaling. I think there are a few things about the hardware that make it more complicated to do in a racing game. Needs a lot more effort on the part of the coder

I actually watched a YT Video about the scaling in AOF a few days back. Very interesting about the overlapping tiles. That seems like a genius solution to me. I had guessed they used Mode 7 but I thought maybe they somehow "drew" the sprites onto the mode 7 background tiles every frame and then scaled them all in one.

On the same video, the guy showed how the PC Engine version was done - it actually just changes screen resolutions. It's more of a sudden zoom but still an impressive trick when you see it in action

[Pokun]

Oh that's a nice example of taking advantage of the fact that the PC Engine has very flexible resolution control.

[93143]

I actually watched a YT Video about the scaling in AOF a few days back. Very interesting about the overlapping tiles. That seems like a genius solution to me.

You can see it happening here.

And now that I've tried to compare individual frames, I'm wondering if the prevailing interpretation (or what I thought was being said in that thread) is wrong. It kinda looks like the sprites with pared-down edges are actually scaled and not just masked. if I'm seeing this right, then either it's real CPU scaling, or they stored all the graphics in multiple versions...

Revolution X appears to have just scrunched the sprites together for the helicopter scene. No scaling or masking.

[NeoOne]

You can see it happening here.

And now that I've tried to compare individual frames, I'm wondering if the prevailing interpretation (or what I thought was being said in that thread) is wrong. It kinda looks like the sprites with pared-down edges are actually scaled and not just masked. if I'm seeing this right, then either it's real CPU scaling, or they stored all the graphics in multiple versions...

Revolution X appears to have just scrunched the sprites together for the helicopter scene. No scaling or masking.

I can't tell from the gif you showed but it def looks like it is removing edges. I guess that is relatively fast - just writing 0's to VRAM locations?

I saw a video yesterday that explained the scaling of objects (when you collect them from a chest) in Star Ocean. And those *did* use software scaling - as well as overlapping tiles. So it was a mix of both.

It's great developers actually went to the effort of doing this. Back at the time we were probably just like "Oh well its well known the SNES can scale sprites" or "It's just mode 7". About 80% of people thought the SNES could scale sprites back then.

That scaling on that helicopter in Revolution X looks really good! More games should have done that. Does it take more CPU time on SNES to move tiles seperately? Or do you have to do that anyway with large objects? (I'm not sure if you can join sprites together on the SNES so they all move as one?)

[93143]

I can't tell from the gif you showed but it def looks like it is removing edges. I guess that is relatively fast - just writing 0's to VRAM locations?

Look at the thick guy's boots.

Somebody in the thread had previously proposed simply trimming edges (and not uniformly across all sprites in the metasprite either) as a homebrew technique, which may be what confused me.

Also, no, the sprites on SNES use the interleaved bitplane format, so the fastest method of (vertical) edge trimming would probably involve a lot of 16-bit immediate AND, with the results written to WRAM. You don't want to be trying to write directly to VRAM in a software rendering loop on SNES, because during active display and HBlank it's closed for exclusive use of the video chips, and your writes will fail.

This is why VRAM updates on SNES are generally limited to what you can push through with DMA during VBlank, and why games like Final Fight and Star Fox often letterbox with forced blank to give the DMA unit more time. Quite foreign to how the Neo Geo (and NES/Famicom) operate.

I'm not sure if you can join sprites together on the SNES so they all move as one?

No such luck. Sprites on SNES don't know about each other. Metasprites on SNES are a software concept. And the OAM format, while it is nice and compact (requiring only 544 bytes of DMA for 128 sprites), is such a pain to use that there's actually a special chip (the OBC-1, used in Metal Combat: Falcon's Revenge) solely to make it easier to compile an OAM image.

The SNES sprite system is actually a pretty weird quasi-legacy design that could have (IMO) greatly benefited from earlier abandonment of the idea of Famicom backward compatibility. I look with envy at the Mega Drive, where any sprite can have its own unique H and V sizes rather than having to select from only two global square* sizes, and getting more than 16 KB of sprite data onscreen at the same time doesn't require potentially brittle, difficult, limiting and/or VRAM- and DMA-wasting tricks†...

* there are two settings with non-square sizes, but they were never finished (or are just accidental undefined behaviour) and vertical flipping doesn't work properly
† my application involves a fake BG layer made of sprites, which makes bypassing the 16 KB limit almost trivial. Something like Metal Slug would be a whole different ball game...

[creaothceann]

If they had used 80 sprites like the Genesis, they could've given each one 6 bytes of data and still end up with only 480 bytes of OAM...
(24 bits x/y position, 11 bits tile index, 4 bits palette, 1 bit color math, 2 bits priority, 2 bits x/y flip, 4 bits x/y size = 8/16/32/64)