custom Define your own custom by means of -crt_range lines
pal PAL TV - 50 Hz/625
ntsc NTSC TV - 60 Hz/525
generic_15 Generic 15.7 kHz
arcade_15 Arcade 15.7 kHz - standard resolution
arcade_15ex Arcade 15.7-16.5 kHz - extended resolution
arcade_25 Arcade 25.0 kHz - medium resolution
arcade_31 Arcade 31.5 kHz - high resolution
arcade_15_25 Arcade 15.7/25.0 kHz - dual-sync
arcade_15_25_31 Arcade 15.7/25.0/31.5 kHz - tri-sync
m2929 Makvision 2929D
d9200 Wells Gardner D9200
d9400 Wells Gardner D9400
d9800 Wells Gardner D9800
k7000 Wells Gardner K7000
k7131 Wells Gardner 25K7131
m3129 Wei-Ya M3129
h9110 Hantarex MTC 9110
polo Hantarex Polo
pstar Hantarex Polostar 25
ms2930 Nanao MS-2930, MS-2931
ms929 Nanao MS9-29
vesa_480 VESA GTF
vesa_600 VESA GTF
vesa_768 VESA GTF
vesa_1024 VESA GTF
Note: labels are no longer case sensitive
-crt_range 0-9 HfreqMin-HfreqMax, VfreqMin-VfreqMax, HFrontPorch, HSyncPulse, HBackPorch, VfrontPorch, VSyncPulse, VBackPorch, HSyncPol, VSyncPol, ProgressiveLinesMin, ProgressiveLinesMax, InterlacedLinesMin, InterlacedLinesMax
-lcd_range VfreqMin-VfreqMax
#
# CORE SWITCHRES OPTIONS
#
-modeline Generate modelines for arcade monitors
-monitor Monitor type, e.g.: generic_15, arcade_15, lcd, custom, etc.
-orientation Monitor orientation (horizontal|vertical|rotate)
-connector [Linux] video card output (VGA-0|VGA-1|DVI-0|DVI-1)
-interlace Enable interlaced scanning when necessary
-doublescan Enable double scanning when necessary (unsupported under Windows)
-cleanstretch Force integer scaling, 0 means automatic selection
-changeres Enable dynamic in-game video mode switching
-powerstrip Use Powerstrip API for dynamic setting of custom video timings
-lock_system_modes Lock system (non-custom) video modes, only use modes created by us
-lock_unsupported_modes Lock video modes reported as unsupported by your monitor's EDID
-refresh_dont_care Ignore video mode's refresh reported by OS when checking ranges
-dotclock_min Lowest pixel clock supported by video card, in MHz, default is 0
-sync_refresh_tolerance Maximum refresh difference, in Hz, allowed in order to synchronize
-frame_delay Delays the start of each frame to minimize input lag (0-9)
-lcd_range Add custom LCD range, VfreqMin-VfreqMax, in Hz, e.g.: 55.50-61.00
-crt_range0 Add custom CRT range, see documentation for details.
-crt_range1 Add custom CRT range
-crt_range2 Add custom CRT range
-crt_range3 Add custom CRT range
-crt_range4 Add custom CRT range
-crt_range5 Add custom CRT range
-crt_range6 Add custom CRT range
-crt_range7 Add custom CRT range
-crt_range8 Add custom CRT range
-crt_range9 Add custom CRT range
Amazing! :o
I'm itching to try this! :))
This looks amazing, I'm now itching to get some free time and try this out on my cabinet :)
Really happy to see this progressing so much, good job guys!!!
I'll hopefully find free time to play with this some myself, free time for me is rare but for the amount this has progressed I am rather excited about finding some time to try it out!
While doing some first tests with the new frame_delay feature, I also found something interesting that fixes the issue with the <240 line modes running way too fast on my setup (win7+soft15khz), as we spoke about some time ago (see: http://forum.arcadecontrols.com/index.php/topic,120331.msg1313434.html#msg1313434 (http://forum.arcadecontrols.com/index.php/topic,120331.msg1313434.html#msg1313434)). That speed issue for those specific screenmodes is completely fixed now when I set the frame_delay parameter to 1 (or higher)!
Can't wait to try this. Do I add groovy.exe to a MAME download or a MESS download?
Nice, going to check it out.
So in mame ini I just select the ms2930 settings as my monitor and in vmmaker I still add the timings of the 2931 right?
Can't wait to try this. Do I add groovy.exe to a MAME download or a MESS download?
If you're using GroovyUME then get the MESS download, but for GroovyMAME I usually start with an empty folder.
One question though, is there a way to stop it sounding like a wonkey record when the CPU can't keep up? For instance Tekken Tag does lag a little bit on my system but still perfectly playable, though it now sounds awful whereas before it just skipped a bit now and then.
Is this soundsync doing it's thing? I didn't see an option to disable it.
I can't get killer instinct or KI2 to work, it even doesn't create a log file!
Screen just blinks and get back to windows, they do work in mameplus 0.147
Edit:Nevermind, got it working needed a fresh Mame install...a copy to my old 0.143 setup caused the problem.
@Krick,
I think the issues related to vector games are solved, I used the list you provided for testing, anyway let me know if you still experience any problem. I considered to add your options for vector games, but I found that the default look of vectors varies depending on the api used (ddraw/d3d/sdl) so I thought I'd better leave the user decide.
I tried to run GroovyMAME 147, and Im having slowdowns on all games, regardless of the actual amount of resources they need.
Can you please check my settings for an ArcadeVGA 3000 type setup. I think I got it right now. Before I would never have to touch the ini so I am just making sure.
15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,576
should become15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576
According to the new "crt_range" parameter, this old monitor_specCode: [Select]15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,576
should becomeCode: [Select]15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576
Is that right?
Yes, those would be the right settings for the 3000. If you have the chance, please attach a log here so I can see how the modes are being reported by the system and guess if there's some potential problem (I don't have one here to test that's why I'm asking).
As requested. See attached. I am giving you two examples, one that works and one that does not.
Mspacman looks like it is not syncing with the monitor. It just scrolls a lot.
One thing I forgot to mention is that this latest version of GroovyMAME makes the QMC2 front-end (http://qmc2.arcadehits.net/wordpress/ (http://qmc2.arcadehits.net/wordpress/)) to hang during initialization. It's because the front-end looks for the MAME/UME version number in the exe and can't find it in the expected place, because the GroovyMAME Switchres version information is there:
Thanks for reporting this Dr.Venom. This will need to get fixed on the next update.
Anyway, that's too bad about QMC2, that's not an ortodox way of retrieving the version of MAME if you ask me, they should be using the XML information instead.
Hi cack01, thanks for your logs.
I've noticed several things:
- For some reason you're using the '-monitor vertical' option for mspacman. I guess this is intended, because you are physically rotating your monitor. Otherwise you should leave it as 'horizontal'.
.............................................
So I've been doing some tests these days, and the new option named -frame_delay is going to be ready for the next release. I've done it so that a frame time is divided in 10 parts, so a frame_delay value of 0 (default) means the emulation starts at the beginning of the frame time, as always.
As for the hardware part, do yourself a favour and grab an old ATI Radeon card, any model from Radeon 7000 to the HD 4xxx family should work, both AGP and PCIe models. As far as we know, there is nothing that can remotely compare to these cards in terms of flexibility.
I'm not too familiar with GroovyMAME yet. Would the Geforce card even work, or do I need something running the Catalyst drivers? If it would work, would it be less flexible for timing adjustments than the Radeon? It's worked fairly well so far. How would I check if a Radeon card could be better?
I'm not unwilling to go ahead and pay for some more video cards if I'll get better results, but I just want to make sure if I will or not.
Modeline "400x256@52,4Hz 15,6KHz (60Hz)" 8.080 400 416 456 519 256 268 271 297 -hsync -vsync
Modeline "448x240@60,0Hz 15,9KHz (60Hz)" 9.160 448 464 512 576 240 243 246 265 -hsync -vsync
Modeline "720x480@59,9Hz 31,5KHz (60Hz)" 29.250 720 752 824 928 480 486 489 526 -hsync -vsync
Modeline "640x480@59,6Hz 31,3KHz (60Hz)" 26.180 640 672 736 836 480 486 489 525 -hsync -vsync
Modeline "512x512@58,3Hz 31,8KHz (60Hz)" 21.210 512 538 594 668 512 513 516 545 -hsync -vsync
Modeline "512x448@59,9Hz 31,6KHz (60Hz)" 21.210 512 542 598 672 448 469 472 527 -hsync -vsync
Modeline "512x384@60,0Hz 24,6KHz (60Hz)" 14.750 512 520 568 600 384 388 391 410 -hsync -vsync
Modeline "496x384@60,0Hz 25,0KHz (60Hz)" 15.475 496 508 570 620 384 388 391 416 -hsync -vsync
Modeline "640x288@51,0Hz 15,7KHz (60Hz)" 13.100 640 672 736 832 288 289 292 309 -hsync -vsync
Modeline "640x240@60,0Hz 15,9KHz (60Hz)" 13.220 640 672 736 832 240 243 246 265 -hsync -vsync
Modeline "632x264@56,8Hz 15,8KHz (60Hz)" 13.000 632 664 728 824 264 265 268 278 -hsync -vsync
Modeline "512x288@50,9Hz 15,9KHz (60Hz)" 10.680 512 544 600 672 288 289 292 312 -hsync -vsync
Modeline "512x240@60,0Hz 15,9KHz (60Hz)" 10.680 512 544 600 672 240 243 246 265 -hsync -vsync
Modeline "368x240@59,2Hz 15,6KHz (60Hz)" 7.470 368 384 424 478 240 243 246 264 -hsync -vsync
Modeline "384x288@51,2Hz 15,8KHz (60Hz)" 7.850 384 400 440 496 288 289 292 309 -hsync -vsync
Modeline "392x240@59,9Hz 15,9KHz (60Hz)" 8.000 392 408 448 504 240 243 246 265 -hsync -vsync
Modeline "480x240@60,0Hz 15,7KHz (60Hz)" 9.306 480 488 532 592 240 241 244 262 -hsync -vsync
Modeline "512x240@60,0Hz 15,7KHz (59Hz)" 9.935 512 520 567 632 240 241 244 262 -hsync -vsync
Modeline "512x256@53,0Hz 16,5KHz (53Hz)" 10.583 512 520 561 640 256 274 277 312 -hsync -vsync
Modeline "512x264@53,0Hz 16,5KHz (53Hz)" 10.583 512 520 561 640 264 278 281 312 -hsync -vsync
Modeline "576x240@60,0Hz 15,7KHz (60Hz)" 11.193 576 584 637 712 240 241 244 262 -hsync -vsync
Modeline "592x240@60,0Hz 15,7KHz (60Hz)" 11.444 592 600 654 728 240 241 244 262 -hsync -vsync
Modeline "608x240@60,0Hz 15,7KHz (60Hz)" 11.821 608 616 672 752 240 241 244 262 -hsync -vsync
Modeline "640x200@60,0Hz 15,7KHz (60Hz)" 12.324 640 648 706 784 200 221 224 262 -hsync -vsync
Modeline "640x240@60,0Hz 15,7KHz (59Hz)" 12.324 640 648 706 784 240 241 244 262 -hsync -vsync
Modeline "640x256@53,0Hz 16,5KHz (53Hz)" 13.229 640 648 700 800 256 274 277 312 -hsync -vsync
Modeline "672x240@60,0Hz 15,7KHz (60Hz)" 12.953 672 680 741 824 240 241 244 262 -hsync -vsync
Modeline "704x256@53,0Hz 16,5KHz (53Hz)" 14.552 704 712 769 880 256 274 277 312 -hsync -vsync
Modeline "704x264@53,0Hz 16,5KHz (53Hz)" 14.552 704 712 769 880 264 278 281 312 -hsync -vsync
Modeline "704x288@53,0Hz 16,5KHz (53Hz)" 14.552 704 712 769 880 288 290 293 312 -hsync -vsync
1) new monitor preset like arcade_15ex are not recognised in vmmaker.ini, is it normal? Or you plan to release another vmmaker version?
2) it seems that new groovymame does not support -md option to create log file when you run a game. Is there another way?
The new version of GM will work with NVidia cards by interfacing with Powerstrip. This means you can use your current setup, so if you have created your resolutions with Soft-15kHz or even Powerstrip, then GM will pick them. But the interesting part here is that if you enable the -powerstrip option GM can also recalculate the timings for a given resolution and have it available on the fly. If you're familiar with Powerstrip you'll know it has a limitation that it can only store a custom timing for each resolution. Well, this method overrides this limitation, so for example, you only need to create an instance of the 256x224 resolution, and GM will adjust its vertical refresh on the fly for all the variations required. However, you're still limited by the NVidia drivers that only allow defining 31 custom resolutions simultaneously.
For my tests I used one Geforce Go 7400, which might be similar to your card. I noticed having some issues with low dotclocks, so I ended up using this mode list (lower resolutions are doubled on the horizontal):
Notice the above list is for a tri-sync arcade monitor!
I achieved pretty decent results with this method. Before you decide whether to switch to ATI, I'd appreciate if you tested this. Just make sure to backup your current video modes, because GM will overwrite whatever you have carefully tweaked with Powerstrip and it doesn't restore it afterwards, so you may end up loosing your current settings. Powerstrip will only "remind" the last timings used for each mode, whatever they are.
This method is not perfect, unfortunately. We have to trust on Powerstrip for succesfully creating the desired dotclock, but sometimes the obtained dotclock is too off and we end up with a lowered refresh rate, or it's not even stable. These are things that you can sort out when you create a mode manually, but an algorithm can't know beforehand whether the target dotclock will work or not, unless you create a black list or something. Fortunately, you can often identify the problematic dotclock ranges and avoid them, that's what I did by doubling some resolutions on the table above. So it definitely requires some effort on your part to get everything working. This is experimental stuff after all.
That's great, but does it have to use an automatically calculated timing value? I prefer to adjust all the timing values myself in Powerstrip, so I can have both a correct refresh rate and the precise geometry that I want. I do this starting with test patterns, and then adjust it for practical things in the game itself, like overscan cutting off health bars, highscore, etc.
For example, could I tell GroovyMAME the exact timing values to use with 320x240 when it loads up a neogeo.c game?
Hey Calamity,
You've done such a wonderful job on Groovymame! Congratulations on creating something that makes so many people happy.
:notworthy:
I've recently switched my winxp setup to an Arch installation and am having a bit of an issue.
I'm using the 'ms2930' monitor preset and when I try to run dkong I'm getting the following as output:
SwitchRes: [dkong] (1) vertical (224x256@60.61)->(400x256@57.12)
SwitchRes: ProgressiveLinesMax 768 out of range
SwitchRes: Error in monitor range (ignoring): 31000-32000, 50-65, 0.330, 3.580, 1.750, 0.316, 0.063, 1.137, 0, 0, 576, 768, 0, 0
I got a better screen while I was running windows. I'm probably missing something simple, but can't find it. Any suggestions?
I am still testing and I have found quite a few games with slowdowns. Refresh related slow downs.
It might be configuration related. You should always post your basic setup specs when asking for help........
I wouldn't say you need hundreds of modelines. In most cases you can set them up on a hardware driver basis, and individual game adjustments aren't needed.
Even if you use the automatic mode most of the time, I think it's pretty critical to be able to go manual in special cases as you say.
An idea when raw modeline support will be added? If the capability of using generated timing values is already there, wouldn't it be fairly simple to bypass the formulas and use values from the ini file? You could implement that first before taking the time to add it to the UI.
Advanced users wouldn't need any error handling either. If the modeline is bad, let it crash. If we're creating these modelines, we can verify they're working ahead of time.
More than five hundred, indeed :). A different story as that many of them belong to non-so-relevant games.
QuoteAn idea when raw modeline support will be added?Well, it should be ready for the next release, that's for sure.
By now, you can safely use GM with your own modes, as any other version of MAME, just make sure to have the -powerstrip option disabled. You need to have the -modeline option enabled anyway otherwise the -frame_delay option won't work.
Also, you'll need to disable the -lock_system_modes option, as your modes will be detected as 'system' modes, as opposed to 'custom' modes that are the ones we create for the Catalyst cards.
Finally, maybe you need to enable -refresh_dont_care, depending on how you labelled the refresh rate values of your modes.
Sorry about that.
XP 64
Intel i5 @ 2.8ghz
ArcadeVGA 3000
GM 0.147u3 64bit
Have tried with -syncrefresh set to 0 & 1 in the GM ini.
Pretty much has to be configuration/new GM version as these games will all play fine when modelines is turned off in GM 0.147u3. Pre GM 0.147 I would just have to put the *.exe in the directory set monitor to generic and off I go. There are a lot more settings now, so I just trying to troubleshoot and see what works best with the AVGA 3000.
Do you mean 500 variations including timing variations, or 500 resolutions that are all different in terms of basic active height and width?
I was thinking I would have to program my front-end to adjust the timing values in the driver or something, right before launching the game.
You mean manually switching to my modeline, then starting the game? I can wait for next version.
Timing variations of course.
Well, definitely you're going to do figure out some automated method to pass the modelines to GroovyMAME through .ini or command line, is that what you mean?
Hi crack01,
That's odd because your log looks perfectly fine. The only interesting bit is that it's performing a resolution switch while in the game, but that's the expected behaviour. So, what are you seeing exactly? A slowdown? By refresh related slowdown I mean that the game shows a solid slowdown, not variable, of say 92% or whatever. If you get a variable rate then that's something different. Well for a refresh related slowdowns, you can either modify the refresh (you can use ArcadePerfect for your AVGA 3000) or enable -triplebuffer for that particular game (let's say that -triplebuffer is the opposite to -syncrefresh in this context). If, as you said, switching -modeline off fixes the issue, please attach a log here of the same game with -modeline off so I can compare.
Thanks for the continued help. Slow down is constant and usually about 76%. I am attaching three logs:
Modelines on: Slow Down
Modeline off: Good
Modeline On & Triple Buffer On: Good
Triple buffer seems to fix it although I have no idea what it does and if/why we use it. ???
Thoughts?
I tried to run GroovyMAME 147, and Im having slowdowns on all games, regardless of the actual amount of resources they need.
All games? Or just a few of them? Vertical games? Slowdowns can be either CPU related, or refresh rate related (check your monitor settings, generic_15 is very conservative, try arcade_15). Try disabling -syncrefresh from command-line to find the answer, or... go into Game Information and check if the game is running at its native refresh or if it's been reduced to meet your monitor specs,
etc.
arcade_15 did the trick... 100% speed and perfect sync. now on to understand the new modelines syntax and get my old settings back :)
Ok, you're just saying it's a lot of timing variations to set up. I though you were referring to running over the nVidia 31 custom res limit.
Most resolutions should fit inside a common one, like running 384x224 centered in 392x240 and adjusting the border into the overscan. As long as I have unlimited timing variations, I'm good.
I meant my front-end would have a manually defined record of the the timing values for each game. The game would be set up in MAME to switch to the right resolution, but the front end would edit the graphics driver to adjust the timing values for the selected game just before launching MAME.
It would have been an enormous pain in the ass. I don't even know if I'd be able to make adjustment to the driver that would take effect before restarting. I hadn't begun working on it yet.
What do you mean I'll need an automated method to pass the modelines to GroovyMAME? Once raw modeline support is added, can't I just manually type them into the individual hardware driver or game's .ini?
I could have the front-end pass them when launching through command line too, but it would be good to be able to store them in the .ini's.
Even just counting the different resolutions (ignoring refresh variations), it's quite beyond the NVidia 31 custom res limit, especially if you consider implemeting the MESS side
by doing a clever use of the border sizes, as you're suggesting, you can simulate having many more resolutions, that's a huge lot of work but if properly done it should be perfect.
That's similar to how the SwitchRes app works (before it was integrated in MAME), but unfortunately that wouldn't work for NVidia, because their drivers only seem to read custom video definitions on boot , according to my tests, so you can't edit them dynamically unless you use a third party app like Powerstrip.
Of course the new option should pick the modelines directly from driver o game's ini
anyway what's important now is to add this functionality, and let users find the best way for them to use it.
Thanks for the continued help. Slow down is constant and usually about 76%. I am attaching three logs:
Modelines on: Slow Down
Modeline off: Good
Modeline On & Triple Buffer On: Good
Triple buffer seems to fix it although I have no idea what it does and if/why we use it. ???
Thoughts?
Are you by any chance using the new -frame_delay option? Make sure it's disabled if you're seeing speed issues.
I really need to see your compared logs of the same game with -modeline on/off, both with -syncrefresh (leave apart the -triplebuffer by now). That should point to one direction or other.
Tempest is still not working for me. Suggestions? I also don't understand fully how to use the new lines or at least how to find out what progressive and interlaced ranges make sense for my monitor. Can someone help out?
It's basicly the successor of the hantarex polo... Its from the same manufacturer that bought hantarex (called 'monitor') based in Florence. I have my custom modeline, I just need to know how to use the new lines.
No, it's extended 15khz. I know what the new lines are doing, I just don't know how to find out what's good/bad for my monitor.
I tested all tempest versions and they all do the same: First a blue screen, then yellow flicker, then black... that's basicly it. No report of broken or missing roms.
Fresh mame.ini: Yes. Magic resolutions: Yes. I'm using d3d with a HD4350. Would love to post a logfile but can't seem to save it... I know I have to use the -v command, but how do I save the log? Sorry for the noobish question.
thanks, here's the log. I'm not even shure what hlsl is. Is it disabled by default in the new mame.ini... were else should it be deactivated!?
I actually only had to delete an old ini I had for tempest... it screwed something up. Works now... thanks ;)
Hi maxpontello,
Yes, GM overrides the installed modelines because it recalculates them on the fly. By now, the way to adjust geometry is by editing the crt_range options, for shifting the picture to the right you need to reduce the horizontal front porch. This will affect all modes.
threads=1
ff=1
monitor=m3129
aspect=4:3
...
monitor_specs0 31000.00-32000.00, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 576, 768
monitor_specs1 auto
monitor_specs2 auto
monitor_specs3 auto
monitor_specs4 auto
monitor_specs5 auto
monitor_specs6 auto
monitor_specs7 auto
...
monitor m3129
monitor custom
crt_specs0 31000.00-32000.00, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0
monitor custom
crt_specs0 15250-16500, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 1, 1, 224, 288, 448, 576
crt_specs1 23900-24420, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 1, 1, 320, 384, 0, 0
crt_specs2 31000-32000, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0
Try 1.8 for instance. The back porch affects the left border. Another approach is: launch Arcade_OSD, set the resolution you use for bublbobl as you have adjusted it, then enter the horizontal geometry menu and copy the values there (front and back porches), then use those into the crt_range line.
Hi emuola,
I assume your using the GM v0.147u3, Linux and the Wei-Ya M3129. Please refresh my memory: why would you want to only use the 31kHz range if yours is a tri-sync monitor? You probably had a reason, it's just that I can't remember now.
Anyway, leave alone the switchres.conf
You only need to create a fresh mame.ini (the options you posted are out of date), then edit the option 'monitor' with:Code: [Select]monitor m3129
Now, this sets GM to use the three ranges (15-24-31), with GM's default settings for M3129. If you just want to use the 31 kHz range, and your custom settings, do the following (still in mame.ini):Code: [Select]monitor custom
crt_specs0 31000.00-32000.00, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0
If you wanted to enable the three ranges, but setting the 31 kHz range with your custom settings, do this:Code: [Select]monitor custom
crt_specs0 15250-16500, 40-80, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 1, 1, 224, 288, 448, 576
crt_specs1 23900-24420, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 1, 1, 320, 384, 0, 0
crt_specs2 31000-32000, 55-65, 0.33, 3.58, 1.75, 0.316, 0.063, 1.137, 0, 0, 480, 512, 0, 0
Emuola, I don't think you understand what the different modes mean, and the significance of running native resolutions. It sounds like someone gave you some advice that... I won't say it's bad advice, but they were just trying to tell the easiest thing to do, with no regard to what would actually give you a good picture and make the most of your monitor.
Basically, one of the main points of GroovyMAME is to help run these games in their native resolution, meaning the resolution they originally ran in the arcade. 90% of games in MAME originally ran in resolutions around 320x240, meaning they ran in 15kHz resolutions.
15kHz = anything around 320x240 progressive (240p) OR 640x480 interlaced (480i)
25kHz = anything around 512x384 progressive
31kHz = anything around 640x480 progressive (480p)
If you run these 15kHz games in native res they'll be sharp, and they will have authentic scanlines; they'll really look good. If you run them in 31kHz they have to be upscaled (stretched out to fit a larger resolution), they'll probably be either too blurry or too sharp, and the scanlines will be gone; they won't look nearly as good.
Now games that are actually meant for 31kHz will look great in 31kHZ. Same thing with 25kHz. Everything generally looks best in its native resolution.
The whole point of a Tri-Sync is to be able to display all these different resolutions. I'm sure you paid a good amount of money for that thing, so you should put some work into getting a good pictre out of it. If you're just using it for 31kHz and scaling everything lower up, it's not much better than a computer monitor.
If GM can control settings through Powerstrip, couldn't I program my front-end to do the same though? I won't need to with GroovyMAME, but I may need to set timing values before launching a PC game.
check the GM's source, there's a file named pstrip.c
I plan to buy some wiimote to play gun games on groovymame and I'd like to ask you some informations to be sure to make the right choice:
I still have one suggestion/question: concerning the ones that use GroovyMame on a flat screen or videoprojector, is it possible to reproduce something like that only with software : http://shoryuken.com/forum/index.php?threads/t-slg-toodles-scanline-generator-authentic-retro-look-from-your-modern-flatscreen.145407/ (http://shoryuken.com/forum/index.php?threads/t-slg-toodles-scanline-generator-authentic-retro-look-from-your-modern-flatscreen.145407/) because it's apparently a huge improvement in term of confort !
Calamity,
I just want to say a quick thanks for all the hard work you and anyone has put into GroovyMame! It truly is a great piece of software and provides unmatched results when it comes to picture quality! Thanks again and happy holidays M8!
(ps, it is also extremely easy to setup! I used to spend hours trying to fine tune my old setups!)
Remind me what ini settings i need to set if im using a LCD display?
Remind me what ini settings i need to set if im using a LCD display?
It's easier than before. You just need to set the 'monitor' option to 'lcd'
Then, if you're using Powerstrip, enable the 'powerstrip' option.
Finally, define the range your monitor can actually refresh, e.g.:
-lcd_range 57.50-61.00
where do i need to place the, refresh value for my monitor in the mame.ini file?
Do i need powerstrip installed, or can you get away without using it. Any ideas if theres a program that tells you what actual refresh rate your monitor supports? I have a DELL 2405FPW, im guessing its just 50-60hz
Exception at EIP=01CE9124 (not found): ACCESS VIOLATION while attempting to write memory at.......
A friend of mine got this error whenever he tries to start a rom:Code: [Select]Exception at EIP=01CE9124 (not found): ACCESS VIOLATION while attempting to write memory at.......
He is using groovymame-0.147u4 32bit self-compiled on windows (using the new official toolchain).
He can't test official build because there is no "groovymame-0.147u4" (at least I can't find it here (http://code.google.com/p/groovyarcade/downloads/list)).
A friend of mine got this error whenever he tries to start a rom:Code: [Select]Exception at EIP=01CE9124 (not found): ACCESS VIOLATION while attempting to write memory at.......
He is using groovymame-0.147u4 32bit self-compiled on windows (using the new official toolchain).
I just wanted to comment that Pac-Man runs flawlessly with the new GroovyMAME. It looks great, the sound is perfect, the speed seems correct. I wasn't able to get it running this good with the older version of GroovyMAME. Namely, the sound was always off because the game was running slower to sync with the video. What changed?
Patch updated for MAME 0.148.
Please test it before upload on the official site.
I made a groovymame-0.147u4 and encountered a similar error.The error persists.
The solution is to move/delete the NVRAM and/or CFG files of the offending ROM and let MAME rebuild them.
Try it and let us know.
He tried with shinobi, mk, gng, snow bros and sf2.
Hi Calamity,
I plan to use GroovyMame on an arcadebox with a old CRT TV but also sometime with a LCD. How may I get original-31khz games to work on their original frequencies on LCD ?
Thanks a lot.
Monkee
For some reason he has the -modeline option disabled. That shouldn't cause GM to crash (it did in older versions), but I wonder if there's still some bug related to it. First tell him to enable the -modeline option. Apart from that the custom modelines are not being read, this is probably because of the order the displays are listed. How many video cards are there in that system?He said, he never used the "-modeline" option either with previous versions, but he will try to enable it.
For some reason he has the -modeline option disabled. That shouldn't cause GM to crash (it did in older versions), but I wonder if there's still some bug related to it. First tell him to enable the -modeline option.The problem persists even with "-modeline" option enabled.
He said, he never used the "-modeline" option either with previous versions, but he will try to enable it.
The system has two video cards:
- ati 9250 pci (not pci-e) set as "primary" into bios (this is only used to prevent the boot phase to show up)
- secondary video card used for everything else
Please consider the attached patch for your new switchres (it removes a very bad segfault and takes care of 64 bits installs).
Do the old monitor spec lines still work or are they different, i have a Samsung LCD TV so not sure what i need place in the lcd-range line now?See the first post (http://forum.arcadecontrols.com/index.php/topic,128879.msg1316985.html#msg1316985):
- New format for defining custom monitor specs, now the -crt_range0-9 options are used. This is the most important change in this version from the user's point of view, as the existing custom definitions will need to be modified. Not big deal however, but make sure you understand how this works as it will guarantee your success with GroovyMAME. The usual timing values remain the same, but the line limiters are replaced by four values: ProgressiveLinesMin, ProgressiveLinesMax, InterlacedLinesMin, InterlacedLinesMax. These are used to easily define the upper and lower limits of the total logical resolutions GroovyMAME should allow, both for the progressive and the interlaced range. You may leave either one of the two ranges set as zero in case you do not want progressive or interlaced modes to be generated. So the current format is as follows:Code: [Select]-crt_range 0-9 HfreqMin-HfreqMax, VfreqMin-VfreqMax, HFrontPorch, HSyncPulse, HBackPorch, VfrontPorch, VSyncPulse, VBackPorch, HSyncPol, VSyncPol, ProgressiveLinesMin, ProgressiveLinesMax, InterlacedLinesMin, InterlacedLinesMax
- Automatic LCD timings generation. This is useful in combination with PowerStrip. Your current timings will be read from PowerStrip and used to recalculate modelines from them. You just need to define the range for the vertical refresh your monitor supports:Code: [Select]-lcd_range VfreqMin-VfreqMax
Calamity, can you please help me with my Nanao MS2390 setting? I want it to only run in 15khz for now. I do i know what values to use for the new custom monitor setting? When i just plug in the old setting, the scanlines disappear. Any help?
With this new version of Groovymame is it possible to get smooth vertical scrolling on an LCD screen with powerstrip?
Do the old monitor spec lines still work or are they different, i have a Samsung LCD TV so not sure what i need place in the lcd-range line now?
Calamity, can you please help me with my Nanao MS2390 setting? I want it to only run in 15khz for now. I do i know what values to use for the new custom monitor setting? When i just plug in the old setting, the scanlines disappear. Any help?
Just define the monitor as 'custom' and add this line:
crt_range0 15450-16050, 50-65, 3.190, 4.750, 6.450, 0.191, 0.191, 1.164, 0, 0, 192, 288, 448, 576
The -md option is no longer used, use just -v to get the logs. Consider opening a separate thread se we can follow there.
Some of the new features are: multiple window/display support (e.g. play-choice games), user-defined raw modelines, progressive/intelaced mode switching in W7, resolution masks, etc.
Does this also mean dual monitor/display support for games like Sega Outrunners? :P
1. How is the frame delay option coming along? Please forgive me if it's already out in a current version or patch, I'm waiting for the modeline control to make the switch.
2. I noticed in the first page here that you said Linux is the best operating system to run GM right now. Could elaborate on the differences/benefits? Would it have a significant advantage in terms of input lag over a well-configured XP64 setup?
Some of the new features are: multiple window/display support (e.g. play-choice games), user-defined raw modelines, progressive/intelaced mode switching in W7, resolution masks, etc.
Does this mean we will be able to update to Windows 7? That would be great! Thanks for the update!
Does this also mean dual monitor/display support for games like Sega Outrunners? :P
Yep ;)
But hopefully also GM not breaking MAME's multi screen support, as it does now. So you could use the second head for a LCD marquee and stuff like that.
Quick question, I can't get hiscores to save.
I understand why some users decide to disable the -modeline option but now all the resolution picking logic passes through this option so disabling it makes GM fall back to MAME's default resolution picking algorithm which does not perform any safe frequency check, etc.
I need to modify this somehow in future versions so that the -modeline option is always on and possibly add some extra option to ensure that the installed modelines are read-only if the user wants to.
Just a 'hotfix' update and resyncing to current baseline MAME.
Seem to be having a strange issue with 0.147u3. When i select 'LCD' as the monitor in mame.ini mame gives me this message in the attached file when loading a rom
Ahh sorry heres the correct one....
Please post a log of this, I need to see what's happening for a possible fix. I never use GroovyMAME without the -modeline option so I don't detect these issues myself.Sure, I'll post it this evening.
As I have explained many times, disabling the -modeline option also disables the pick_best_mode logic built in GroovyMAME and all the throttling decisions are made based on that. The -modeline option should never be disabled, it's just there for testing purposes. You'd better find the right specs for your monitor.I know that, but after many failing attempts to find a right monitor spec I decided to go through the dirty standard way.
Future versions will have this -modeline thing redesigned so people can use their own custom modelines without compromising the normal behaviour.That sounds promising. :)
I know that, but after many failing attempts to find a right monitor spec I decided to go through the dirty standard way.
Horizontal scan freq.: 15.625KHz +/- 500Hz
Vertical scan freq.: 50Hz
Here the logs.
In fact with 147u3 I have the same problem. 146u4 worked fine.
The rom i've used is "wiz".
Patch updated for MAME 0.148u4.
Please test it before upload on the official site.
Ok have just compiled a 0.148u2 version of groovymame, and am interested in trying out the other console emulators. Do i have to compile UME aswell or is that already in the GM diff file?
Thanks, it works. Sadly that option is useful for many titles like strider 2, etc, so I have to disable it for all vertical games and I don't know how to do it automatically...
Sorry for the late answer. Yes, I see the problem. You can probably fix it by disabling the -changeres option in mame.ini
(This is not required when using the -modeline option)
now triplebuffering is automatically triggered when the refresh difference if higher than specified by the -syncrefresh_tolerance option. As this is set to 2.0 Hz by default, it means that for 288-line resolutions, which usually won't run higher than 52-54 Hz on arcade monitors, -syncrefresh is turned off and -triplebuffer is used instead. This is great for non scrolling games like pacman. You can play with the -syncrefresh_tolerance option in order to decide how off the refresh must be for enabling this behaviour.One question. Triple buffer introduces massive lag, so how can I be sure that groovymame doesn't use it? Someting like "-syncrefresh_tolerance 999"?
-"And he did give them CRT bloom, and it scorched their eyes so; and they wept
openly, for there was nothing left to see with" [MooglyGuy]
* Enabled vector bloom and associated .ini controls
* Added raster bloom and associated .ini controls, each bloom "level" is the
linear weight of successively half-sized render targets
* Removed D3D8 mode
* Mass renaming in D3D renderer to use namespaces, initial planning step to
HAL-based renderer implementation on Windows (i.e., GL on Windows)
* Converted d3d_info, d3d_poly_info, and d3d_texture_info into classes
* Added batching of vectors for possible speed increase
* Minor cleanup of shader state setting
Ok, it turned out it wasn't that hard to update the patch finally, I have a working build here. I still need to test it and I'd like to add some fixes, it will be released as 014b within this week. Still none of the new "big" features I'm working on in a parallel experimental patch 015.Very happy to read this.
What do i need to change in the mame.ini file to tell mame to run in 1280x720 instead om my windows resolutions?
This is the first version with native Windows 7 support.
Yeah thanks a lot for this amazing stuff calamity !
I just build a small conf this week end with a AMD sempron, 2gb ram and a Ati HD4350.
Your emu drivers works like a charm, and all the modelines were created easily with VMMAKER.
I also installed for the first time groovymame32 148u5.
For some reason, I can't get my fav' games ssf2 and ssf2t to run (CPS2) ; it says roms are missing (I got a full .148 mame romset)
Is it a problem with groovy, or maybe the roms has been changed between .148 and .148u5 ?
Cheers,
Apply hi_148u5.txt (how do i do this same as the diffs???)
Apply Groovy Diff
Compile Mame
Copy Groovy Mame EXE over the top of Mame exe or am i good to go because i complied it as a package???
Stupid questions:
Is Groovymame going to be nice on a videoprojector or a plasma screen? Or does it will suffer from the same problems you get on a LCD?
Does the CRT_EmuDriver will make my windows work on 15Khz all the time after booting ? Because I want to use the computer as a HTPC too and on my CRT too so I guess I need this frequence all the time.
Thanks :)
Does the CRT_EmuDriver will make my windows work on 15Khz all the time after booting ? Because I want to use the computer as a HTPC too and on my CRT too so I guess I need this frequence all the time.
In my dedicated MAME cabinet I am using a betson imperial 27" and a radeon 4890. I am looking for the best graphics quality out of the multi-frequency arcade monitor.
Am I better of:
1) using the groovy mame liveCD
2) using windows 7 and groovymame
Also is there any front end built into groovymame and/or can I install one after the fact?
In my dedicated MAME cabinet I am using a betson imperial 27" and a radeon 4890. I am looking for the best graphics quality out of the multi-frequency arcade monitor.
Am I better of:
1) using the groovy mame liveCD
2) using windows 7 and groovymame
Also is there any front end built into groovymame and/or can I install one after the fact?
1) Is possibly the best
2) Is NOT a possibility yet (it will be soon)
However you're missing option 3) for some reason:
3) using Windows XP x64/x86 and GroovyMAME
This is posible right now and offers the very same graphics quality than Linux.
You'll probably want to install a separate front-end to lauch GM from (it does contain the basic MAME's internal menu).
In this thread here, there is a lot of work done to get the betson imperial monitor working with groovymame. http://forum.arcadecontrols.com/index.php/topic,117489.0.html (http://forum.arcadecontrols.com/index.php/topic,117489.0.html)
Are all of these settings built into groovymame now? I did not see this monitor listed in the separate thread about monitors.
If I use both a old CRT and a new videoprojector for groovymame, does CRT_emudriver will do the job by itself or do I have to set something up?
And concerning GroovyArcade, do you plan to release it without the live cd, I mean will I be able to install it on (Xbmc)Ubuntu one day ?
Patch updated for MAME 0.149.
Please test it before upload on the official site.
CRT Emudriver is "passive", it just enables some video modes to your specs. You have to care about setting the right resolution to the right output, depending on the device you plan to attach.Can you explain me how to do that? Sorry if it's a stupid question, i'm still struggling a bit with the functionalities. :-\
Mmmm, GroovyArcade and the live cd are much the same thing, it's a full operating system. You can't simply install it on Ubuntu. You'd need to patch some kernel elements and roll your own modified Ubuntu clone of GroovyArcade, if that's what you mean.Thanks Calamity, that's exactly what I mean. Then I'll stay with Windows :)
Can you explain me how to do that? Sorry if it's a stupid question, i'm still struggling a bit with the functionalities. :-\
Patch updated for MAME 0.150.
Please test it before upload on the official site.
Patch updated for MAME 0.150.
Please test it before upload on the official site.
By latest build, do you mean you compiled your own based on v0.150?
You need to use this option (as in the previous versions):
aspect 16:9
By latest build, do you mean you compiled your own based on v0.150?
Yeah the one Ansa89 posted above
I used that and complied it with the latest mame0.150 source (along with hi score and cave sh3)
By latest build, do you mean you compiled your own based on v0.150?
Yeah the one Ansa89 posted above
I used that and complied it with the latest mame0.150 source (along with hi score and cave sh3)
I tried compiling 0.150 I got the hiscore and groovy diff patched but get this error when trying to patch the cave diff. If I ignore the error I then get a error right at the end of compiling.
Let me know if you want me to start a new topic :)
C:\MameCompiler\MameSrc150>patch -p0 -E 0<cavesh3_147u3.diff
patching file src/mame/drivers/cavesh3.c
patching file src/mame/drivers/csh3blit.c
patching file src/mame/mame.lst
Hunk #1 succeeded at 39 with fuzz 2.
patching file src/mame/mame.mak
Hunk #1 FAILED at 1740.
Hunk #2 FAILED at 2379.
2 out of 2 hunks FAILED -- saving rejects to file src/mame/mame.mak.rej
By latest build, do you mean you compiled your own based on v0.150?
Yeah the one Ansa89 posted above
I used that and complied it with the latest mame0.150 source (along with hi score and cave sh3)
I tried compiling 0.150 I got the hiscore and groovy diff patched but get this error when trying to patch the cave diff. If I ignore the error I then get a error right at the end of compiling.
Let me know if you want me to start a new topic :)
C:\MameCompiler\MameSrc150>patch -p0 -E 0<cavesh3_147u3.diff
patching file src/mame/drivers/cavesh3.c
patching file src/mame/drivers/csh3blit.c
patching file src/mame/mame.lst
Hunk #1 succeeded at 39 with fuzz 2.
patching file src/mame/mame.mak
Hunk #1 FAILED at 1740.
Hunk #2 FAILED at 2379.
2 out of 2 hunks FAILED -- saving rejects to file src/mame/mame.mak.rej
Nevermind. Found this little page of goodness http://www.systempixel.fr/extra/ (http://www.systempixel.fr/extra/)
Been getting screen tearing since 149 on my LCD screen, have tried enabling tripplebuffer but doesnt seem to sort the problem. Anything else to try in the ini file?
- New option -frame_delay. Delays the start of the emulation of each frame by an amount of time defined in tenths of the frame period length (0-9), in order to give a chance to the emulator to have the most possible updated input for that frame, as an attempt to minimize input lag. A value of 0 corresponds to standard behaviour. This option is experimental, and is known to produce tearing in LCD screens.
Is there a patch yet for the improved frame delay, to help with input lag??
Is there a patch yet for the improved frame delay, to help with input lag??
Not yet, but the official patch for v0.150 will have it.
the official patch for v0.150Is there a release date for that patch?
Do u know if this will sort the tearing issues on LCD displays?
Is there a release date for that patch?
Is there a patch yet for the improved frame delay, to help with input lag??
Not yet, but the official patch for v0.150 will have it.
How does this affect GroovyMAME?...