Were 3bpp graphics ever actually a thing?
Re: Were 3bpp graphics ever actually a thing?
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...
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.
Re: Were 3bpp graphics ever actually a thing?
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).
Re: Were 3bpp graphics ever actually a thing?
Correction: it's OR, not AND. Not sure where my head was at...
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.
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:I'm pretty sure quite a number of MD games use 3bpp to do exactly what you're saying; 4 subpalettes now becomes 8.
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...turboxray wrote:it's not as fast to do in realtime writing to VRAM like with planar, but then again MD uses VDMA anyway
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.
Re: Were 3bpp graphics ever actually a thing?
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.
Re: Were 3bpp graphics ever actually a thing?
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.
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.
Re: Were 3bpp graphics ever actually a thing?
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.
Re: Were 3bpp graphics ever actually a thing?
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 */
Re: Were 3bpp graphics ever actually a thing?
Look like we got that 3bpp information from a common source of motivation then
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Were 3bpp graphics ever actually a thing?
How many colors can the System-16 do at once in total?
Re: Were 3bpp graphics ever actually a thing?
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
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Were 3bpp graphics ever actually a thing?
What was the technical reason the System-16 boards had 3bpp BG layers?
Re: Were 3bpp graphics ever actually a thing?
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.