bmc/koftball: decode bitmap layer #12255
Conversation
| void koftball_state::pixram_w(offs_t offset, uint16_t data, uint16_t mem_mask) | ||
| { | ||
| COMBINE_DATA(&m_pixram[offset]); | ||
|
|
||
| int const x = (offset & 0xff) << 2; | ||
| int const y = (offset >> 8); | ||
|
|
||
| uint16_t const pixpal = (m_pixpal & 0xf) << 4; | ||
|
|
||
| uint16_t pen; | ||
| if (ACCESSING_BITS_8_15) | ||
| { | ||
| pen = (data >> 12) & 0xf; m_pixbitmap->pix(y, x + 0) = pen ? pixpal + pen : 0; | ||
| pen = (data >> 8) & 0xf; m_pixbitmap->pix(y, x + 1) = pen ? pixpal + pen : 0; | ||
| } | ||
| if (ACCESSING_BITS_0_7) | ||
| { | ||
| pen = (data >> 4) & 0xf; m_pixbitmap->pix(y, x + 2) = pen ? pixpal + pen : 0; | ||
| pen = (data >> 0) & 0xf; m_pixbitmap->pix(y, x + 3) = pen ? pixpal + pen : 0; | ||
| } | ||
| } |
There was a problem hiding this comment.
I got rid of this because it's hardly adaptable, and the performance penalty for drawing 512x256 in screen_update rather than the handler isn't all that noticeable in a stock 68k game.
It's also imho the wrong way of doing it, if anybody really bothers the better approach is to just use a is_dirty boolean flag attached to the handlers.
|
Thanks, now jxzh test mode and bookkeeping screens look way better. |
Fixed in a bit. |
| if (nibble) | ||
| bitmap.pix(y, (x << 2) + xi) = pix_bank | nibble; |
There was a problem hiding this comment.
Note: needs this if check because copyscrollbitmap_trans on its own is unable to break on a pal base. It's likely doable with prio* / primask* methods but I've forgot/don't know the incantation off the bat ...
| m_tilemap[1]->set_transparent_pen(0); | ||
| m_tilemap[3]->set_transparent_pen(0); | ||
|
|
||
| m_pixbitmap = std::make_unique<bitmap_ind16>(512, 256); |
There was a problem hiding this comment.
Is there a reason for dynamically allocating the bitmap object itself? The bitmap classes don’t allocate storage until you call resize or allocate – this adds an extra layer of indirection.
There was a problem hiding this comment.
I just reused what was already available in the driver for convenience, and didn't made great efforts in testing this beyond a couple service mode items (i.e. if there's a video register that controls pitch width or if it uses this as priority mask).
No description provided.