Run N Gun - PCE

[fragmare]

Really? I thought the SNES could put more sprite pixels on a line... I know it can put more sprites on a line, at least. Don't know about actual pixel limits.

It's actually 280 pixels (35 sprites) per scanline.   Er... or so my old SFC press release says.

Hmm, I've never heard 280px for the SNES.  It's always been 256px worth of sprite data that I've heard.  I'm not sure how accurate this is, but this is similar to what I've always seen http://en.wikibooks.org/wiki/Super_NES_Programming/SNES_Specs

I *do* know the SNES (and Genesis) had a smaller minimum sprite size than the PCE.  That is, they could display an 8x8 sprite and it would only count as 8px towards the scanline limit.  In contrast, the smallest valid sprite size on the PCE was 16x16.  The smaller sprites came in handy for tiny bullets and whatnot.  As an artist, I sometimes wish the PCE incremented sprite cells in 8 pixel increments (like it does with bg tiles) but alas, that's not how things panned out.  :/

[nodtveidt]

What I mean is, if there is a sprite pixel per line limit and a sprite object/tile limit per line, does the most conservative value always trump?

Tiles do not work the same way as sprites. Tiles do not have a "per line" limit; tiles never overlap and cannot be placed in random locations on the screen. Sprites can be placed anywhere, and can overlap all day long. They are two completely different schemes.

[fragmare]

What I mean is, if there is a sprite pixel per line limit and a sprite object/tile limit per line, does the most conservative value always trump?

The sprite pixel per line and sprite object per line limit is one in the same.    When you hear people say the PCE's limit is 256 pixels or 16 sprites they mean you can have sixteen 16px wide sprites on a given scanline.  You can also have eight 32px wide sprites on a line.  You can also combine them and have, say, six 32px sprites and two 16px wide sprites.  But at no time can you have more than 256px worth of sprite data on any given scanline, else it'll start dropping the lowest priority sprite's graphic data for that line.  The Genesis is the same way, but its limit is 320px of sprite data per line (at least in 320x240 res mode).  The SNES is similar to the PCE, except for the fact that instead of dropping the bottom-most sprites when it flickers (i.e., the lowest priority sprites), it'll drop the top-most sprites (highest priority).  This can be good or bad, depending on if the flicker is intentional or not.  Also, as I stated one post up, the Genesis and SNES differ from the PCE/TG16 in that they have a smaller minimum sprite size.  Their smallest sprite size is 8x8 as opposed to the PCE/TG16, which has a minimum sprite size of 16x16.  The SNES and Genesis also have larger maximum sprite sizes (up to 64px wide, iirc).  So on the SNES and Genesis, that means more combinations of various sprite sizes are possible on a given scanline.  Either way you look at it, though, the limit is absolute for each respective system and cannot be exceeded.  Hope that helps clarify things a bit for you.

[nodtveidt]

Almost, Frag. The Genesis is limited to a max size of 32x32. Only the SNES can do 64x64.

[fragmare]

Ah okay.  I'm not as familiar with Genesis/SNES graphical limits, obviously, since I only draw pixel art for the PC-Engine.  But my point still stands regarding sprite buffer limits.  That is to say, whether you're using 8, 16, 32 or 64 pixel wide sprites for whatever system, it all counts towards the scanline limit the same way.  You can mix and match and combine various sprite sizes on a line however you like, but you can't exceed a particular system's sprite buffer and expect to see all the sprites on a line.

[nodtveidt]

Yeah, everything else was spot-on correct.

[spenoza]

OK, thanks Fragmare. That's the direction I was leaning, but I was having trouble sussing it out because of the way things were worded. I was looking at that wikibooks site as well.

And yes, Rover, I know BG tiles are different from sprites, but that one site Fragmare linked had some confusing wording, and I was trying to work out if the SNES did something in a different manner.

I'm used to assuming hardware behaves oddly, because of my familiarity with the Saturn. The Sega Saturn does almost nothing in a normal fashion.

[Bonknuts]

         0 = 8x8    16x16    ;Caution:
         1 = 8x8    32x32    ;In 224-lines mode, OBJs with 64-pixel height
         2 = 8x8    64x64    ;may wrap from lower to upper screen border.
         3 = 16x16  32x32    ;In 239-lines mode, the same problem applies
         4 = 16x16  64x64    ;also for OBJs with 32-pixel height.
         5 = 32x32  64x64
         6 = 16x32  32x64 (undocumented)
         7 = 16x32  32x32 (undocumented)

 You can only have two sprite sizes on screen at the same time on the SNES (for that frame). That can be pretty limiting. If you want to optimize for sprite scanline flicker (overflow) and use 8x8 for one size, you're forced to use 16x16 or 32x32 or 64x64 for the other size. That last two pairs are rather useless for the most part IMO. So 8x8 paired with 16x16. A little limiting and it'll eat through the 128 entry OAM (sprite table) quicker.

 If you optimized for 8x8/16x16, then you hit the sweet spot for sprite cells per scanline limit. It's 34 8x8 cells per scanline or 272 pixels (byuu corrected me a couple of years back). I think most SNES games used 16x16/32x32 sprite mode. Which is pretty close to PCE for scanline pixel to cell limit. But the SNES has the advantage for another BG layer (and a 3rd low color one in some modes) to make larger enemies/bosses without cutting into that sprite scanline limit.

 There's a hardware trick on the PCE that you can do to make 16x8 sprite cells ( making the following sizes 16x8,32x8,16x16,32x16,16x32,32x32) instead of the usual 16x16 (16x16,32x16,16x32,32x32,16x64,32x64). Not as nice as 8x8, but still makes it more optimal in certain situations since it actually effects the scanline limit on a vertical plane/path.

[esteban]

I'm up for anything run n gun as long as the controls and action are good.  Cho Aniki run n' gunner!

Clearly, you read my suggestions back in the day.

I was totally serious about them (I still am). Sadly, I don't think fragmare wanted to implement any of them

[Nando]

Discovered this little gem just yesterday.

Toshi Tensou Keikaku - Eternal City
http://www.pcengine.co.uk/HTML_Games/Eternal_City.htm



I REALLY like the pace and the amount of enemies thrown at you. You can only shoot in one direction, wish it were different, but it doesn't necessarily detract from the game.  I was able to jump over and avoid bullets like a pro and shoot a ton of really nicely animated robots and stuff. Really fun game so far, and it's animated beautifully.