Run N Gun - PCE

[fragmare]

Oh, and here are a few player animations I've been working on lately.

[Nando]

I'll stick some new mockup pics of PC-Gunjin up here soon.  In the meantime, there is this: http://fragmare.mindrec.com/pc-gunjin.htm

As for what I'd like to have seen on the PC-Engine?  Contra Hard Corps or GTFO.

That looks sweet!

[KingDrool]

I'll stick some new mockup pics of PC-Gunjin up here soon.  In the meantime, there is this: http://fragmare.mindrec.com/pc-gunjin.htm

God...that looks like it could (could've?) be amazing.

[Arkhan]

Make a game with a buncha brits called CUNTRA: HARD TWATS

[spenoza]

One thing I worry about is 2 player mode and sprite line limits. I know there are ways around them, using coordinated flicker and whatnot, but too much flicker could kill a good run n' gun.

[nat]

There is nothing worse than dying from a bullet invisible due to flicker.

[spenoza]

Well, deliberate flicker is better than accidental/unintended flicker. If you simply display something on every other frame, you at least ensure that the item will be predictably visible, and not have bullets and enemies just disappearing randomly. And you don't want to put too many constraints on how much stuff you have going on in a run n' gun.

[fragmare]

One thing I worry about is 2 player mode and sprite line limits. I know there are ways around them, using coordinated flicker and whatnot, but too much flicker could kill a good run n' gun.

Eh, look at Contra III on the SNES.  They managed just fine with the same sprite buffer as the PCE/TG16 (256 sprite pixels per line).  They just alternately flickered the player bullets in 2p co-op mode afaik.

[Keranu]

I think Hard Corps used the same flicker trick on 2 players.

[Tatsujin]

Ark! MEME CREATOR!!!!

lol, not exactry, this time \o/

[spenoza]

One thing I worry about is 2 player mode and sprite line limits. I know there are ways around them, using coordinated flicker and whatnot, but too much flicker could kill a good run n' gun.

Eh, look at Contra III on the SNES.  They managed just fine with the same sprite buffer as the PCE/TG16 (256 sprite pixels per line).  They just alternately flickered the player bullets in 2p co-op mode afaik.

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.

[ccovell]

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.

[spenoza]

I did some web searching and found support for the 256 sprite-pixels per line limit. But the SNES can put more sprites on a line than the PCE and it can also display larger sprites (up to 64 x 64), which means the SNES's sprite-pixel limitation is much more restrictive than the sprites per line limitation. Unless there's a level of interpretation here I'm not getting, like the sprite pixels are per scan line and the sprite per line limit is screen regions called lines and not merely scan lines.

[nodtveidt]

spenoza, it seems you are indeed missing something here. The sprite-pixels-per-line (yes, that means scanline) limit is absolute. The SNES is capable of 256 sprite pixels per line. If you put more, then sprites are clipped. It works that way on all the 16 bit consoles (yes, including the Neo Geo, but its limits are way higher... close to 1000 pixels, iirc). You can put as many sprites on a line as you want but that doesn't mean they're all going to be displayed. The SNES is a sprite monster but developers still have to follow the rules.

[spenoza]

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?