Done some test, sadly switchres now doesn't pick the best resolution (right res, but wrong Hz):
Hi Haggar,
Yes, there was a bug in the scoring system that only affected the -nomodeline_generation case. Now it should be fixed (015b).
Now, in order to get it working properly with your own modelines, you need to help GroovyMAME a bit:
- Your custom modelines will still be passed through the sanity check (hfreq, vfreq, etc.), this means that you need to use a monitor preset that is compatible with your modelines, otherwise they will be labelled as "out of range" and rejected. When cloning your modeline list in my system, this is the preset that worked fine for me:
monitor custom
crt_range0
15700-16720, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576
- I noticed there are some problematic modelines in your mode table. The one that failed with "wiz", for instance, you have it labelled as 401x256 but is defined internally as 401x258
Switchres: [ 42] 401x 256 @ 54: DALDTMCRTBCD401x256x0x54 - Modeline "401x258_54 15.47KHz 54.48Hz" 8.03 401 420 460 519 258 261 264 284 -hsync -vsync)This makes DirectDraw crash. The resolution defined in the detailed timings can't be bigger than the one in the label. The other way round, however, does work. Another example (wrong):
Switchres: [ 20] 320x 200 @ 60: DALDTMCRTBCD320x200x0x60 - Modeline "320x240_60 15.70KHz 59.91Hz" 6.53 320 329 385 416 240 242 245 262 -hsync -vsync- For cases where an interlaced mode would be used normally, like when playing donpachi on a horizontal monitor, you'll see that using -nomodeline_generation usually results in picking a low resolution progressive mode. This happens because when fractional stretching has been determined as the best possible choice, the algorithm prioritizes mathing the refresh rate rather than going for a higher resolution. So it will just pick the modeline with the closest refresh rage ignoring the resolution. There isn't a good workround for this but creating a good list of interlaced resolutions with the expected resfresh rates or as close as possible (e.g. 57.55 Hz in the case of donpachi). This is what VMMaker does by default. As a last resource you can always force GroovyMAME to pick a specific mode by using an .ini file. This problem doesn't happen when you use -modeline_generation as GroovyMAME then is capable of adjusting the refresh as desired and just goes for the highest resolution where the target refresh is feasible.
- Since recent versions of GM, a much better approach for using hand-adjusted modelines is no longer using a read-only mode list with the -nomodeline_generation option, but instead, create a dynamic mode table with VMMaker, use -modeline_generation in GroovyMAME and pass the hand-adjusted modelines using the raw format in the .ini file, e.g.:
## This is goldnaxe.ini ##
modeline "320x240_60 15.70KHz 59.91Hz" 6.53 320 329 385 416 240 242 245 262 -hsync -vsync
It's a lot of work but this way you're not limited by the driver's capacity: you can indeed create your own modeline library with hundreds of them. Besides, this is the only way to bypass the sanity check, so you can use whatever crazy frequencies you want.
Home
Help
Search
Login
Register
Send this topic
Print
Topic: GroovyMAME 0.171 - SwitchRes v0.015m (Read 228924 times)
