summaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
author angelosa <salese_corp_ltd@email.it>2018-01-26 21:14:33 +0100
committer angelosa <salese_corp_ltd@email.it>2018-01-26 21:17:06 +0100
commit780d0a14c7b2cac06f5f3207094d84c4858a0981 (patch)
tree3c5387dadc054d8edf3a428924480f9f82cde7f4
parente3ca055051e9f7511abbc0785cdc486e05409cce (diff)
taito_f3.cpp: Removed outdated kludge for Darius Gaiden [Angelo Salese]
-rw-r--r--src/mame/includes/taito_f3.h1
-rw-r--r--src/mame/video/taito_f3.cpp11
2 files changed, 7 insertions, 5 deletions
diff --git a/src/mame/includes/taito_f3.h b/src/mame/includes/taito_f3.h
index 9d3e91b7679..d894b11a36b 100644
--- a/src/mame/includes/taito_f3.h
+++ b/src/mame/includes/taito_f3.h
@@ -120,7 +120,6 @@ public:
uint16_t *m_f3_pf_data_6;
uint16_t *m_f3_pf_data_7;
uint16_t *m_f3_pf_data_8;
- int m_f3_skip_this_frame;
int m_sprite_lag;
uint8_t m_sprite_pri_usage;
bitmap_ind8 m_pri_alp_bitmap;
diff --git a/src/mame/video/taito_f3.cpp b/src/mame/video/taito_f3.cpp
index 184079ee0af..91ef77cb681 100644
--- a/src/mame/video/taito_f3.cpp
+++ b/src/mame/video/taito_f3.cpp
@@ -668,8 +668,6 @@ VIDEO_START_MEMBER(taito_f3_state,f3)
m_gfxdecode->gfx(0)->set_source((uint8_t *)m_f3_vram.get());
m_gfxdecode->gfx(3)->set_source((uint8_t *)m_f3_pivot_ram.get());
- m_f3_skip_this_frame=0;
-
m_sprite_lag=m_f3_game_config->sprite_lag;
init_alpha_blend_func();
@@ -830,12 +828,17 @@ READ16_MEMBER(taito_f3_state::f3_lineram_r)
WRITE16_MEMBER(taito_f3_state::f3_lineram_w)
{
+ #ifdef UNUSED_FUNCTION
/* DariusGX has an interesting bug at the start of Round D - the clearing of lineram
(0xa000->0x0xa7ff) overflows into priority RAM (0xb000) and creates garbage priority
values. I'm not sure what the real machine would do with these values, and this
emulation certainly doesn't like it, so I've chosen to catch the bug here, and prevent
the trashing of priority ram. If anyone has information on what the real machine does,
please let me know! */
+ /* Update: this doesn't seem to occur anymore, I'll leave this snippet in but commented out.
+ * fwiw PC=0x1768a0/0x1768a4 is where the game clears lineram in round D, which is a
+ * move.w Dn, (An,D7.w*2) , a kind of opcode that could've been bugged back then.
+ */
if (m_f3_game==DARIUSG) {
if (m_f3_skip_this_frame)
return;
@@ -844,7 +847,8 @@ WRITE16_MEMBER(taito_f3_state::f3_lineram_w)
return;
}
}
-
+ #endif
+
COMBINE_DATA(&m_f3_line_ram[offset]);
}
@@ -3147,7 +3151,6 @@ uint32_t taito_f3_state::screen_update_f3(screen_device &screen, bitmap_rgb32 &b
{
uint32_t sy_fix[5],sx_fix[5];
- m_f3_skip_this_frame=0;
machine().tilemap().set_flip_all(m_flipscreen ? (TILEMAP_FLIPY | TILEMAP_FLIPX) : 0);
/* Setup scroll */