Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
04493 Speed Minor Always Sep 22, 2011, 21:19 Jun 7, 2021, 20:28
Tester Afdal View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows XP (32-bit)
Status [?] Confirmed Driver taito_f3.cpp
Version 0.143 Fixed in Version Build Normal
Fixed in Git Commit Github Pull Request #
Summary 04493: arkretrn, elvactr, landmakr, dungeonm, quizhuhu, popnpop, trstar, puchicar, qtheater, gunlock, recalh, ridingf: Slow game speed
Description The following games run slowly at erratic speeds, typically lower than 75% of full game speed: arkretrn, quizhuhu, popnpop, puchicar, qtheater, gunlock, recalh, & ridingf.

In addition, the following games are affected as well, but nowhere near as badly: elvactr, landmakr, dungeonm, & trstar. While they do not go below 90% speed, they refuse to play smoothly at a consistent full 100% speed.

Other Taito F3 games do not appear to be affected.
Steps To Reproduce Run a game (preferably one of the more severely affected ones) for a minute or so.
Additional Information Bugs encountered on Windows XP SP2 with AMD dual-core 4200+ CPU and ATI Radeon X1600 graphics card.

This speed issue does not exist in 0.142 and earlier versions of MAME, and though I have not extensively tested all the games with each incremental update, it appears to still be a problem as of 0.143u6.

Revision (r12073) is the cause of the performance loss.
Github Commit
Regression Version 0.142u1
Affected Sets / Systems arkretrn, elvactr, landmakr, dungeonm, quizhuhu, popnpop, trstar, puchicar, qtheater, gunlock, recalh, ridingf
Attached Files
There are no relationship linked to this issue.
User avatar
Senior Tester
Sep 22, 2011, 21:48
there does seem to have been a non-negligible speed drop in the driver, yes.

They still all run at over 100% on my C2D, but given the other recent speed drops I can't help but wonder if it's related. I can't think of anything specific that's changed relating to these drivers tho.
User avatar
Senior Tester
Sep 22, 2011, 22:38
edited on: Sep 22, 2011, 22:48
ok, Tafoid traced it back.

It actually comes from the code I added to fix the football games crowd display.

Unfortunately that's an unavoidable slowdown with the current way MAME works, as the driver now has to manage twice as many tilemaps on those games, simply because the crowd was previously in an area not covered by the tilemaps, while a bit in the lineram clearly allows access to that area, requiring there to be tilemaps there.

Given that all games are the same hardware, that applies to all games in the driver even if they don't specifically use that part of the tilemap. Any case where all tilemaps get marked as dirty will be inherently slower due to the additional tilemaps. (and from memory there are a few situations where this can happen)

The only real way to fix it that I can think of would be to avoid the tilemap system completely, which is an option, and might end up being necessary for full and proper video support in the driver. (it's due a rewrite anyway)
User avatar
Sep 22, 2011, 22:44
Updated fields and confirmed report for now. It might be closed later as this is a largely unavoidable performance drop due to the added enhancements to other games in the driver, as Haze described.
User avatar
Senior Tester
Sep 22, 2011, 22:47
edited on: Sep 23, 2011, 11:37
I'm happy for it to be left open, I don't really think the performance in that driver is what you'd call acceptable especially when you consider the sheer number of glitches still present, it could definitely be better, but will take a significant reworking of some of the code to get there IMHO.
User avatar
Jun 7, 2021, 20:28
I doubt this is a valid report, since unfortunately performance will have further hit(s) if we ever emulate properly several features (namely the per-scanline color register setups).