Software Support > GroovyMAME
Do switchres monitor presets always display game content in some form?
nix999:
I have a question about switchres presets such as pal ntsc and arcade_15.
Give that a game has a 'Working' status in MAME is it correct to expect GroovyMAME to show at least some output on screen when launched with a preset.
Using for example
./groovymame inthunt -monitor pal
or
./groovymame inthunt -monitor ntsc
or
...
I have Sony Trinitron PAL SCART television set that is used with a custom build Arch.
I tried to find information about the capabilities of the TV and slightly modified the arcade_15 settings found on
https://gitlab.com/groovyarcade/support/-/wikis/3-Post-Installation-and-Maintenance/3.5-Monitor-Definitions#built-in-monitor-definitions
to fit as much as possible and that range is in mame.ini and the monitor is set to custom.
I set the dotclock_min to 6.0 and tested some games like wboy, toki, sf2, cabal and they all center nicely and run absolutely fine.
Then I found out that my TV cannot display some content even though a valid mode gets calculated. It displays rolling content from top to bottom.
This is the case for mk, mk2, mk3 mk4 and likely others.
Next I made a bash script that reads the names from ./problematic_games.txt and if it is in there I get the refresh rate from the given game's xml and if it is lower then 55hz I launch it with
-monitor pal
and if it is above I launch it with
-monitor ntsc.
The idea is that I use the slightly modified arcade_15 preset to make as much games as possible run native - if I can call it that - and force the exceptions to pal or ntsc the TV can display.
All was fine at that point until ...
What I did not expect is to find games that loose sync on all presets.
From the looks of it they are all NeoGeo games such as In The Hunt and Puzzle Bobble. I tested other games and for one game the TV showed the blue information screen but it also lost sync after.
I do not understand what I am doing wrong.
Any hints about a correct approach please?
Thank you.
Zebidee:
I've found that many TVs do OK at close to both 60hz or 50hz, but lose sync at close to ~55hz.
This being the case, the default generic_15 and arcade_15 default presets are insufficient as they cover a large range from 49.50hz to 65.00hz, without blocking out the middle frequencies. This means they can generate modes at ~55hz that the TV cannot display.
My solution was to create a custom monitor preset that includes multiple ranges, for both "NTSC" and "PAL". That way you can specify the valid frequencies for each. It looks something like this
--- Quote ---monitor "ChinaTV1", "China TV - 50/60 Hz", "4:3"
crt_range0 15625.00-15750, 49.50-55.00, 1.500, 4.700, 5.800, 0.191, 0.191, 1.056, 0, 0, 192, 288, 448, 576
crt_range1 15625.00-15750, 55.01-62.00, 2.000, 4.700, 6.200, 0.256, 0.191, 1.200, 0, 0, 192, 248, 448, 480
--- End quote ---
The above example is what I use with my "China" TV. The switchres driver chooses the most appropriate crt_range based on the maximum number of permitted lines allowed. Each range has a max progressive lines specified, which I've bolded above.
For example: if you chose to launch MK2, which wants 254p, switchres checks the lowest range (crt_range1, "NTSC") first. This allows max 248 progressive lines, or 248p, not enough. So it moves onto the next range (crt_range0, "PAL"), which allows up to 288p, and uses a 256p video mode generated from that range.
You might have noticed that, in the above example, I didn't actually block out any frequencies around 55hz - that is because my "China" TVs are fine with handling 55hz. So why do I even use the split ranges? Because the TVs default to different screen geometries based around "NTSC" and "PAL" signals, and automatically change depending the signal received! By modifying the crt_ranges to align with this, the front/backporch values can be further tweaked to ensure a better "screen fit" for the video modes.
If you wanted to limit video modes to just those close to 50hz and 60hz, and block out most frequencies in-between, you might use a preset like this:
--- Quote ---monitor "NTSC/PAL only", "PAL/NTSC 50/60hz only", "4:3"
crt_range0 15600-15900, 49.50-50.00, 2.000, 4.700, 4.700, 0.064, 0.192, 1.056, 0, 0, 192, 288, 448, 576
crt_range1 15600-15900, 59.50-61.00, 2.000, 4.700, 5.800, 0.064, 0.192, 0.898, 0, 0, 192, 248, 448, 480
--- End quote ---
You could even specify PAL for only 50hz exactly, and NTSC for only 59.94hz exactly, if you really wanted to.
The horizontal frequencies specified are less important. I usually just use the same for each crt_range, covering the total for both.
I guess you could specify a preset with three separate sets of crt_range values, hone in on those 55hz modes, but I don't see a compelling reason to do so with TVs - especially given they seem to usually default to "NTSC" or "PAL" modes of operation.
I don't know how Calamity thinks about this, or if this is what was intended - I "improvised" this approach based on existing implementations for dual-sync monitors. Looking at it a certain way, TVs that work for both 50hz and 60hz ARE dual-sync, auto-switching monitors. I don't know if this will work the same for you, but is what I've found works for me. Feel free to tinker, try playing around with it to see what works for you.
** Disclaimer: I use Win7+CRT_emulator+GM, not Retroarch, but I think all the same theory applies.
For further queries, maybe attach a log file.
Calamity:
Yes, the method explained by Zebidee is how this is supposed to be handled.
--- Quote ---Give that a game has a 'Working' status in MAME is it correct to expect GroovyMAME to show at least some output on screen when launched with a preset.
--- End quote ---
Yes, GroovyMAME will always show some output on the screen. If you have a certain game that goes out of sync, try to find the reason. If you have dotclock issues, 8.0 is a reasonable minimum (rather than 6.0). Note that the lower end of admitted dotclocks may have gaps (i.e. 5.5 may work, 5.6 not, etc.) until you find a number that works fine from there on.
nix999:
Ok. Thank you for the detailed responses. I'll tinker a bit more and report back. I'll attach a log file if I can't sort it out. It might take some days. Probably next weekend.
One thing I do see is that my system never generates 2560x... modes. It is always much lower though 2560 is in mame.ini super_resolution it's called if I'm not mistaking.
I do not understand why it behaves that way but I'll document it and report back.
I also started from a fresh ini created with ./groovymame -cc.
The dotclock 6.0 is what made Cabal work.
I'm not using RetroArch. It's a bash shell with groovymame 0.280 and some scripts around it.
nix999:
I got a whole lot further but I'm still not there.
I increased dotclock to 8.0
These two ranges make every game I started thus far run ~100%
crt_range0 15600-15800, 49.50-50.20, 2.000, 4.700, 5.800, 0.064, 0.192, 1.056, 0, 0, 192, 288, 448, 576
crt_range1 15600-15800, 59.30-60.50, 2.000, 4.700, 5.800, 0.064, 0.192, 0.898, 0, 0, 192, 248, 448, 480
The issue I have is that in general the screen is off to the left and too wide.
I can use the slider controls
CRT H size between 0.70 and 0.65
CRT H shift between -2 and -7
Seem to do the trick.
This means I need to adapt every game manually.
I already tried putting them in default.cg but they get stripped it seems. I might need to create a wrapper script to pre-create the cfg files.
I'll look into that a bit further.
But ideally the two ranges should be adjusted to cope with the issue I just described.
I do not succeed unfortunately.
The 2nd issue I have I cannot solve using the slider controls as there is no CRT V size in the slider menu.
If I use MAME's own Screen Vert Stretch combined with MAME's own Screen Vert Position or CRT V shift I get artifacts.
For In The Hunt for example in the bottom to top scrolling monster demo I see the background being re-drawn in a choppy way.
What really happens is that the Top op the screen is correct but the bottom section falls off.
I see for example the top letters in some demo scene perfectly positioned but the bottom score is 75% visible.
Ideally the two ranges should be adjusted to also cope with the issue I just described.
I do not succeed either unfortunately.
If I have to adapt every game for issue 1 so be it. I'd rather avoid to but it is manageable I of course would like to solve it in general.
But the 2nd one is worse ...
Can someone assist in adapting the two ranges I posted please or give me some hints how that's supposed to work.
Thank you.
EDIT: Perhaps this is helpfull:
inthunt.cfg
<sliders>
<slider desc="CRT H size" value="700" />
<slider desc="CRT H shift" value="-2" />
</sliders>
generated mode with these settings:
./groovymame inthunt
Switchres/SDL2: Detected SDL version 2.33.0
Switchres: Calculating best video mode for 320x240@60.012478 orientation: normal
Switchres: Modeline "640x240_60 15.603244KHz 60.012478Hz" 12.404579 640 665 723 795 240 242 245 260 -hsync -vsync
Switchres: Calculating best video mode for 320x240@60.012478 orientation: normal
Switchres: Modeline "640x240_60 15.603244KHz 60.012478Hz" 13.262757 640 680 742 850 240 242 245 260 -hsync -vsync
So the first Modeline is a result from range_1 it seems and the 2nd one seems to be a recalculation based on the <sliders></sliders> tag
So the 2nd Modeline effectively solves problem1 - by hand - but not problem2
Navigation
[0] Message Index
[#] Next page
Go to full version