I quite don't get the part where the game you run in the second place still runs at 100%. This shouldn't be the case. Are you possibly using the -frame_delay here? By using the -syncrefresh option only, the speed should adapt automatically to the refresh rate.
Yes, I'm using the frame_delay. See attached log.
At first I thought that it could be that the first time the resolution is used, the values are read from registry and never updated, but since you said that you have measured the speed before (62.199) and after (57.499) then the modeline is read at least twice. Why wouldn't it be read more than twice? Mystery.
I'm not sure what you mean by the highlighted line?
Now I don't even know if the 'dynamic' stuff could not be a side effect of patching the drivers...
I'm getting the feeling that the dynamic stuff -is- indeed a side effect of patching the drivers. I did an additional test that made me realize how things might actually be working..
I turned things once again around from the previous post where arcade_osd would read the 256x240_62 refresh right after a reset as 62.199, but after running snowbros it would show the snowbros refresh rate (even though showing all the _62Hz modeline parameters).
So my hypothesis is that the -first- time a screenmode resolution is opened, the video driver is putting the modeline parameters for the specific resolution in a temporary structure and is sticking with these values for the rest of the Windows session. They will as such be unmodifiable for the rest of the session also.
So another way of testing the hypothesis is to first open the 256x240_62Hz screen with arcade_osd and then run snowbros. If the hypothesis is correct, then with this sequence of first opening the screen with arcade_osd and then starting GM, it will not be able to modify the refresh for snowbros to 57.5Hz. So I did run it in this sequence and indeed it confirms the predicted behaviour, see the attached log:
Average speed: 108.17% (41 seconds)
Sound: buffer overflows=160 underflows=0
The speed at 108.17% is an *exact* reflection of snowbros running at 57.5Hz and the screen "stuck" at 62.199Hz (62.199/57.5=108.17%).
With these and the previous findings it seems to be becoming quite clear what is happening. Basicly the video driver is putting all opened screenmode resolutions during a session in a "shadow/temporary" structure, which it calls upon again when the -same- screenmode is opened again during the session. For these resolutions it does that instead of re-reading the registry.
This seems to perfectly explain all observed behaviour and why it's possible that arcade_osd (after first starting snowbros) will show all correct modeline parameters for the 256x240_62Hz screenmode, while actually testing the refresh will result in the refresh of 57.5Hz. So in detail this is what happens.
Run Snowbros:
1: GM modifies the modeline to 57.5Hz
2: Video driver opens the resolution with the 57.5 modeline values and puts the 256x240 resolution in its "temporary" structure with the modified refresh / modeline parameters. Snowbros runs at the correct 57.5Hz modeline speed.
3: close GM -> GM restores the original _62Hz modeline to the registry.
Next run Arcade_OSD:
Open the 256x240_62Hz resolution. Two things happen:
1: Arcade_OSD reads the modeline values for 256x240 from the registry -> finds the _62Hz modeline characteristics and shows these values in edit modeline
2: The video driver bypasses the registry modeline values, because the screenmode has been opened previously during the session, and *thus* calls the 256x240 resolution from the "temporary" structure, opening the screenmode with the earlier created 57.5Hz refresh parameters!
This results of course in arcade_osd measuring the 57.5Hz refresh, even though reading the registry values would suggest otherwise. Of course at this point, once a specific resolution is put in the drivers' "shadow / temporary" structure, reading values from the registry is futile.
So basicly, if this is how things are (approximately) working, the only solution would be a hack of the video driver which enables GM to "reset" or clear the "shadow / temporary" structure at the same time when it restores the modeline. I'm not sure, but possibly you have seen similar behaviour like this when patching/hacking the driver for XP?
In any case if this would make sense and you would ever want to take a stab at the Windows 7 *64-bit* video driver, there's a particular thing to note. In Windows 7 64-bit all drivers are enforced to be signed with a valid certificate. I'm not sure what is involved in hacking the driver, but I can imagine that it would break the signature/certificate validation. Luckily there's a way around this. The solution is to put Windows 7 64-bit in "test mode", which allows the installation of unsigned drivers. The tool to put it in test mode can be found here:
Driver Signature Enforcement Overrider 1.3b
http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=826I understood that you're not very much looking forward to hacking a driver again. But if you were to take a look at hacking again then hopefully you'll consider looking at the 12.6 legacy driver. Basicly because it has a number of benefits:
- it's the final (very) stable release for HD 2000/3000/4000 cards;
- it has a release for both WindowsXP, Windows 7 AND Windows 8, making it futureproof (compatible with new hardware) for the foreseeable future;
- because it's a separated driver it will work very well with dual gfx-card setups, making it possible to additionally install the very latest video-card and driver, creating the ultimate combination of oldskool CRT arcade/console emulation and "newskool" PC gaming, all from one machine.
Possibly because it's the same driver version for XP, 7 and 8 (some of) the hacks, once done for one driver, can be ported over to the drivers for the different platforms? I guess this would involve quite a lot of work still, but the benefit would be having one final set of hacked drivers, that will show the same behaviour across platforms, and not having to be updated ever again (i guess that will be of major importance).
I want to thank you again for your detailed tests, they're of great value.
Thanks. It's definitely my pleasure to be of help in this great project. I really appreciate all of the effort and dedication that you've been putting into bringing (CRT) perfection to the already insanely great mainline MAME/MESS/UME project.