Help troubleshooting my custom preset

[8BitMonk]

Looking for help troubleshooting my custom preset (at bottom).

The issue is with 320 vertical games. Groovymame pushes games like ddonpach (ddonpach 240x320@57.550644) into range (crt_range7) and runs it at 2560x464@60hz. I think it should be using crt_range4 where the vertical resolution matches at 320. It runs and looks ok but this seems wrong, it seems like it should use a range that matches vertical resolution.

In other instances like aerofgt (224x320@61.310001) it picks the right range (crt_range4) but gets the vFreq wrong (2560x320_60 22.00KHz 58.67Hz). As you can see it's too low.

Not sure why it's picking the wrong range for ddonpach and then when it does pick the right range for aerofgt the vFreq is incorrect.

I've attached logs for aerofgt and ddonpach.

------ CUSTOM PRESET -------
crt_range0    15625-15900, 50-59.96, 3.03, 6.134, 6.763, 0.067, 0.200, .532, 0, 0, 192, 248, 448, 496
crt_range1    15625-16240, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
crt_range2    16029-17200, 50-80, 1.220, 4.728, 7.626, 0.190, 0.191, 1.018, 0, 0, 249, 256, 498, 512
crt_range3    18300-18800, 50-58, 8.300, 2.750, 9.000, 0.190, 0.191, 1.018, 0, 0, 257, 280, 514, 560
crt_range4    18448-22000, 50-80, 6.278, 2.058, 7.410, 0.799, 0.828, .876, 0, 0, 281, 320, 0, 0
crt_range5    24000-25000, 50-80, 1.163, 3.595, 1.798, 0.081, 0.162, 0.889, 0, 0, 384, 400, 0, 0
crt_range6    24000-29000, 50-80, 1.549, 2.820, 6.502, 0.225, 0.150, 2.021, 0, 0, 384, 400, 0, 0
crt_range7    30000-34000, 50-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 448, 496, 0, 0
crt_range8    34001-38000, 50-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 512, 600, 0, 0

Thanks for any help!

[cools]

How do they run if you force the resolution?

[8BitMonk]

Hi cools,

They ran good if I forced the resolutions.

I was actually able to resolve this myself last night. To get aerofgt to run right I just needed to up the HfreqMax on range4 as aerofgt was running a little over 22Khz the max was set at. Upping it to 23500 fixed it. To fix ddonpach which was mistakenly selecting the higher ranges I upped the HfreqMax from 50 to 58 for ranges 5,6,7 in order to skip it since it's running at 57.55.

That seemed to do the trick and not negatively affect any other games so far.

------ CUSTOM PRESET -------
crt_range0    15625-15900, 50-59.96, 3.03, 6.134, 6.763, 0.067, 0.200, .532, 0, 0, 192, 248, 448, 496
crt_range1    15625-16240, 59.98-80, 3.000, 4.700, 7.700, 0.190, 0.191, 1.018, 0, 0, 192, 248, 448, 496
crt_range2    16029-17200, 50-80, 1.220, 4.728, 7.626, 0.190, 0.191, 1.018, 0, 0, 249, 256, 498, 512
crt_range3    18300-18800, 50-58, 8.300, 2.750, 9.000, 0.190, 0.191, 1.018, 0, 0, 257, 280, 514, 560
crt_range4    18448-23500, 50-80, 6.278, 2.058, 7.410, 0.799, 0.828, .876, 0, 0, 281, 320, 0, 0
crt_range5    24000-25000, 58-80, 1.163, 3.595, 1.798, 0.081, 0.162, 0.889, 0, 0, 384, 400, 0, 0
crt_range6    24000-29000, 58-80, 1.549, 2.820, 6.502, 0.225, 0.150, 2.021, 0, 0, 384, 400, 0, 0
crt_range7    30000-34000, 58-80, 0.636, 3.813, 1.906, 0.020, 0.106, 0.607, 0, 0, 448, 496, 0, 0
crt_range8    34001-38000, 50-80, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 512, 600, 0, 0

[Calamity]

Hi 8BitMonk,

You have spotted an actual flaw in the modeline scoring algorithm. This problem, as well as a bunch of others, was introduced with the support for super resolutions. Hopefully I'll be able to iron these out for the next version of the patch.

Basically, the problem with ddonpach is that the scoring algorithm should not penalize the need for fractional scaling on the horizontal *when* cleanstretch 2 is being used. Currently, if any fractional scaling is required the modeline gets a poor score. If you have two possible resolutions to choose from and both require fractional scaling and also both allow for perfect vertical refresh then the determining factor is the highest resolution, that's why 464p is being used instead of 320p, ignoring that 320p is integer scaled on the vertical. This special case only happens when you use super resolutions and is what needs to get fixed.

So raising the lower vfreq values from the upper ranges to 58 will work but it's a bad workaround because it is not properly defining your monitor but instead it's just a way to bypass a current bug in GM. You'd better keep the original values and use an .ini for ddonpach provisionally.

On the other hand raising the high hfreq value for crt_range4 does make perfect sense, and it's the kind of fine tuning that needs to be done.

As you have noticed, given a certain hfreqmin-max range it's usually not possible to achieve the whole vfreqmin-max range for all the vertical resolutions allowed for that range. It's simple arithmetic. Higher vertical resolutions will require a higher hfreq for the same vfreq. Once hfreqmax is reached increasing the vertical resolution is only possible by decreasing the vertical refresh. (etc)

Keeping the ranges as 50-80, even if the monitor's manual says it supports up to 80 Hz, is probably unpractical. I'd just use 50-65 for all ranges from crt_range5 and above.

BTW if it's actually the horizontal frequency what matters for memorizing adjustments with this monitor I'm wondering if it's still required to split crt_range0 in two ranges as we do now (59.96/59.98).

[8BitMonk]

Hi Calamity,

Ahh so that's what it was with ddonpach! I wondered if the logic was off somewhere, I was looking at the calculations in the logs and couldn't for the life of me figure out why it wanted to pick 464.

Thanks for all the info and feedback, good stuff to know.