Were 3bpp graphics ever actually a thing?

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Were 3bpp graphics ever actually a thing?

Post by 93143 »

I just now realized that 3bpp as a compression technique for 4bpp graphics allows you to double the number of available palettes, by optionally filling in the fourth bitplane with the bitwise OR of the first three.

Unfortunately this technique works best on the PC Engine, which needs it the least, and seems like it would be inefficient on the Mega Drive, which would benefit the most...
Last edited by 93143 on Wed Nov 13, 2019 8:47 pm, edited 1 time in total.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Were 3bpp graphics ever actually a thing?

Post by turboxray »

I'm pretty sure quite a number of MD games use 3bpp to do exactly what you're saying; 4 subpalettes now becomes 8. Or a combination of 4bbp and 3bpp (shifted and non shifted). But yeah, it's not as fast to do in realtime writing to VRAM like with planar, but then again MD uses VDMA anyway. A lot of PCE hucard games early to mid generation used 3bpp because of the instant savings. SuperGrafx port of GnG uses 3bbp and 2bpp almost for everything (tiles and sprites).
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Were 3bpp graphics ever actually a thing?

Post by 93143 »

Correction: it's OR, not AND. Not sure where my head was at...
turboxray wrote:I'm pretty sure quite a number of MD games use 3bpp to do exactly what you're saying; 4 subpalettes now becomes 8.
Interesting. Not especially surprising, considering the hardware limits they had to deal with. SNES programmers complain about the sprite system; MD programmers complain about CRAM...
turboxray wrote:it's not as fast to do in realtime writing to VRAM like with planar, but then again MD uses VDMA anyway
The CPU still has to do the decompression, which in this scheme involves breaking up the 3bpp data into nibbles and checking if each one is nonzero, then adding the appropriate value before finalizing the 4bpp data. Not to mention that with packed-pixel you save no space by using 3bpp unless you barrel-shift each nibble...

Probably the best way to do this on MD would be to not bother with 3bpp storage - just use some other compression scheme - and set the high bit of each nontransparent pixel, so that you can just mask off the high bits if you want the bottom half of the palette.


EDIT: ...hmm. Copy 32-bit value (8 pixels) into a second register, then into a third register and shift left. Move the result into a fourth register, shift left again. OR the second, third and fourth registers together, shift left yet again and mask off the bottom three bits of every pixel (AND with $88888888). Add that to the original register and Bob's your uncle. Does that work on a 68000?

Still less efficient than just AND with $77777777, though, so unless there's a good way to take advantage of 3bpp for compression it may be better to start with ones in the nontransparent high bits.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Were 3bpp graphics ever actually a thing?

Post by Bregalad »

turboxray wrote: Thu Oct 31, 2019 1:07 am Sega's original System-16 uses 3bit tiles for the background. That was a hardware limit, not a software compression thing. Oddly, IIRC sprites are 4bit.
Stef wrote: Tue Nov 05, 2019 3:21 am Some arcade systems (as the System-16 from Sega) used 3bpp tiles for the background layer, so that existed even if it wasn't common.
I'd be interested to know from where you guys have got this info from. The page on System16 website on System16 machine doesn't mention that.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Were 3bpp graphics ever actually a thing?

Post by lidnariq »

MAME's System16 "A" tilemap implementation has 3 ROMs allocated to tilemap graphics, and converts them from planar to packed pixels using GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar, 0, 1024 )

Interestingly, searching the code base for "gfx_8x8x3_planar" yields a number of other arcade hardware with 3bpp graphics ... and I'm reminded that the PlayChoice 10's instructions/supervisor display is also 3bpp.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: Were 3bpp graphics ever actually a thing?

Post by turboxray »

I knew it from talking with Charles MacDonald; I was working on a project to get the arcade shinobi rom running on the Genesis (years ago). I was trying to replace the graphics routines with custom ones.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Were 3bpp graphics ever actually a thing?

Post by Bregalad »

lidnariq wrote: Tue Dec 03, 2019 11:10 am Interestingly, searching the code base for "gfx_8x8x3_planar" yields a number of other arcade hardware with 3bpp graphics ... and I'm reminded that the PlayChoice 10's instructions/supervisor display is also 3bpp.
My results are :

Code: Select all

.../mame/src/emu/video/generic.cpp:const gfx_layout gfx_8x8x3_planar =
.../mame/src/emu/video/generic.h:extern const gfx_layout gfx_8x8x3_planar;
.../mame/src/mame/drivers/m57.cpp:	GFXDECODE_ENTRY( "gfx1", 0x0000, gfx_8x8x3_planar,    0, 32 )
.../mame/src/mame/drivers/m58.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar,   0, 32 )
.../mame/src/mame/drivers/segahang.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar, 0, 1024 )
.../mame/src/mame/drivers/segaorun.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar, 0, 1024 )
.../mame/src/mame/drivers/segas16a.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar, 0, 1024 )
.../mame/src/mame/drivers/segas16b.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar,   0, 1024 )
.../mame/src/mame/drivers/segaxbd.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar, 0, 1024 )
.../mame/src/mame/drivers/sprcros2.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar, 0,   16 )
.../mame/src/mame/drivers/tatsumi.cpp:	GFXDECODE_ENTRY( "gfx4", 0, gfx_8x8x3_planar, 768, 16)
.../mame/src/mame/drivers/tatsumi.cpp:	GFXDECODE_ENTRY( "gfx5", 0, gfx_8x8x3_planar, 0, 512)
.../mame/src/mame/drivers/zaccaria.cpp:	GFXDECODE_ENTRY( "gfx1", 0, gfx_8x8x3_planar, 0, 32 )
.../mame/src/mame/drivers/zaxxon.cpp:	GFXDECODE_ENTRY( "gfx_bg", 0, gfx_8x8x3_planar,  0, 32*2 )  /* background tiles */
Stef
Posts: 263
Joined: Mon Jul 01, 2013 11:25 am

Re: Were 3bpp graphics ever actually a thing?

Post by Stef »

turboxray wrote: Wed Dec 04, 2019 6:53 am I knew it from talking with Charles MacDonald; I was working on a project to get the arcade shinobi rom running on the Genesis (years ago). I was trying to replace the graphics routines with custom ones.
Look like we got that 3bpp information from a common source of motivation then :lol:
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Were 3bpp graphics ever actually a thing?

Post by psycopathicteen »

How many colors can the System-16 do at once in total?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Were 3bpp graphics ever actually a thing?

Post by lidnariq »

video/segas16a.cpp uses segaic16.cpp, which says

Code: Select all

 *  Hang On/System 16A-style tilemaps
 *
 *  4 total pages (Hang On)
 *  8 total pages (System 16A)
 *  Column/rowscroll enabled via external signals
 *
 *  Tile format:
 *      Bits               Usage
 *      ??------ --------  Unknown
 *      --b----- --------  Tile bank select
 *      ---p---- --------  Tile priority versus sprites
 *      ----cccc ccc-----  Tile color palette
 *      ----nnnn nnnnnnnn  Tile index
 *
 *  Text format:
 *      Bits               Usage
 *      ????---- --------  Unknown
 *      ----p--- --------  Priority
 *      -----ccc --------  Tile color palette
 *      -------- nnnnnnnn  Tile index
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Were 3bpp graphics ever actually a thing?

Post by psycopathicteen »

What was the technical reason the System-16 boards had 3bpp BG layers?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Were 3bpp graphics ever actually a thing?

Post by lidnariq »

Why not? Nothing else needs to access the data other than the tilemap renderer, so there's no reason to stick to any other convention. Planar graphics (instead of packed pixel) make it easy to use any arbitrary number of bits per pixel.
Post Reply