 No.03497
Haze 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) |
|---|---|
 No.03501
aaron Developer
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. |
 No.03502
Mamesick 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. |
|
No.03503
Haze 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. |
|
No.03519
Mamesick 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. |
|
No.03522
Haze 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. |