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

[CrackTiger]

The PCE version of Strider looks and feels unfinished. It has lots of extra art and detail from the arcade that is missing from the Genesis version, but it uses a horrible color palette.

It actually looks nice in stills when recolored. It also has terrible sprite optimization and has unecessary sprite break up/flicker as a result. All of that wouldn't be so bad, except that the framerate/scrolling is messed up. I don't know if it runs at 30fps or not, but either way it looks like it isn't scrolling at the kind of integers that regular games do.

I don't think that any version of of arcade Strider is very good, so the gameplay doesn't seem worse to me.

[Dyna138]

PCE Strider has a few qualities in its favor, but the graphics are a little disappointing since I expect better from the ACD. It's still a great version of the game to play for the extra level, CD soundtrack and cutscenes. Depending on what system you favor you may prefer one over the other.

Personally I love to play different versions of my favorite games to see how they compare to each other and I love when they take advantage of the CD format and add some extra goodies not in the arcade.

[blueraven]

I just beat PS1 Strider. The game is badass.

Having fun with Strider 2 as well

[Tatsujin]

I played the Genesis Strider and wasn't all that impressed. I am hoping the PCE version is way better. I just need to track it down.

As stated before, there is no hope. But if you like to spend like 60 bucks+ extra for finding it out by yourself, go ahead

If you want the definite strider conversion, buy "strider hiryu 1&2" for the PS1.

[turbogrfxfan]

Yeah I wanted strider for many years now and I finally got it a few weeks ago and wasn't disappointed at all. The games pretty easy once u figure out what to do. The last stage is a lot of fun and you gotta chip away at it.but isd more fun than tough. Is it worth 60????  Well imo this game is a hell of a lot beTter than some bitch flying around on a broomstick for 150 bucks....  Pce version

[RR1980]

Yeah I wanted strider for many years now and I finally got it a few weeks ago and wasn't disappointed at all. The games pretty easy once u figure out what to do. The last stage is a lot of fun and you gotta chip away at it.but isd more fun than tough. Is it worth 60????  Well imo this game is a hell of a lot beTter than some bitch flying around on a broomstick for 150 bucks....  Pce version

you can get that cotton bitch for alot less than $150 and she will bring her pixie fairy friend too hehe

[turbogrfxfan]

No I'm talkin about mc for pce but I hear ya:)

[RR1980]

No I'm talkin about mc for pce but I hear ya:)

haha I know tfan ;-)

[SNKNostalgia]

Also, arcade version of Strider is on Capcom Classics Collection Vol. 2. It also supports 480P and has a few extras. So I guess that would be the best version next to playing the PS1 version on a PS3 with progressive scan maybe.

I never got to play Strider until 94 when I borrowed a friend's Genesis due to just owning a SNES and TG-16 (Finally got my Genesis with a SegaCD on the cheap in 96). I enjoyed the game a bit I guess. Then I finally played the arcade version for the first time with the PS1 Strider 1 and 2 release 11 years ago. Funny how the disc labels where switched with my copy. I liked it a lot more than the Genesis version, but still didn't think it was all too spectacular. I guess the game just aged poorly in some ways by that time. I was more of a fan of games like Final Fight from those days and still am. I also preferred other Capcom platform action games more, GnG series or Magic Sword. I would maybe appreciate it a bit more if I had played it in the arcades back in '89 or so.

[nat]

Funny how the disc labels where switched with my copy.

If I'm not mistaken, the labels are switched on all the copies. Mine are like that too.

[sheath]

I was crazy about Strider from the first time I played the Arcade version back in '89.  The fluidity of the gameplay and the animation during all of the jumps and slides and strikes just really drew me in, seconded by the unique and well thought out level designs.  I am convinced that Sonic the Hedgehog would not exist as is without the inspiration of Strider, I saw the similarities in basic level designs and gameplay as soon as I played Sonic 1.  The whole concept of being able to move forward never stopping and being able to dodge everything was unprecedented, or at least under represented, at the time.  

I consider Shinobi III the only nearest neighbor to Strider when it comes to Action Platformers with this kind of extreme action emphasis.  When I play a 3D Action game today I always compare them to Strider or Shinobi III and so far not one game has lived up to them.  Cinematics be damned.

[TurboXray]

The PCE version of Strider looks and feels unfinished. It has lots of extra art and detail from the arcade that is missing from the Genesis version, but it uses a horrible color palette.

It actually looks nice in stills when recolored. It also has terrible sprite optimization and has unecessary sprite break up/flicker as a result. All of that wouldn't be so bad, except that the framerate/scrolling is messed up. I don't know if it runs at 30fps or not, but either way it looks like it isn't scrolling at the kind of integers that regular games do.

I don't think that any version of of arcade Strider is very good, so the gameplay doesn't seem worse to me.

Yeah, a couple of areas of the design are unpolished. But the most important area that's lacking is gameplay in my opinion. Played a lot of the Genesis and Arcade versions BITD. But yeah, poor palette choices and poor sprite management doesn't help it either. And the date it was released, the hype around it, the extra hardware it used, etc, doesn't help expectations either.
http://www.pcedev.net/sprite_management/strider/enemy1_comparison.png
http://www.pcedev.net/sprite_management/strider/sword_swing_comparison.png
http://www.pcedev.net/sprite_management/strider/sword_swing_crouch_comparison.png

[DirkFunk]

I consider Shinobi III the only nearest neighbor to Strider when it comes to Action Platformers with this kind of extreme action emphasis.  When I play a 3D Action game today I always compare them to Strider or Shinobi III and so far not one game has lived up to them.  Cinematics be damned.

I agree, most (if not all) 3D action games are inferior to Strider and Shinobi III.

Why has Capcom not released a Strider 3? Why hasn't Sega made a more straight forward Shinobi game? I liked the PS2 one (I am in the minority I think). I realize game design has "evolved" but there are so many great aspects of those games that would translate wonderfully to modern games.

[CrackTiger]

I consider Shinobi III the only nearest neighbor to Strider when it comes to Action Platformers with this kind of extreme action emphasis.  When I play a 3D Action game today I always compare them to Strider or Shinobi III and so far not one game has lived up to them.  Cinematics be damned.

I agree, most (if not all) 3D action games are inferior to Strider and Shinobi III.

Why has Capcom not released a Strider 3? Why hasn't Sega made a more straight forward Shinobi game? I liked the PS2 one (I am in the minority I think). I realize game design has "evolved" but there are so many great aspects of those games that would translate wonderfully to modern games.

This is as close as you are going to get to Strider 3.

Sega is working on a more straight forward Shinobi right now.

[roflmao]

  Moon Diver looks insane!

[sheath]

Eh, Moon Diver and Strider 2 (PS1) feel like sequels to Run Saber to me, I can't put my finger on what's missing.  I guess I just like the whole aspect of slide tackling, doing an aerial somersault, landing in the midst of enemies and slashing them all to bits that Strider does so well and so often.  Shinobi III adds the eight shuriken throw and the guard to the mix but keeps the same gameplay flexibility.  I like this gameplay so much that I still enjoy playing Strider ACD even though it is slower.

[CrackTiger]

Eh, Moon Diver and Strider 2 (PS1) feel like sequels to Run Saber to me, I can't put my finger on what's missing.  I guess I just like the whole aspect of slide tackling, doing an aerial somersault, landing in the midst of enemies and slashing them all to bits that Strider does so well and so often.  Shinobi III adds the eight shuriken throw and the guard to the mix but keeps the same gameplay flexibility.  I like this gameplay so much that I still enjoy playing Strider ACD even though it is slower.

What do you think of Osman?

[sheath]

I don't think I've played Cannon Dancer/Osman before, but it looks to have all of the mechanics I like about Strider and decent level/character designs to back that up.  I'll need to fire up Mame at some point to give it a play.

I have played Edward Randy already, it is definitely in the same vein and plays great, though not exactly like Strider like Osman seems to be.

[geise]

Osman is actually developed by Ex Capcom devs.

[CrackTiger]

Osman is actually developed by Ex Capcom devs.

I believe that they are actually ex-Strider devs.

[SignOfZeta]

Osman is so fucking amazingly unspeakably great. If you loved Strider then you'll basically die of pleasure playing Osman.

[PunkCryborg]

Osman is so badass! It's hard even when you are just credit spamming. I can't get past that one point where you have to go up that hill while the cars drop down and the girls are flying all over the screen. Beautiful game though with a nice color palette and spot on Strider controls.

[sheath]

I just popped in Strider ACD for a quick play through, got most of the way through level 2 (3 with the extra level) before I fell more times than I'd like.  I have to say that it looks and plays even better than I was remembering.  Some notable exceptions are in level 2/3, the beginning of the Syberian tunnel doesn't have the bell chime tune that I absolutely love in the Genesis version, and it doesn't have the mountain range in the background during the big run.  If I recall correctly the music repeats more often in Strider ACD than it does in the Genesis game, which has more audio tracks than the Arcade original does.

Sprite flicker is only bad when there are a ton of explosion sprites on screen, otherwise I didn't notice any and fail to see how combining the cypher sprite with Hiryu's would make a significant difference.  I also noticed that Hiryu's sprite is different colors in different levels, especially the exclusive level 2 sand level.  I wonder if this was taken into account in those PCEdev edits.

[TurboXray]

Sprite flicker is only bad when there are a ton of explosion sprites on screen, otherwise I didn't notice any and fail to see how combining the cypher sprite with Hiryu's would make a significant difference.

It's just specifically sprite bandwidth wasting for no apparent benefit for the PCE itself. Look at the crouching example. 160 pixels! The sprite bandwidth is only 256 pixels. It could easily be cut down to 80 pixels wide (and that's just the normal reach sword slash). That's a noticeable and significant difference. PCE's strength is also its weakness. 16x16 sprite cell size is fairly large and not always optimal (all those empty pixels in the sprite cells still contribute to sprite scanline overflow/blank out, or flicker if the programmers write the routine for it). Cutting as many cells down in size/number (horizontally) always helps, because a game is almost always dynamic as to what's being put onscreen and where - so you need to optimize for worse case scenario, or dumbly dial back the amount of objects on screen over all, or go NEC Ave's route and not give a shit. NEC AVE made games tend to completely ignore this (Dynasty Wars on PCE is probably the worse offender. At least they used a lower res for this Strider port. Surprising for direct NEC handled port). There are a lot more examples in Strider (and they all add up), I just never got around to presenting them. The explosions is another one. They remade/designed the explosions, and it saves space because of mirroring - but eats up much more bandwidth than taking the arcade originals and scaling them down to the right perspective.

[turbogrfxfan]

Sprite flicker is only bad when there are a ton of explosion sprites on screen, otherwise I didn't notice any and fail to see how combining the cypher sprite with Hiryu's would make a significant difference.

It's just specifically sprite bandwidth wasting for no apparent benefit for the PCE itself. Look at the crouching example. 160 pixels! The sprite bandwidth is only 256 pixels. It could easily be cut down to 80 pixels wide (and that's just the normal reach sword slash). That's a noticeable and significant difference. PCE's strength is also its weakness. 16x16 sprite cell size is fairly large and not always optimal (all those empty pixels in the sprite cells still contribute to sprite scanline overflow/blank out, or flicker if the programmers write the routine for it). Cutting as many cells down in size/number (horizontally) always helps, because a game is almost always dynamic as to what's being put onscreen and where - so you need to optimize for worse case scenario, or dumbly dial back the amount of objects on screen over all, or go NEC Ave's route and not give a shit. NEC AVE made games tend to completely ignore this (Dynasty Wars on PCE is probably the worse offender. At least they used a lower res for this Strider port. Surprising for direct NEC handled port). There are a lot more examples in Strider (and they all add up), I just never got around to presenting them. The explosions is another one. They remade/designed the explosions, and it saves space because of mirroring - but eats up much more bandwidth than taking the arcade originals and scaling them down to the right perspective.

wow thts kiler ifo i didntknw.  thnx!!

[CrackTiger]

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.

[CrackTiger]

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.  ;)

[CrackTiger]

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?

[CrackTiger]

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.

[TurboXray]

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.

[CrackTiger]

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.

[TurboXray]

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 Expand

           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:
/SOR_exm_1.png

 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):
/punch_1.png

 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.

[CrackTiger]

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.

[sheath]

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.

Streets of Rage is a 320 wide game, which should mean that it had a 20 sprites per scanline limit.  There isn't slow down with eight or twelve character sprites, there is slowdown when there are juggling enemies on screen and 8-12 character sprites on screen.  I haven't seen anything like it on a console.  But, I bet most people just call the special car bomb attack whenever that much action is going on.  ;)

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.

I noticed that Streets of Rage 1 doesn't toss around a lot of character sprites while larger bosses are on screen.  Streets of Rage 2 has no problem with doing so though, especially that insane elevator level.  I'd honestly love to see the same thing done in other games regardless of platform.  It's not like I pause the game to count characters and objects, the effect of all of those enemies at once has an immediate impact on the gameplay that three enemies can never achieve.

[CrackTiger]

Streets of Rage is a 320 wide game, which should mean that it had a 20 sprites per scanline limit.

320 wide Genesis games have a 320 pixel sprite limit and 256 wide PCE games have a 256 pixel sprite limit. Either way, it equals 1 screen width.

There isn't slow down with eight or twelve character sprites, there is slowdown when there are juggling enemies on screen and 8-12 character sprites on screen.  I haven't seen anything like it on a console.  But, I bet most people just call the special car bomb attack whenever that much action is going on.  ;)

Yeah, I can't think of any 16-bit console brawlers that come close to the SoR games when it comes to characters on-screen. That in itself would be impressive, but it's how tastefully done it is that gives it that special feel. The ultimate 16-bit console beat em up would be something for Genesis as well designed as SoR, only running in the 256 wide mode, so it could handle more horizontal sprites without breakup. Although the SoR games already toss around more than enough characters. But it would be cool to have a 4 player game.

I believe that the scene I was thinking of with slowdown and flicker is Stage 5 of SoR. There's a point where if you don't attack everyone right away, they add up until the game slows and flickers. I don't remember any scenes with more enemies than that.

I noticed that Streets of Rage 1 doesn't toss around a lot of character sprites while larger bosses are on screen.  Streets of Rage 2 has no problem with doing so though, especially that insane elevator level.  I'd honestly love to see the same thing done in other games regardless of platform.  It's not like I pause the game to count characters and objects, the effect of all of those enemies at once has an immediate impact on the gameplay that three enemies can never achieve.

I think that the SNES and PCE could do something that would be impressive, even when compared to SoR, but it's the kind of thing that had to happen back in the day. Maybe down the road as PCE "homebrew" continues to improve, we'll see a cool new beat em up with tons of characters at once.

[TurboXray]

Streets of Rage is a 320 wide game, which should mean that it had a 20 sprites per scanline limit.

Yes, but the sprite scanline buffer is still just that of the width of the screen. The buffer is 1.25 times larger and there is 1.25 times more sprites per scanline, but the pixels per scanline for the screen are also 1.25 more dense as well. What that means, is that 32 pixels in low res mode takes 40 pixels in high res mode. So to get the exact same output 'width' as a low res, you need more pixels. Both systems aren't going to be hitting their SAT entry per scanline limit before they would hit their scanline sprite pixel buffer limit. Genesis could have 20 sprites per scanline if they were 16 pixels wide (or less) for 320 res mode (or H40 as Sega labels it). That's it. So you could have ten 32pixel wide sprites per scanline, but those 32pixels are going to be a shallower width than low res 32pixels. For the same width you'd need ten 40 pixel wide sprites, which means you only have sprite bandwidth for 8 objects with that corresponding width. Which is exactly the limit of low res mode for both system.

 The higher res H40 mode is more optimizable for sprites of in between sizes, or more smaller/tiny objects per scanline. Where a pixeled image might push over into the next cell segment for low res (and coarser sprite cell size of the PCE), could be optimized to take less relative scanline bandwidth ratio to the real output width of the image. I.e. less sprite core cells, thus less bandwidth for the sprite scanline buffer.

There isn't slow down with eight or twelve character sprites, there is slowdown when there are juggling enemies on screen and 8-12 character sprites on screen.  I haven't seen anything like it on a console.  But, I bet most people just call the special car bomb attack whenever that much action is going on.  ;)

Yeah, what comes to mind is the axe juggling guys that cause the slowdown (with less than 8 characters on screen. SOR1 we're talking about here). But it's not like the game was plagued with slowdown, like I remember Final Fight on the SNES being as such.

[soop]

I can't believe it!  I was searching for "Final Fight" "sprite size" in Google, and found a page here wondering exactly what I was wondering.  I still don't actually have the sizes, but I'm gonna keep looking, because I think this is do-able.

1. Final Fight's enemies do tend to take turns.  You'd have to make an algorithm to make sure the enemies moved around to different scanlines, and the main trouble would be the charging enemies.  However, for the first stage "boss" (slash?  Forgot his name) when he sits on the wall and calls more guys, you could just convert him to background tiles.

2. You can't get rid of the destroyable objects (barrels etc), but I like the idea of making them background tiles until they get destroyed.

3. Fire effects would be hard to do unless you could use dynamic tiles.

4. The sprites are very large though.  I still can't find the sizes, but I think the PCE could handle it.  It's crazy that there weren't more beatemups considering what the PCE can do (and the fact that one of the first releases was The Kung Fu.

*edit* I didn't realise because I got here from google, but can we get this moved to the PCE development folder now?

*edit* Tom mentioned "mirroring" - what's that?

[fraggore]

I was wondering what everyones opinion of the arcade system card is. The only two games that look good to me are Strider and Sapphire. I have no need for those neo geo fighting games since I already own them on other systems. So, is it worth buying just for those two games alone? 

I just got one Sapphire is ok it aint nothing special and i realy dont like Strider the megadrive one is much better and that coming from a guy who loves the game.

as for the neo games the pretty impresive conversions but if you got a neo your not gonna play them i do like the kabuki clash game its pretty good havent tryed mad stalker yet.

[soop]

I just got one Sapphire is ok it aint nothing special

O___O  Say what?

Sapphire (the bootie) is worth getting an Arcade card for.

[soop]

crap, I just had a look at the SNES sprites, and Guy (who is a fairly small sprite) is at least 6 32x32 sprites.  Which means 3 people on screen max, using those sprites.  Not including the really big guys.

Wow, and I just find some of Tom's converted sprites! still too big tho: http://forum.frozenutopia.com/index.php?topic=176.0

[hoobs88]

I was wondering what everyones opinion of the arcade system card is. The only two games that look good to me are Strider and Sapphire. I have no need for those neo geo fighting games since I already own them on other systems. So, is it worth buying just for those two games alone? 

I just got one Sapphire is ok it aint nothing special and i realy dont like Strider the megadrive one is much better and that coming from a guy who loves the game.
as for the neo games the pretty impresive conversions but if you got a neo your not gonna play them i do like the kabuki clash game its pretty good havent tryed mad stalker yet.

I agree with Fraggore... I only own 3 ACD games- Kabuki Itouryodan, Strider, and Sapphire. If you have Kabuki on another system that only leaves Strider and Sapphire to justify your purchase of an ACD card and Strider isn't that great of port (I can only compare it with the arcade version). That just leaves Sapphire (and whether or not you love Shooties). Some people really like the music in Sapphire but I don't recall it being very memorable the one time I played it.

[fraggore]

i love shmups and Sapphire seems well a bit over rated to be honest its not a bad game but it aint great either just my opinion like.

The music is pretty good i like the rock sound track but its no lords of thunder or gates of thunder just think they is a lot better shooter on the engine not to say i am not gonna play it.

as for strider its a pretty shoddie conversion was realy disappointed with it it looks and plays pretty bad the fmv and the extra level is a nice touch but they could have used the time to make the game better instead, i am a big fan of the arcade game and the megadrive that has a awesome conversion of it i was just very surprised how bad it was.

[SignOfZeta]

I agree with Fraggore... I only own 3 ACD games- Kabuki Itouryodan, Strider, and Sapphire. If you have Kabuki on another system that only leaves Strider and Sapphire to justify your purchase of an ACD card and Strider isn't that great of port (I can only compare it with the arcade version). That just leaves Sapphire (and whether or not you love Shooties). Some people really like the music in Sapphire but I don't recall it being very memorable the one time I played it.

First off, yes, I realise that this is a year old thread that got bumped for Final Fight reasons. BTW, Final Fight is an overrated piece of fluff. If I had any skills for porting whatsoever I'd be concentrating on Kunio games. Final Fight has such a lack of...stuff to do, it gets boring in five minutes. Kunio games never had the graphical punch, but they had 10 times the gameplay of any other beat-em-um until Guardian Heroes was released.

Anyway, the reason I'm posting, the Kabuki game on ACD doesn't exist on another system. Its totally different than the Neo one.