mirror of
https://github.com/holub/mame
synced 2025-05-24 23:05:32 +03:00
Toaplan2: Removed tile limit hack, not needed now since VDP is mixed properly [David Haywood]
This commit is contained in:
parent
15e1bc9b2e
commit
8987e6dfdc
@ -251,13 +251,6 @@ static TILE_GET_INFO_DEVICE( get_top0_tile_info )
|
||||
{
|
||||
tile_number = ( vdp->gp9001_gfxrom_bank[(tile_number >> 13) & 7] << 13 ) | ( tile_number & 0x1fff );
|
||||
}
|
||||
else
|
||||
{
|
||||
if (tile_number>vdp->tile_limit)
|
||||
{
|
||||
tile_number = 0;
|
||||
}
|
||||
}
|
||||
|
||||
color = attrib & 0x0fff; // 0x0f00 priority, 0x007f colour
|
||||
SET_TILE_INFO_DEVICE(
|
||||
@ -285,11 +278,6 @@ static TILE_GET_INFO_DEVICE( get_fg0_tile_info )
|
||||
{
|
||||
tile_number = ( vdp->gp9001_gfxrom_bank[(tile_number >> 13) & 7] << 13 ) | ( tile_number & 0x1fff );
|
||||
}
|
||||
else
|
||||
{
|
||||
if (tile_number>vdp->tile_limit) tile_number = 0;
|
||||
}
|
||||
|
||||
|
||||
color = attrib & 0x0fff; // 0x0f00 priority, 0x007f colour
|
||||
SET_TILE_INFO_DEVICE(
|
||||
@ -313,10 +301,6 @@ static TILE_GET_INFO_DEVICE( get_bg0_tile_info )
|
||||
{
|
||||
tile_number = ( vdp->gp9001_gfxrom_bank[(tile_number >> 13) & 7] << 13 ) | ( tile_number & 0x1fff );
|
||||
}
|
||||
else
|
||||
{
|
||||
if (tile_number>vdp->tile_limit) tile_number = 0;
|
||||
}
|
||||
|
||||
color = attrib & 0x0fff; // 0x0f00 priority, 0x007f colour
|
||||
SET_TILE_INFO_DEVICE(
|
||||
@ -404,8 +388,6 @@ void gp9001vdp_device::device_reset()
|
||||
top_flip = 0;
|
||||
sprite_flip = 0;
|
||||
|
||||
tile_limit = 0xffff;
|
||||
|
||||
/* debug */
|
||||
display_bg = 1;
|
||||
display_fg = 1;
|
||||
|
@ -50,7 +50,6 @@ public:
|
||||
UINT8 top_flip;
|
||||
UINT8 sprite_flip;
|
||||
|
||||
UINT16 tile_limit; // prevent bad tile in Batsugun, might be something like the CPS1 tile addressing limits?
|
||||
int tile_region; // we also use this to figure out which vdp we're using in some debug logging features
|
||||
tilemap_t *top_tilemap, *fg_tilemap, *bg_tilemap;
|
||||
|
||||
|
@ -510,9 +510,6 @@ VIDEO_UPDATE( batrider )
|
||||
|
||||
|
||||
|
||||
/* How do the dual VDP games mix? The internal mixing of each VDP chip is independent, if you view only a single
|
||||
VDP then the priorities for that VDP are correct, however, it is completely unclear how the priorities of the
|
||||
two VDPs should actually mix together, as a result these games are broken for now. */
|
||||
VIDEO_UPDATE( dogyuun )
|
||||
{
|
||||
#ifdef DUAL_SCREEN_VDPS
|
||||
@ -526,10 +523,6 @@ VIDEO_UPDATE( dogyuun )
|
||||
|
||||
VIDEO_UPDATE( batsugun )
|
||||
{
|
||||
toaplan2_state *state = screen->machine->driver_data<toaplan2_state>();
|
||||
state->vdp1->tile_limit = 0x1fff; // 0x2000-0x3fff seem to be for sprites only? (corruption on level 1 otherwise)
|
||||
|
||||
|
||||
#ifdef DUAL_SCREEN_VDPS
|
||||
VIDEO_UPDATE_CALL( toaplan2 );
|
||||
#else
|
||||
|
Loading…
Reference in New Issue
Block a user