It is currently Mon Aug 20, 2018 2:04 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Tue Aug 07, 2018 1:52 pm 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 259
Location: Seattle
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


Top
 Profile  
 
PostPosted: Tue Aug 07, 2018 2:48 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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.

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.

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.

Marscaleb wrote:
They both are looking at the same amount of memory for sprites

...no?

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.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 1:05 am 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 124
adam_smasher wrote:
Marscaleb wrote:
They both are looking at the same amount of memory for sprites

...no?

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.


Eh? Then what's this:
tepples wrote:
Marscaleb wrote:
And how much memory does the system have that can be used for sprites; how many tiles could be used for sprite data?

Genesis: 64 KiB; always shared with background
Super NES: 16 KiB out of 64 KiB; can optionally be changed mid-screen or shared with background

If that's the case, then what stops a game from sharing data like the Genesis?


Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 1:40 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 1:41 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7473
Location: Chexbres, VD, Switzerland
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 ^^).


Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 5:19 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 124
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.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 5:32 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10716
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Wed Aug 08, 2018 5:34 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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...


Top
 Profile  
 
PostPosted: Tue Aug 14, 2018 12:14 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2731
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.


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.

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.


Top
 Profile  
 
PostPosted: Wed Aug 15, 2018 12:37 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 694
Location: Denmark (PAL)
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.


Top
 Profile  
 
PostPosted: Thu Aug 16, 2018 9:22 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2731
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.


Top
 Profile  
 
PostPosted: Fri Aug 17, 2018 3:29 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 694
Location: Denmark (PAL)
- and those skeletons are coincidentally completely recycled from Rondo on PC Engine ;)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group