Sprites: SNES vs Genesis
-
- Posts: 271
- Joined: Sun Mar 27, 2011 10:49 am
- Location: Victoria, BC
Re: Sprites: SNES vs Genesis
Conjecture 1: The MD CPU tends to be faster and better for mathy things that allow for smooth and flexible multijointed sprites.
Conjecture 2: The SNES' additional background layers and Mode 7 were often used for large bosses and the like; developers thought this approach looked better than multijointed sprites so went with this on the SNES instead
Conjecture 3: The SNES has more flexibility palette-wise; Genesis developers used uniform sprites with a single palette because more elaborate designs would've pushed the small number of colours available too much
Conjecture 2: The SNES' additional background layers and Mode 7 were often used for large bosses and the like; developers thought this approach looked better than multijointed sprites so went with this on the SNES instead
Conjecture 3: The SNES has more flexibility palette-wise; Genesis developers used uniform sprites with a single palette because more elaborate designs would've pushed the small number of colours available too much
Re: Sprites: SNES vs Genesis
It's generally accepted that there was indeed something of an advantage there (though not nearly as big as the MHz numbers suggest). In addition, the 68000 was more familiar to a lot of programmers, and even 65xx programmers often prefer the 68000, describing it as "like being on vacation" and such stuff.adam_smasher wrote:Conjecture 1: The MD CPU tends to be faster and better for mathy things that allow for smooth and flexible multijointed sprites.
The SNES sprite system was also more fiddly to work with, which made it take more CPU power to do the same thing, particularly if you weren't smart about it. Hence the OBC-1 chip used in Metal Combat, and the "soft OBC-1" sprite routine devised by modern homebrewers.
Your other conjectures make sense to me too. As an analogy, I've seen people claim that the Mega Drive was better at line scrolling than the SNES, even though its capabilities were just a subset of what the SNES can do with HDMA. I imagine this sort of thing may be because SNES developers tended to focus more on stuff the SNES could do but the Mega Drive couldn't, rather than just stubbornly going head to head with a better CPU. Conversely, perhaps Mega Drive programmers were attempting to make the most of their system's more limited feature set, so they'd end up doing things like that because they couldn't do stuff like Mode 7 and colour math.
...no?Marscaleb wrote:They both are looking at the same amount of memory for sprites
The SNES can only address 16 KB of sprite tile data at a time. Mid-frame OBSEL writes are very difficult to use for anything other than faking a BG layer with sprites, because of how hard it is to make sure the data you want is available when you want it for every generic moving object on screen. So basically you've got 16 KB to work with.
The Mega Drive can put sprite data anywhere in VRAM. 64 KB. Shared with BG tiles, map data, and the sprite attribute table, of course, but it's still way more flexible if you've got a bunch of huge sprites like in a beat-em-up.
Re: Sprites: SNES vs Genesis
Eh? Then what's this:adam_smasher wrote:...no?Marscaleb wrote:They both are looking at the same amount of memory for sprites
The SNES can only address 16 KB of sprite tile data at a time. Mid-frame OBSEL writes are very difficult to use for anything other than faking a BG layer with sprites, because of how hard it is to make sure the data you want is available when you want it for every generic moving object on screen. So basically you've got 16 KB to work with.
The Mega Drive can put sprite data anywhere in VRAM. 64 KB. Shared with BG tiles, map data, and the sprite attribute table, of course, but it's still way more flexible if you've got a bunch of huge sprites like in a beat-em-up.
If that's the case, then what stops a game from sharing data like the Genesis?tepples wrote:Genesis: 64 KiB; always shared with backgroundMarscaleb wrote:And how much memory does the system have that can be used for sprites; how many tiles could be used for sprite data?
Super NES: 16 KiB out of 64 KiB; can optionally be changed mid-screen or shared with background
Re: Sprites: SNES vs Genesis
There's no function to explicitly "share" data. It's just that the data happens to be in the same format, and nothing is keeping you from specifying sprite and BG data ranges that overlap. That's all that means.
In the SNES case, the BG data for a 4bpp layer (the same format as the sprites) spans 1024 tiles, or half of VRAM. Each BG layer has a separate data range in VRAM specified by the programmer, and these data ranges can overlap (so BG layers can also share data with one another). The sprite data is in two tables, each spanning 256 tiles, and the PPU does not check to make sure you haven't put a sprite table in the middle of a BG data area. (Why would it?) So in principle the same tile can be used by both 4bpp BG layers and the sprite layer, all at the same time.
The only way to exceed 16 KB of sprite data during one frame (that I know of) is to write to OBSEL during an active line to change where the sprite data is looked for. That way, once HBlank arrives and the PPU begins to load sprite sliver data for the next line, it looks in the new location. Unfortunately this is impractical for most situations because it's too hard to figure out where to put stuff to avoid glitching, so in general you're stuck with 16 KB of sprite data, some or all of which may also be background layer data.
In the SNES case, the BG data for a 4bpp layer (the same format as the sprites) spans 1024 tiles, or half of VRAM. Each BG layer has a separate data range in VRAM specified by the programmer, and these data ranges can overlap (so BG layers can also share data with one another). The sprite data is in two tables, each spanning 256 tiles, and the PPU does not check to make sure you haven't put a sprite table in the middle of a BG data area. (Why would it?) So in principle the same tile can be used by both 4bpp BG layers and the sprite layer, all at the same time.
The only way to exceed 16 KB of sprite data during one frame (that I know of) is to write to OBSEL during an active line to change where the sprite data is looked for. That way, once HBlank arrives and the PPU begins to load sprite sliver data for the next line, it looks in the new location. Unfortunately this is impractical for most situations because it's too hard to figure out where to put stuff to avoid glitching, so in general you're stuck with 16 KB of sprite data, some or all of which may also be background layer data.
Re: Sprites: SNES vs Genesis
Sprites can be shared with background but only in some modes where the backgrounds are 4BP, in practice that means background 1 and 2 of mode 1 and mode 2, as well as background 2 of the rarely used mode 3. (Mode 5 also uses a 4BP background but it's hi-res so re-using the same data as sprites won't look the same, harldy useful at all). Also, tile sharing will not work for all combinations of BG's tile size and sprites' size. I'm not knownledgealbe enough about SNES to give all details but you can look it up yourself.
The only reason this wasn't used much is that this was hardly ever needed. Sprites are displaying moving objects, background non-moving objects. On the older consoles like the NES sharing sprites and background tiles make sense because there's so few sprites : When an object is moving only rarely, it makes sense to draw it as background, and sprites only when it's actually moving. On the SNES there's enough sprites, so they can just use sprites even for objects which are rarely moving.
One example for such is units in Fire Emblem. On the NES version and the first SNES game, they are drawn with background, except the moving units which are then drawn with sprites. On the last 2 SNES games, as well as the GBA games, the units are just sprites, no matter whether they're moving or not; this probably greatly simplifies programming. I have no idea why they stuck to the BG/sprites changes hassle in the first SNES game, you should analyze it to see whether they re-use sprites as BG or if it's another VRAM page.
Another example is the falling blocks in Castlevania games. In Castlevania III, they are displayed as background, and when you step on them for a short time, they start to fall off, blank tiles are written to the background and the falling blocks turn into sprites so they can physically move. In Super Castlevania IV, the exact same falling blocks are simply displayed as sprites all the time, even before they start falling (to be verified, I'm only 95% sure of that ^^).
The only reason this wasn't used much is that this was hardly ever needed. Sprites are displaying moving objects, background non-moving objects. On the older consoles like the NES sharing sprites and background tiles make sense because there's so few sprites : When an object is moving only rarely, it makes sense to draw it as background, and sprites only when it's actually moving. On the SNES there's enough sprites, so they can just use sprites even for objects which are rarely moving.
One example for such is units in Fire Emblem. On the NES version and the first SNES game, they are drawn with background, except the moving units which are then drawn with sprites. On the last 2 SNES games, as well as the GBA games, the units are just sprites, no matter whether they're moving or not; this probably greatly simplifies programming. I have no idea why they stuck to the BG/sprites changes hassle in the first SNES game, you should analyze it to see whether they re-use sprites as BG or if it's another VRAM page.
Another example is the falling blocks in Castlevania games. In Castlevania III, they are displayed as background, and when you step on them for a short time, they start to fall off, blank tiles are written to the background and the falling blocks turn into sprites so they can physically move. In Super Castlevania IV, the exact same falling blocks are simply displayed as sprites all the time, even before they start falling (to be verified, I'm only 95% sure of that ^^).
Re: Sprites: SNES vs Genesis
Ahh, I see my mistake now.
Although it can share data with the background, there is still only 16K that can be used as sprites.
Wait, does that really come out to only two banks of 256 tiles? That's only double what the NES can store; that's outrageous. How did even half the games I've played even function with such a small selection of sprites?
Right off the cuff I'm guessing you can change where in the memory those two banks are, so between frames you could swap out for another set of tiles. That would be great for something like a fighting game, but anything else will leave you pressed to have the tiles you need.
Although it can share data with the background, there is still only 16K that can be used as sprites.
Wait, does that really come out to only two banks of 256 tiles? That's only double what the NES can store; that's outrageous. How did even half the games I've played even function with such a small selection of sprites?
Right off the cuff I'm guessing you can change where in the memory those two banks are, so between frames you could swap out for another set of tiles. That would be great for something like a fighting game, but anything else will leave you pressed to have the tiles you need.
Re: Sprites: SNES vs Genesis
I think both the Genesis and the SNES make heavy use of DMA to stream new patterns as needed. On the NES you had to do it manually byte by byte, so that's why CHR-RAM animations weren't so common, but when you have DMA functionality at your disposal? Run the games in emulators with VRAM viewers and you'll see how much the tiles change over time.
Re: Sprites: SNES vs Genesis
Yes, you can change where the sprite data banks are in VRAM. This might be useful for double buffering or very rapid scene changes.
In fact you can do it mid-frame to bust the 16 KB limit, but as I said it's hard to use this trick for anything other than a fake BG layer made out of sprites, so it's extremely rare.
Perhaps one of the bigger differences is that you can replace several KB of sprite data per frame with DMA. This isn't NROM, where the whole game uses one sprite table...
In fact you can do it mid-frame to bust the 16 KB limit, but as I said it's hard to use this trick for anything other than a fake BG layer made out of sprites, so it's extremely rare.
Perhaps one of the bigger differences is that you can replace several KB of sprite data per frame with DMA. This isn't NROM, where the whole game uses one sprite table...
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Sprites: SNES vs Genesis
Donkey Kong Country had 3 types of animated sprites (normal, bananas/HUD, and bosses). Normal sized sprites can take up to 1kB at maximum, and there can be up to 14 of them onscreen at once. Bananas and HUD take 2kB all together and they are statically located. Bosses animate similar to normal sized sprites, but they take up 2 normal sized enemy slots instead of one. During game logic, it predicts when DMA overflow happens, so instead of DMA causing black bar glitches it delays the animation instead. If you're playing in slow motion, you can sometimes see Donkey Kong or Diddy Kong float for a frame before their jumping animation begins.Marscaleb wrote:Ahh, I see my mistake now.
Although it can share data with the background, there is still only 16K that can be used as sprites.
Wait, does that really come out to only two banks of 256 tiles? That's only double what the NES can store; that's outrageous. How did even half the games I've played even function with such a small selection of sprites?
Right off the cuff I'm guessing you can change where in the memory those two banks are, so between frames you could swap out for another set of tiles. That would be great for something like a fighting game, but anything else will leave you pressed to have the tiles you need.
Dracula X is pretty interesting. The main player animates with DMA like Donkey Kong Country does, but the enemies don't use DMA except when changing rooms. Rooms can't have too many distinct enemy types or else they won't fit in VRAM. Weapons get DMA'ed during weapon changes. The interesting thing about this game is that the enemies are actually a combination of traditional frame by frame animation and multijointed sprites.
Re: Sprites: SNES vs Genesis
SNES Dracula XX is re-using a ton of graphics from the PC Engine Dracula X game (which is an entirely different game aside from that). I'm pretty sure all the multijointed enemies in the game are carried over directly from the earlier game, so it made sense to do it the same way.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Sprites: SNES vs Genesis
https://www.youtube.com/watch?v=jlkzy9cIB5o
The first skeletons you come accross recycle the same body parts between frames, but changes the location of the body parts relative to eachother.
The first skeletons you come accross recycle the same body parts between frames, but changes the location of the body parts relative to eachother.
Re: Sprites: SNES vs Genesis
- and those skeletons are coincidentally completely recycled from Rondo on PC Engine
Re: Sprites: SNES vs Genesis
Genesis has the SNES beat in the sprites department overall.
Flexibility of sprites in ram vs the snes bank layout really comes into play when you need more unique detail on screen via sprites (instead of just the same reference). It allows better option for more frames in vram without always uploading frames to vram. It allows more flexibility for double buffer large sprites (Neo Geo fighters) - only 16k for sprites hurts.
The limit of two sprite sizes really dampers the SNES, especially considering they're power of 2 sizes. Genesis flexibility to have 8, 16, 24, 32 in either row/col setup allows a game to maximize for sprite realstate without sprite drop out/flicker. It really allows you to drill down and optimize for scanline limit (Streets of Rage 2 and 3 are damn impressive in this respect).
Snes' 34/272 pixel limit looks great on paper, but limited to two choice sprite size really makes it less optimal than it appears. That's not to say it doesn't have edge cases which it is optimal, but it's an outer edge case compared to general case. Give the OAM is 128 entries, 8x8 and 16x16 is the most optimal choice, then there's the snes' slower cpu and oam format overhead. From what I've seen, 16x16 paired with 32x32 is pretty common on the snes - which puts it pretty much on par with the PCE (but lacks the vram flexbility of the PCE for sprites, and PCE also has additional 16x32, 16x64, and 32x16 sizes.. so even the PCE edges it out in general case ). 16x16/32x32 is also wasteful on vram too if you have 8x8 areas inside those sprites that have all transparent pixels (24x24 sprite using 32x32 format).
I have a trick on the PCE (VDC reg settings) that makes it show sprites at half vertical res (it skips every other line of the sprite), allowing 16x8, etc. Basically it skips every other line. So, bit #0 if the Y position because kind of a bank select per sprite (which interleaved set of lines to show for that specific sprite). You lose the XX by 64 height, but it's not generally useful size.
Flexibility of sprites in ram vs the snes bank layout really comes into play when you need more unique detail on screen via sprites (instead of just the same reference). It allows better option for more frames in vram without always uploading frames to vram. It allows more flexibility for double buffer large sprites (Neo Geo fighters) - only 16k for sprites hurts.
The limit of two sprite sizes really dampers the SNES, especially considering they're power of 2 sizes. Genesis flexibility to have 8, 16, 24, 32 in either row/col setup allows a game to maximize for sprite realstate without sprite drop out/flicker. It really allows you to drill down and optimize for scanline limit (Streets of Rage 2 and 3 are damn impressive in this respect).
Snes' 34/272 pixel limit looks great on paper, but limited to two choice sprite size really makes it less optimal than it appears. That's not to say it doesn't have edge cases which it is optimal, but it's an outer edge case compared to general case. Give the OAM is 128 entries, 8x8 and 16x16 is the most optimal choice, then there's the snes' slower cpu and oam format overhead. From what I've seen, 16x16 paired with 32x32 is pretty common on the snes - which puts it pretty much on par with the PCE (but lacks the vram flexbility of the PCE for sprites, and PCE also has additional 16x32, 16x64, and 32x16 sizes.. so even the PCE edges it out in general case ). 16x16/32x32 is also wasteful on vram too if you have 8x8 areas inside those sprites that have all transparent pixels (24x24 sprite using 32x32 format).
I have a trick on the PCE (VDC reg settings) that makes it show sprites at half vertical res (it skips every other line of the sprite), allowing 16x8, etc. Basically it skips every other line. So, bit #0 if the Y position because kind of a bank select per sprite (which interleaved set of lines to show for that specific sprite). You lose the XX by 64 height, but it's not generally useful size.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Sprites: SNES vs Genesis
I'm guessing a good rule of thumb is, if you're using a lot of sprites onscreen in an SNES, avoid making the main character or 'regular' sized enemies more than 32 pixels wide, per line, unless the enemy is supposed to be intimidatingly huge or if you absolutely need to.
Re: Sprites: SNES vs Genesis
So, could you place the HUD graphics for a game onto some free space in the 4bpp background layer's tileset and then use sprites with those background tile graphics for the actual in-game HUD, thereby still allowing the HUD that's made of sprites to appear over all the normal background layers while saving a little of the limited VRAM normally allocated to sprite tiles?Bregalad wrote: ↑Wed Aug 08, 2018 1:41 am Sprites can be shared with background but only in some modes where the backgrounds are 4BP, in practice that means background 1 and 2 of mode 1 and mode 2, as well as background 2 of the rarely used mode 3. (Mode 5 also uses a 4BP background but it's hi-res so re-using the same data as sprites won't look the same, harldy useful at all). Also, tile sharing will not work for all combinations of BG's tile size and sprites' size. I'm not knownledgealbe enough about SNES to give all details but you can look it up yourself.
The only reason this wasn't used much is that this was hardly ever needed. Sprites are displaying moving objects, background non-moving objects. On the older consoles like the NES sharing sprites and background tiles make sense because there's so few sprites : When an object is moving only rarely, it makes sense to draw it as background, and sprites only when it's actually moving. On the SNES there's enough sprites, so they can just use sprites even for objects which are rarely moving.
One example for such is units in Fire Emblem. On the NES version and the first SNES game, they are drawn with background, except the moving units which are then drawn with sprites. On the last 2 SNES games, as well as the GBA games, the units are just sprites, no matter whether they're moving or not; this probably greatly simplifies programming. I have no idea why they stuck to the BG/sprites changes hassle in the first SNES game, you should analyze it to see whether they re-use sprites as BG or if it's another VRAM page.
Another example is the falling blocks in Castlevania games. In Castlevania III, they are displayed as background, and when you step on them for a short time, they start to fall off, blank tiles are written to the background and the falling blocks turn into sprites so they can physically move. In Super Castlevania IV, the exact same falling blocks are simply displayed as sprites all the time, even before they start falling (to be verified, I'm only 95% sure of that ^^).