Obeybrew spriting reference

[Nando]

Ok gang, trying to compile all the information I've gotten from members here about sprite and game creation; art side, on the PCE.

Here's what I've got so far. Ideally we can get a polished guide that can be posted on the obeybrew site.


HUGE THANKS to Ark, Paul and Rove

It's a bit on the messy side so bare with me:

_______________________________________________


Screen Resolution: 256x224 256x239 (used the most) - and 336x224

 
----

Sprites come in 16 or 32 pixel widths, and 16, 32, or 64 pixel heights. So, some sprites in games are actually multiple sprites (like China Warrior).

There are a total of 16 individual sprite palettes. Each palette has 16 colours.
Colour 0 (the first colour in the palette) must be the same on every sprite palette. This colour will be the one the system sees as 'transparent' when displaying the sprite. So essentially, just think that each palette has 15 useable colours.

Color 0 of that palette is treated as transparent.  The other 15 colors (colors 1 thru 15!) in the palette are your colors for your sprite!

PROTIP
A lot of action games use a stacked 32x32 set up
Use the brightest magenta/pink as that's rarely used in the sprites themselves.
If you make a PCX, it's automagically using an indexed palette. Photoshop writes PCX files backwards, you can use Gimp to save in the correct order

There are 512 color options to choose from (9 bit color. Like an Amiga.  Its 2^9, or 512).

Your color options should be chosen using RGB values that go in steps of 36

so RGB values of 0 36 72 108 144 180 216 252

Example:
R: 144
G: 36
B: 180


-------
Cut Scenes are made up of background tiles and sprites. They're identical to sprites except for the following:

All background tiles share color 0, so every palette used for the background (palettes 0 thru 15) will have the same color in slot 0.  Whatever color 0 is in palette 0, becomes the shared color.  

All background tiles are 8x8 instead of 16x16.


 

PROTIP
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.

 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.

256 pixels per line.  16 is the max if you only do 16x16 sprites.  It ranges from 8-16 depending on your sprite sizes.

Two "slots" per scanline

[32x16]
[32x16]
[32x32]

PROTIP
Using less scanlines (224 instead of 239, for example) is actually beneficial for executing code and speeding up the game, since much code is executed in the vblank time... the less scanlines you're using for game display, the more time you have in vblank for code.  Makes me wonder how many games with slowdown that used 239 scanlines would have less or no slowdown had they used 224 scanlines.

PROTIP
The system prioritizes based off the sprite number, IIRC.   Lower sprite numbers take higher priority.  It's not LIFO or FIFO.  It's not a stack or queue.  It also doesn't flicker them.  It just flat out clips sprites that are out of priority.

See here.   The dome tops are lower sprite #s than the coral.  They clip the coral out.  If you fly down there, it clips a dome too because the ship is sprite 0.

More than one way to skin the spriting cat, you can create a high-res image and scale it down, create your images at the PCE res level.  From Paul

"I've never drawn at higher res and scaled down for any PC Engine work, although I did that a few times on the Amiga (and more recently on PC for a Sabre Wulf remake) and it was very useful. If you're going to do it, I found it worked better scaling down flat blobs of colour and then adding the detail. But if you're good at drawing you should probably just scan and trace your sketches actual size. Try it, see what suits you.

--
Sprite layering

PROTIP
See Deadmoon - open up in an emu that allows you to turn sprite and bkg layers on/off

Because the PCE can't overlap backgrounds, standard horizontal parallax looks like obvious strips. By adding the sprites, it makes everything look a bit more natural as they can overlap each layer without issue. Anything that overlaps has to be done with sprites (with the exception of animated tiles, but these always show a square edge and are only suitable for repeat patterns).

Backgrounds/Cut scenes tips: Try to keep everything moving, animating or colour cycling

-----
Color (Colour ) palettes

PROTIP
Paul:
Using multiple palettes can be a nightmare if you don't keep track of things. The way I approach it is to colour code my palettes, and keep a layer in the artwork that blocks out the areas that use each palette as I work. Working on backgrounds, I'd be inclined to keep the first 2 colours black and white; you need at least one shared colour anyway so it may as well be one of those.

An average of 6-7 colors for each image


Also, there's nothing stopping you shading everything in a single tint and recolouring afterwards if you feel the need.

---------

Color info

9bit color palette
https://lh5.googleusercontent.com/-kEqV4nGSbHs/T14FjBUivOI/AAAAAAAACDs/twRXY-zes2U/s800/pcenginecolourpalette.png

9bit color cube
for more inbetween colours -- you can always choose your path through the colour cube using wider straight lines, or even curve through the cube:
https://www.chrismcovell.com/images/PCE_Colcube.gif


 --

Resources :

VISUAL SCENES!!! study those that came before you!
https://www.youtube.com/user/sunteam  


Any of the mid-late Telenet/Riot games are worth checking out purely because of the quantity of scenes they put in their games. They're good to examine for various techniques on backgrounds, depending on what style you are going for.

[OldRover]

Two additional details to squeeze in there somewhere:

-The common color of the background is also used as the transparent color for sprites that are placed with sprite-to-background priority of 0. (Monolith uses this for the parallax moon trick)
-Palette index 256, the first transparent sprite color, is also used as the overscan color.

[ccovell]

Screen Resolution: 256x224 (used the most) - and 336x224

Not true.  A while back for my Screen Dimension Test demo, I tested all the released HuCard games.  The vast majority used a setting of 256 (or 3xx) X 239 lines.  (one off from 240.)

There are 512 color options to choose from (9 bit color.  Like an Amiga.  Its 2^9, or 512).

An Amiga uses 12-bit (4096) or 24-bit (16777216) colour.

It's the Atari ST that uses 9-bit (512) colour.

[Sadler]

Nice post! Thanks!

Anything that overlaps has to be done with sprites (with the exception of animated tiles, but these always show a square edge and are only suitable for repeat patterns).

I think you can vary the background color per scan line to have overlapping parallax without sprites. It would be basic and ideally a game should use a combination of several parallax techniques (including and especially sprites!) to give an appearance of hardware parallax. I haven't let my ignorance keep me from rambling about this before.

[Nando]

Awesome, thanks for the feedback all.

Once we've got the details hammered out, I will add all edits to a master doc and then submit that to Obeybrew


256x239 interesting...is there any particular reason it was done this way? I'm thinking monitors back in the day had something to do with it?

Rove - will have to pick your brain about that parallax technique.

Sadler - awesome addition. Will have to read that one when I am less sleepy. Thanks for the input!

[_Paul]

I would arrange this to clearly separate the 'factual' areas and the bits that are just tips (often personal opinion), just to clarify things.

[Nando]

I would arrange this to clearly separate the 'factual' areas and the bits that are just tips (often personal opinion), just to clarify things.

[OldRover]

...that's one fucked space marine.

[FraGMarE]

256x239 interesting...is there any particular reason it was done this way? I'm thinking monitors back in the day had something to do with it?

It was likely just what was supported in the PCE's early dev kit, making it mainly a matter of convenience.  NEC/Hudson didn't really officially sanction or "condone" using resolutions outside of what was supported in the devkit (likely 256x239), but some developers chose to break the mold and use other resolutions (256x224, 336x224, 512x224, etc.).  They were just on their own in coding the in-game support for it.

Using less scanlines (224 instead of 239, for example) is actually beneficial for executing code and speeding up the game, since much code is executed in the vblank time... the less scanlines you're using for game display, the more time you have in vblank for code.  Makes me wonder how many games with slowdown that used 239 scanlines would have less or no slowdown had they used 224 scanlines.

[Nando]

Thanks Fragmare.  Added your comment as a pro-tip.


anyone else got additions?

Is the information on here enough of a start to add to Obeybrew?

[Nando]

Last bump on this one.

[cabbage]

PROTIP
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.

 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.

This bold part is wrong? Should be 256 pixels limit per scanline (e.g. 16 16x16 sprites on one scanline)

Also I am curious about this hardware trick to use 16x8 sprites... could you clarify a bit--what's the trick?

[TurboXray]

PROTIP
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.

 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.

This bold part is wrong? Should be 256 pixels limit per scanline (e.g. 16 16x16 sprites on one scanline)

Also I am curious about this hardware trick to use 16x8 sprites... could you clarify a bit--what's the trick?

It's a special setting of the VDC display regs that causes the VDC to skip every other scanline of the sprite field, but retain the normal scanline order of the BG. Thus all sprites cells are half the normal height. Afaik, no emulators support this. This is different from setting the VDC to skip both BG and SPR scanlines (double VDC scanline per real scanline). I tested it on a original PCE, Duo, and SGX. Worked on all three systems. The downside is that you get a little clipping of the screen/display on the right side. The other quirk about this trick is that for vertical movement/placement, you need to treat bit 0 of the sprite table Y reg as the sprite bank selector. I.e. shift your sprite Y value by 1 to the left (Y<<1). This is because it needs to travel twice the distance to show up at the same coords as normal. So, setting bit 0 of Y selects what 'interleaved' scanlines of the real sprite to show. This makes the sprite layout in vram more complicated (until you wrap your head around it), but also makes it more efficient for sprites will 8 or less vertical pixel height.


 The bold text is for SNES sprite cells. It's 32 sprites, or 34 8x8 cells or 272 pixels per scanline.

[TurboXray]

I have a video that just happens to show the 'XX by 8' cell segment sprite mode. It wasn't the purpose of this video, to show that off.  The purpose was a new controllable visual FX for column or row pixel distortion via hsync routine, but it was left in as I just reused it for the effect purpose.

The 8 sprites in a row (they're Link from the SNES game) are 32x32 cells, but in that mode are shown as 32x16 cells.