Were 3bpp graphics ever actually a thing?

Discussion of development of software for any "obsolete" computer or video game system.
93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Were 3bpp graphics ever actually a thing?

Post by 93143 » Wed Nov 13, 2019 2:00 am

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: 16
Joined: Thu Oct 31, 2019 12:56 am

Re: Were 3bpp graphics ever actually a thing?

Post by turboxray » Wed Nov 13, 2019 8:27 pm

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: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Were 3bpp graphics ever actually a thing?

Post by 93143 » Wed Nov 13, 2019 8:49 pm

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: 7766
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Were 3bpp graphics ever actually a thing?

Post by Bregalad » Tue Dec 03, 2019 8:39 am

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: 8776
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Were 3bpp graphics ever actually a thing?

Post by lidnariq » Tue Dec 03, 2019 11:10 am

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: 16
Joined: Thu Oct 31, 2019 12:56 am

Re: Were 3bpp graphics ever actually a thing?

Post by turboxray » 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.

User avatar
Bregalad
Posts: 7766
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Were 3bpp graphics ever actually a thing?

Post by Bregalad » Wed Dec 04, 2019 7:42 am

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 */

Post Reply