Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02800 Speed Major Always Jan 5, 2009, 01:56 Jan 22, 2009, 15:21
Tester Haze View Status Public Platform MAME (Self-compiled)
Assigned To Mamesick Resolution Fixed OS Windows XP/Vista 32-bit
Status [?] Resolved Driver gstream.cpp
Version 0.129 Fixed in Version 0.129u2 Build Normal
Summary 02800: gstream: gstream is running at half speed (at 100% framerate)
Description the game is now running at half the normal speed, despite the framerate being displayed as 100%

this is because the old broken speedup hack was reintroduced. I have no idea why this was done as I fixed the problem a while back.

to fix the problem just use the code from the previous release, which is correct...
Steps To Reproduce
Additional Information
Regression Version 0.129
Affected Sets / Systems gstream
Attached Files
There are no relationship linked to this issue.
User avatar
Senior Tester
Jan 5, 2009, 02:04
the only 'gstream' related entry i see in the whatsnew is

Converted the following drivers to use scanline interrupts, partial
updates, and raw video parameters: [Mamesick]
 * ddragon
 * gstream
 * vball
 * xain
 * chinagat

which is not an accurate description of the changes which have been made to the driver (adding sound banking hacks, and reintroducing a broken speedup hack)
User avatar
Jan 5, 2009, 06:57
edited on: Jan 5, 2009, 06:59
The only change to the speedup hack (which was not 'reintroduced') was that it was changed from activecpu_eat_cycles(50) to activecpu_spinuntil_int(). Looks like that was an error.

I over-edited the description on that one, should have mentioned the sound banking improvement. Which is an improvement in both documentation and end result, even if it's not the way the hardware worked.
User avatar
Senior Tester
Jan 5, 2009, 07:11
with active_cpu_eat_cycles(50) the video completely goes out of sync with audio. That's why I used spinuntil_int(). We need a verification againts real hardware that the game is not so slow on the original PCB too.
User avatar
Senior Tester
Jan 5, 2009, 07:35
edited on: Jan 5, 2009, 07:43
I find it highly unlikely the game runs that slow, updating only every 2 or 3 frames.

Given how dubious the entire sound implementation is (and I'd still argue moreso now than before, the comments are interesting, but I find that code implementation to be horrific) then it seems a more obvious choice to assume that the sound implementation is wrong. The entire thing sounds out of tune anyway.

Please also note that with the correct speedup (or no speedup at all) the behavior is that the game updates every frame. A speedup hack should never change the actual behavior of the game.
User avatar
Senior Tester
Jan 7, 2009, 16:29
Using two interrupts per frame (which is an hack) the game is really really fine. The speed is ok and all things are in-sync properly. I don't think that a simple sound banking routine is the cause... more likely we have to find the correct speedup address as it has been done for vamphalf in this release. My two cents.
User avatar
Senior Tester
Jan 7, 2009, 19:05
right.. putting 2 interrupts per frame clearly isn't right, because it would break the game completely if you removed the (broken) speedup hack. That was what the limenko driver used to do, when it was broken, before I fixed it... Speed hacks should never change behavior, and a game should never depend on hacks built on top of speed hacks to run...

If you skip until the next interrupt then you miss other events such as vblank flags changing, sound status flags changing, or timed interrupts (if they're based on cycle count, not real timers)

If you just burn a few cycles (which is what the working speedup did) then you're far less likely to miss any flag changes.