Is the (acd) arcade card worth it? Sapphire and Strider

[Black Tiger]

I think that in ports like Forgotten Worlds, Dynasty Warriors, Strider, likely Chiki Chiki Boys, etc, the development teams ported many/most sprites straight across. So if the CPS1 version just piled on an extra sprite for animation on a character, then they simply ported over both sprites instead of catering more to the PCE hardware. Which is surprising, considering how well they handled other aspects of the games.

But most PCE developers seemed to only know how to do a certain number of things and then totally blank on something common in other games.

[sheath]

I guess it wouldn't matter for an Arcade Card game, but it just seems like combining the sprite for Hiryu and the Cypher would require a huge amount of excess/duplicate pixels in ROM.  Especially since there would have to be two full sets for the short and long Cypher animations.  It seems more efficient for ROM to have the Cypher separate. 

[Black Tiger]

I guess it wouldn't matter for an Arcade Card game, but it just seems like combining the sprite for Hiryu and the Cypher would require a huge amount of excess/duplicate pixels in ROM.  Especially since there would have to be two full sets for the short and long Cypher animations.  It seems more efficient for ROM to have the Cypher separate. 

Since all visible sprite objects are actually cobbled together from various sizes of smaller sprites, not much would need an alternate sprite section. For both of Strider's main character "sprite" poses, there is only one small section that requires new art when the sword is fully extended. But that small section could equal the width of an entire extra character standing still.

The problem isn't so much the overlapping section, as it is poor sprite design overall. Like that enemy sprite. Without any object overlapping to remove, it still could be reduced a noticeable amount. In something like a beat em up, that can mean the difference between a 1 player game and a 2 player game. Which is huge gameplay-wise.

A good example of wasting sprite line limit space is the player sprite in Dynasty Warriors. I believe that the rider and horse are rendered separately. Even though you never(?) dismount.

[sheath]

I wasn't thinking when I wrote that.  Tiles can probably be reused even if the cypher sprite were combined with the Hiryu sprite in rendering.  We're talking about how the video is displayed by the Hu6270 and its inherent sprite per scanline limits.  Nevermind me, meehhhr NEC Avenue was stoopid. 

[Black Tiger]

I wasn't thinking when I wrote that.  Tiles can probably be reused even if the cypher sprite were combined with the Hiryu sprite in rendering.  We're talking about how the video is displayed by the Hu6270 and its inherent sprite per scanline limits.  Nevermind me, meehhhr NEC Avenue was stoopid. 

The other reason why sprite efficiency is important for PCE games is that they rely on sprites to do layered background effects and/or large bosses more than the MD and SFC.

[sheath]

Maybe somebody can help me out with this one.  Nimai Malle's pce_doc says that 16 pixel wide sprites are aligned as 32 pixel wide, does that mean that the system thinks the sprites are 32 wide no matter what?  The sprite per scanline limit is supposed to be 16, but if the HuC6270 sees them all as 32 pixels wide does that mean that the real limit is 8 sprites per scanline?

[Black Tiger]

Maybe somebody can help me out with this one.  Nimai Malle's pce_doc says that 16 pixel wide sprites are aligned as 32 pixel wide, does that mean that the system thinks the sprites are 32 wide no matter what?  The sprite per scanline limit is supposed to be 16, but if the HuC6270 sees them all as 32 pixels wide does that mean that the real limit is 8 sprites per scanline?

I no technical expert, but I think that it's safe to say that the functional limit isn't 8 sprites per line, judging by the games that have been released.

[ccovell]

The real limit is 256 pixels of sprites per scanline.  That can break down into 16 16-pixel sprites, or 8 32-pixel sprites.

[Bonknuts]

Maybe somebody can help me out with this one.  Nimai Malle's pce_doc says that 16 pixel wide sprites are aligned as 32 pixel wide, does that mean that the system thinks the sprites are 32 wide no matter what?  The sprite per scanline limit is supposed to be 16, but if the HuC6270 sees them all as 32 pixels wide does that mean that the real limit is 8 sprites per scanline?

 The number of sprites per line is a maximum of 16, in a specific and best optimized situation. Because the width of the sprite is variable (not fixed, like 8bit consoles), the maximum number of sprites per scanline is also variable. This isn't unlike the SNES or the Genesis either in that respect. It's easier to think of sprite "cells" per line, rather than actual sprite entries per line. The smallest sprite cell on the TG/PCE is 16 pixels wide. The maximum sprite cells per scanline (normal conditions, excluding funky dual scanline per normal scanline modes - as they are mostly useless) is 16. 16pixels x 16 = 256 pixels (scanline buffer). It's this scanline buffer that prevents more cells from being shown on a single scanline. If you have 240 pixels of the buffer used up on a given scanline (fifteen sprite cells) and you place a 32 wide sprite on that same line, then the last cell of that 32 wide sprite will drop off. You'll only see the first 16 pixels of that 32pixel wide sprite. Because sprite sizes are made up of sprite cells, not real *different* sprite width rows and columns. The Genesis and SNES are exactly like this too. It's easiest to think of this as a chain of connected sprite cells that's done in hardware, rather than software. It also makes a smaller SAT (sprite attribute table) more efficient. A single SAT entry can use a sprite configuration of 32x64. That saves the SAT of 7 additional entries if you did it by software (which WOULD make 64 total sprite entries much more limiting without this hardware feature).

 So, sixteen 16 wide pixel sprite cells per scanline. The number of "SAT" sprites per scanline is variable when you start mixing sprite sizes. The minimum would be 8 sprites per scanline if all you ever used were 32 wide sprites. Relative to the Genesis and SNES, they use a sprite cell size of 8 pixels wide. The Genesis has more in between sprite sizes. Bonk for examples, takes about 24 pixels wide for the widest frames - yet he is drawn on a 32 pixel wide setup on the PCE - you've got 8 pixels of blank space that's eating into scanline buffer limit. On the Genesis, you can select a specific size of 24 pixels (three 8pixels wide cells) and be more efficient with the sprite bandwidth per scanline (though the scanline buffer is still the same; the width of the screen: 256 pixels). Though the Genesis has more limitations in the fetch design, making the number of sprites per line more complicated than the PCE. Regardless of the sprite "width", the Genesis VDP will only show 16 sprite per scanline in low res mode (20 per high res mode). So the advantage isn't as automatic as you think it would be, though high res mode is more flexible on the Genesis than its low res mode. The SNES also uses 8 pixel wide sprite cells, but the maximum sprite cells per scanline is higher than the scanline width itself - it's 34 eight pixel wide sprite cells per scanline. The number of SAT (Nintendo calls it OAM) entries are 32 per scanline. So the SNES could optimize for more smaller objects per scanline than both the Genesis or TG16 and that's why the SAT(OAM) size is a total of 128 entries (seen as 128 sprites per screen in specs). It's needed for when you have a lot of 8x8 sprites on screen. The problem is the overheard of that on the processor. That and you can only have two sprite sizes selected per screen at a time, unlike the TG16 and Genesis. So choose a flexible 16x16 and 32x16 set size and kill alot of your advantage of that SNES sprite cell size, or go with a 8x8 & 16x16 and eat/burn through your processor resource and OAM table (sprites per screen).

 Of the three system's sprite per scanline limit, the PCE is easiest to understand/visualize(no pun intended). There's another system that's similar enough to compare with the PCE's sprite setup. The X68000 computer. It has a SAT of 128 entries (double PCE's). It also has a sprite cell size of 16x16, just like the PCE. But it has a sprite scanline buffer of 512 pixels or 32 sprite cells (double the PCE's). This might sound pretty good, and it is, but there's a downfall to the X68k. It only has a sprite size in the SAT of 16x16. It can only use the base cell size and nothing larger. This means you'll eat through the SAT pretty quickly because you need to make the 32x32 objects or larger, in 4 or more SAT entries. It also means more overhead on the CPU (software meta-sprite handling). It also directly limits how much sprite pixels you can have on screen: 128 SAT entries * 256 pixels (16x16 sprite cell) = 32768 pixel coverage (not square). To put that into a square, that's a maximum single 181x181 window/area (or 256x128 as an easier number to visualize). Now put that into the context of a game running in 384 pixel mode on the X68k (768 pixel mode with half dot clock speed setting). Pixel per screen width ratio becomes even more of a limitation for sprites coverage in that resolution (vs 256 pixel mode) where the 16x16 sprite cells are now 1/3rd their original width in display (seems a lot of games on the X68 use the higher 384 res mode for games).

In contrast, the PCE's maximum sprite pixel coverage is 131072 pixels (all 64 SAT entries using 32x64 sprites) or a maximum single 362x362 pixel area (more than what can be shown onscreen). A typical 32x32 configuration yield is 65536 pixel coverage or 256x256 pixel area (still larger than the low res screen mode of 256x240). The X68k is also hard segmented for sprite and BG addresses in vram (unlike the PCE's place it anywhere/make up your own vram segmentation rules). It's a pretty big difference between the two. It's an interesting comparison because if you look at the systems; one has a much better sprite system (PCE) but with a weaker scanline buffer and the other has a poor sprite setup but with a stronger scanline buffer and an additional BG layer. I always thought the x68k was pretty similar to the CPS1 hardware, but now I know it's nowhere near as close.

[sheath]

Bonknuts, thank you for that.  I was wondering if the maximum sprites per screen and the sprites per scanline worked out that simply (how many pixels are on screen/per scanline).  These systems rendered sprites and backgrounds in 8x8 cells, but the TG16/PCE's minimum sprite size is 16x16 and all of the larger sprite sizes are multiples of that.  This means that for anything smaller than 16x16 transparent pixels must be used (wasted).  This explains to me why beat-em ups in particular have only three enemies plus the main character on screen on the PCE.  

In games like Final Fight CD with five characters on screen there is some sprite flicker when multiple weapons/objects are on the ground and five characters are on screen.  The VDP can render these objects as 8x8, 16x8, 24x8 or 32x8 wide sprites, whereas they would be either 16x16 or 16x32 on the PCE, soaking up a lot more sprite pixels than would be ideal and limiting how many character sprites could be on screen at the same time.  The SNES has the same limited number of enemies and objects on screen, but I suppose that is actually due to the slower CPU clock speed, and the somewhat limited "either or" double pixel sprite settings (or "bad" programming).

So, in comparison to the Genesis in particular, the PCE allows for the possibility for larger sprites at the expense of fewer total on screen for effects like explosions or a bunch of smaller objects/enemies even in the Genesis' low res mode.  This becomes more pronounced in games that use sprites for parallax layers or scrolling background objects, as the Genesis can use its two backgrounds and cell scroll/priority settings to handle most background effects.  The Genesis has every sprite size from 8x8 to 32x32 in multiples of 8 pixel increases, which kind of explains why so many games have smaller sprites with a bunch of "detail" sprites for explosions and other objects.  Whereas the PCE has the advantage of the 32x64 sprite size for larger sprites, which the Genesis would have to build out of at least two sprites.  

[Black Tiger]

Bonknuts, thank you for that.  I was wondering if the maximum sprites per screen and the sprites per scanline worked out that simply (how many pixels are on screen/per scanline).  These systems rendered sprites and backgrounds in 8x8 cells, but the TG16/PCE's minimum sprite size is 16x16 and all of the larger sprite sizes are multiples of that.  This means that for anything smaller than 16x16 transparent pixels must be used (wasted).  This explains to me why beat-em ups in particular have only three enemies plus the main character on screen on the PCE. 

In games like Final Fight CD with five characters on screen there is some sprite flicker when multiple weapons/objects are on the ground and five characters are on screen.  The VDP can render these objects as 8x8, 16x8, 24x8 or 32x8 wide sprites, whereas they would be either 16x16 or 16x32 on the PCE, soaking up a lot more sprite pixels than would be ideal and limiting how many character sprites could be on screen at the same time.  The SNES has the same limited number of enemies and objects on screen, but I suppose that is actually due to the slower CPU clock speed, and the somewhat limited "either or" double pixel sprite settings (or "bad" programming).

So, in comparison to the Genesis in particular, the PCE allows for the possibility for larger sprites at the expense of fewer total on screen for effects like explosions or a bunch of smaller objects/enemies even in the Genesis' low res mode.  This becomes more pronounced in games that use sprites for parallax layers or scrolling background objects, as the Genesis can use its two backgrounds and cell scroll/priority settings to handle most background effects.  The Genesis has every sprite size from 8x8 to 32x32 in multiples of 8 pixel increases, which kind of explains why so many games have smaller sprites with a bunch of "detail" sprites for explosions and other objects.  Whereas the PCE has the advantage of the 32x64 sprite size for larger sprites, which the Genesis would have to build out of at least two sprites. 

It's all about planning. An original beat 'em up could turn out better than a port if it was planned from the ground up around the PCE hardware, the way that Streets of Rage was done. AI could be told not to pile up more than a certain number of characters horizontally, allowing 2 players to each fight up to 3 enemies at different horizontal positions of the screen.

In theory, the worst kind of game for the PCE to handle, flicker/break-up-wise, would be horizontal shooters. The whole point of the game is to line up sprites horizontally and most shooters have bullets that are smaller than 16 pixels wide. But there are enough sprite intensive horizontal shooters for the PCE to show how much can be done with good planning.

[sheath]

With something like this though, I'm inclined to say that there was a technical reason why no beat-em ups on the SNES or PCE had more than three enemies on screen at once.  We know that the PCE could push plenty of sprites around though, thanks to shooters like Sapphire and Gate of Thunder and Side Scrollers like Ninja Spirit.  Sprite size limitations makes more sense than "bad programming" does to me.  That's not to say that must be the reason just because it makes sense to me though.

[Bonknuts]

Bonknuts, thank you for that.  I was wondering if the maximum sprites per screen and the sprites per scanline worked out that simply (how many pixels are on screen/per scanline).  These systems rendered sprites and backgrounds in 8x8 cells, but the TG16/PCE's minimum sprite size is 16x16 and all of the larger sprite sizes are multiples of that. This means that for anything smaller than 16x16 transparent pixels must be used (wasted).

 Exactly! You have invisible pixels eating into your bandwidth for that scanline. So a small 4x4 or 5x5 bullet is using a whole 16x16 sprite. That kind of bullet could easily fit into a 8x8 sprite cell. A very few handful of PCE games do composite bullets in a fancier manner than normal. That is to say; two or more small objects may occupy a single 16x16 sprite. Of course this normally means they need to have the same velocity and acceleration if they are going to keep sharing that same sprite cell ( a simple palette association change can be made to 'turn off' either of the meta objects inside that single cell, if a collision were to happen). A more complicated process would be to have them break off into individual sprite cells when they eventually move apart and/or even have them move inside the sprite cell itself. Think of Gate of Thunder and that reoccurring enemy/ship that blast you with a ton of condensed bullets (he's also in the ending cinema) or Steam Hearts clustered bullets. You could either store the frames needed for this type of repetitive action or brute force with some code (manual compositing).

 Of course there are some other tricks that are commonly used (on the SNES and Genesis too and even older 8bit consoles). One is to take advantage of the fresh rate. 60hz is quite fast. Taking a shmup into example: if you have a weapon that fires a stream of bullets, you can make the distance between each shot be exactly 1 bullet spacing in segments but skip every other segment... but also make the movement/speed of the bullet exactly that of 1 segment. Always filling the gap to the human eye; at 60hz this gives the illusion of a lot of streaming bullets. This is also why quite a few shmups looks less impressive in 30p (frame drop... like youtube videos) than 60p.

In games like Final Fight CD with five characters on screen there is some sprite flicker when multiple weapons/objects are on the ground and five characters are on screen.  The VDP can render these objects as 8x8, 16x8, 24x8 or 32x8 wide sprites, whereas they would be either 16x16 or 16x32 on the PCE, soaking up a lot more sprite pixels than would be ideal and limiting how many character sprites could be on screen at the same time.  The SNES has the same limited number of enemies and objects on screen, but I suppose that is actually due to the slower CPU clock speed, and the somewhat limited "either or" double pixel sprite settings (or "bad" programming).

 Yeah, not just horizontal builds of 8 pixels cells, but vertical as well. That can help out quite a bit too. Why the PCE doesn't have an option for this is a little baffling. I can understand hardcoded logic for 16 wide pixels (sprites are made with a single 16bit fetch in mind, four 16bit fetches gives 16pixels row @ 16colors), but vertical height is just a matter of an internal counter. The VDC could have been made to do one or the other 16 or 8 pixel high cells via a switch(reg). Hell, I was able to setup the VDC in such a manner that it actually did this (by getting it to skip the current scanline of sprites and do the next. Effectively all sprites onscreen half height and interleaved vertically). But hindsight is 20/20. Having more height than what's needed increases the chance of sprite overflow. Having a 8pixel segment height option for sprite cells would benefit horizontal shmups as well.

 

So, in comparison to the Genesis in particular, the PCE allows for the possibility for larger sprites at the expense of fewer total on screen for effects like explosions or a bunch of smaller objects/enemies even in the Genesis' low res mode.  This becomes more pronounced in games that use sprites for parallax layers or scrolling background objects, as the Genesis can use its two backgrounds and cell scroll/priority settings to handle most background effects.  The Genesis has every sprite size from 8x8 to 32x32 in multiples of 8 pixel increases, which kind of explains why so many games have smaller sprites with a bunch of "detail" sprites for explosions and other objects.  Whereas the PCE has the advantage of the 32x64 sprite size for larger sprites, which the Genesis would have to build out of at least two sprites.  

 Having a 32x64 option is nice, but to be honest I rather have something similar to the Genesis cells sizes. Even if it was a simpler 16x8 cell size (I can do this now since I figured it out, though no emulator handles this. Mednafen can do a slightly different mode that does the same thing to sprites though. And it has a slight offset for clipping on the screen). The SNES can be really optimized, but in the same vain it has quite a bit of limitations. And here's the sprite size options for the SNES:

Code: [Select]

           000 =  8x8  and 16x16 sprites
            001 =  8x8  and 32x32 sprites
            010 =  8x8  and 64x64 sprites
            011 = 16x16 and 32x32 sprites
            100 = 16x16 and 64x64 sprites
            101 = 32x32 and 64x64 sprites
            110 = 16x32 and 32x64 sprites ('undocumented')
            111 = 16x32 and 32x32 sprites ('undocumented')

 You can only chose those pairs. Nothing else. And it's for the whole screen. Notice all the sprite cell heights (besides 8x8) are multiples of 16 like the PCE. The 8x8/16x16 mode is what I was referring to for sprite optimization (which even a 128 OAM size is still a bit too small for). Else, 16x16/32x32 looks like it would be the most common mode besides that. And in that case, I'd take the PCE's sprite setup over that. At least on the PCE you have the option of 32x16 and along side 32x32 and 16x16 (and 16x32 and 16x64). While the PCE has some rules for alignment of larger sprites sizes, the SNES actually has vram segmented separately for sprites. You have no control over vram layout of BG tile data and sprite cell data (and they're segmented). In many respects, the Genesis sits in the middle of SNES and the PCE for sprites. While it doesn't have the impressive capability of the SNES 34 cell / 32 sprite per scanline entry, it does have the 8x8 cell segment setup and it has it in a more flexible setup of sizes per screen (all of them available) like the PCE.

This explains to me why beat-em ups in particular have only three enemies plus the main character on screen on the PCE.

 

 Typically (as if the PCE had that many beat-em ups ), yeah. But if a game was designed from the ground up with attention to detail specifically on optimization of sprite management (like the SOR games), then you'd see more of an arrangement of enemies on screen.

 Here's a test I did a number of years ago:


 I rescaled the character for low res mode. I trimmed and fixed where necessary to fit the character into a 32pixel wide cell for his normal stance (two cells wide). The punch animation is 48pixels wide for part of the upper torso region (3 cells wide):


 In the first image, there are 7 objects of 2 cells wide each. I packed them close enough to give an example of a cluster of enemies. That gives a total scanline buffer of 14 sprite cells, leaving room for the character in red and one character in yellow to both punch at the same time - without any sprite cell drop out. Of course you probably wouldn't be fighting 6 enemies at a time that close together. I'd have the AI move some of the enemies to the top or bottom of the screen and wait for their turn (or fight with player #2). Enemies would fly fairly far back when getting knocked to the ground (like later SOR games), in hopes of putting them off screen. Because an enemy laying on their back takes a longer horizontal layout of sprite cells. The AI can be sneaky and keep that enemy off screen even after it recovers (assuming it recovers) and bring it back in when less enemies are on screen or park it near the top. I didn't make any of this up. I simply observed the impressive sprite management of SOR 2 and SOR 3. The real beauty in these games, is that they make it look natural. Very impressive indeed.

 Edit: Just to clear up any misunderstandings, sprite drop out happens per scanline. Not per sprite cell block. This is because all sprite data is refetched and calculated per scanline. It's possible to have only 1 vertical line of overflow/dropout/flicker and at a minimum of 16 pixels wide. If the whole cell height of 16 pixels dropped out, that would look pretty noticeable as well as terrible.

[sheath]

That's an awesome demonstration with the Adam sprites.  Was that shot running on hardware or emulation, or is it an example picture?  I wonder what a game would be able to manage, definitely more than the usual three enemies, but probably less than Streets of Rage's 8-12 enemies plus two main characters and objects. 

Riot Zone gets plenty busy in comparison to SNES beat-em ups, I enjoy playing it just fine.  I'd also love to own Double Dragon II, I just can't justify the cost right now. 

[Black Tiger]

That's an awesome demonstration with the Adam sprites.  Was that shot running on hardware or emulation, or is it an example picture?  I wonder what a game would be able to manage, definitely more than the usual three enemies, but probably less than Streets of Rage's 8-12 enemies plus two main characters and objects.

The Genesis can't display any more sprites horizontally at the resolution of the SoR games than the PCE can line up at the 256 pixel width resolution. So as long as you don't make the character sprites wasteful of the PCE's sprite sizes, it should be able to do something comparable. But the only time I remember seeing that many characters on-screen in a SoR game, there was slowdown and flicker. Objects can remain as tiles until destroyed or picked up. Beat 'em ups don't require much parallax to look good, but urban settings are more dynamic-tile-friendly anyway.

Riot Zone gets plenty busy in comparison to SNES beat-em ups, I enjoy playing it just fine.  I'd also love to own Double Dragon II, I just can't justify the cost right now.  

Not that Riot Zone is very polished, but it used large characters, so there's less sprite room to throw around. The SoR games worked well because they had lots of smaller and narrower enemies to mix up with various other sized enemies in various combinations. When all of the sprites are big and wide, there's not much you can do from there to put more enemies on-screen.

Something like River City Ransom is perfect for maximizing the number of on-screen characters, but I doubt that the PCE version used more than the Famicom version.

If RED had developed a Hudson backed brawler, it would have been as good as anything from that generation.