Author Topic: GroovyMame for arcade monitors version 0.146u4_013f (Read 196818 times)

Calamity · « **Reply #80 on:** May 06, 2011, 04:28:29 pm »

Hi zorrobandito,

Probably the last driver installation messed with the previous one. Try cleaning any ATI software using CatUninstaller.

Also that blue screen you had before should not happen unless there's some previous problem. Which version were you using 6.5/9.3 XP32/64? When did you download them? (try getting the newer ones)
Which AVGA model?

If you go back to the hacked drivers, see how many custom modes Arcade_OSD shows (it's the number showed between () ). If it's below 100 (60 probably) that means the hacked drivers are not the ones running, even if you have 15Khz output it's actually default Windows drivers the ones that take control, that would explain why upper resolutions make the system crash. That usually happens with XP distributions that ship their own MS drivers and for some reason the system refuses to accept our drivers taking its own decisions without informing us. In those cases you have to manually uninstall that default driver, from Device Manager/Display Adapters/Properties. You'll know your system is more likely to be receptive to our drivers if after rebooting it's unable to get a compatible device driver for your card.

That said, you actually NEED to use ddraw without hwstretch to benefit from hacked drivers + GroovyMame. It's GroovyMame the one that will use the right options for you, even hwstretch when there's the need for it. Our new -syncrefresh and -triplebuffer options are only implemented for DirectDraw. Create a new mame.ini with GroovyMame and only edit it with your roms path and your monitor type.

Let us know your progress.

lettuce · « **Reply #81 on:** May 07, 2011, 05:57:30 pm »

How would this work with a 1080P LCD TV?? would i still get res below 480p?? Also has anyone complied the latest version, im crap at compling??

bitbytebit · « **Reply #82 on:** May 07, 2011, 06:16:47 pm »

Quote from: lettuce on May 07, 2011, 05:57:30 pm

How would this work with a 1080P LCD TV?? would i still get res below 480p?? Also has anyone complied the latest version, im crap at compling??

There are precompiled builds available, so ypu won't need to patch/compile it. Also if you are able to use git then can check out the source code already patched too.

With a 1080p Tv ( which I do test on sometimes) it has less of an advantage. You can get some though by having it choose the best one and somewhat making the best option decisions. Possibly with a better custom mode table setup for 16:9 it could be even more of an advantage. I haven't explored that as much, but it all should be possible.

krick · « **Reply #83 on:** May 07, 2011, 11:20:51 pm »

Is there any way that I can force GroovyMAME to choose 720x480 interlaced instead of 640x480 interlaced? The reason is that on my monitor, 720x480 looks pretty damn good. I tried running Asteroids from the command line with -resolution 720x480 and it looks awesome after a few tweaks to my vector settings in the ini. Running Asteroids at 640x480 interlaced, which is what GroovyMAME chooses by default, is seizure inducing. 800x600 interlaced is even worse.

If the only way to accomplish this is by using game specific ini files, I'm ok with that, however I haven't been able to figure out exactly how to get that to work properly. Either I'm not doing something correctly, or GroovyMAME is ignoring my ini file resolution setting.

Totally unrelated to the above question.... This isn't a problem, just an observation. I've noticed if I switch away (alt-tab) from GroovyMAME and it gets minimized, it runs at like 1000%. I can still hear the audio screaming along. I assume this has something to do with it syncing the game speed to the video. Minimized = no video, so it runs as fast as possible. I'm curious why other (non-MAME) full-screen games don't do this when you minimize them.

lettuce · « **Reply #84 on:** May 08, 2011, 06:57:24 am »

Ok thanks, i noticed there are 3 different downloads of the latest complied version ending in, M, N , O whats the difference between these 3? I take it i need to download the offical 0142.012 version of mame and just replace the exe file with the GroovyMame exe file?

Quote from: bitbytebit on May 07, 2011, 06:16:47 pm

Quote from: lettuce on May 07, 2011, 05:57:30 pm
How would this work with a 1080P LCD TV?? would i still get res below 480p?? Also has anyone complied the latest version, im crap at compling??

There are precompiled builds available, so ypu won't need to patch/compile it. Also if you are able to use git then can check out the source code already patched too.

With a 1080p Tv ( which I do test on sometimes) it has less of an advantage. You can get some though by having it choose the best one and somewhat making the best option decisions. Possibly with a better custom mode table setup for 16:9 it could be even more of an advantage. I haven't explored that as much, but it all should be possible.

Calamity · « **Reply #85 on:** May 08, 2011, 11:31:29 am »

Quote from: krick on May 07, 2011, 11:20:51 pm

Is there any way that I can force GroovyMAME to choose 720x480 interlaced instead of 640x480 interlaced? The reason is that on my monitor, 720x480 looks pretty damn good. I tried running Asteroids from the command line with -resolution 720x480 and it looks awesome after a few tweaks to my vector settings in the ini. Running Asteroids at 640x480 interlaced, which is what GroovyMAME chooses by default, is seizure inducing. 800x600 interlaced is even worse.

If the only way to accomplish this is by using game specific ini files, I'm ok with that, however I haven't been able to figure out exactly how to get that to work properly. Either I'm not doing something correctly, or GroovyMAME is ignoring my ini file resolution setting.

Hi krick,

In order to force GroovyMame to use a specific resolution, use the -resolution param in combination with -nomodeline param. That will disable the internal modeline generator and use the resolution you ask for without recalculating it.

Quote from: krick on May 07, 2011, 11:20:51 pm

Totally unrelated to the above question.... This isn't a problem, just an observation. I've noticed if I switch away (alt-tab) from GroovyMAME and it gets minimized, it runs at like 1000%. I can still hear the audio screaming along. I assume this has something to do with it syncing the game speed to the video. Minimized = no video, so it runs as fast as possible. I'm curious why other (non-MAME) full-screen games don't do this when you minimize them.

Yes that's true. This is a side effect as we disable the throttling mechanism and just sync to the videocard refresh, so if minimized we can't access the sync information and just run full speed.

That could be fixed by patching Mame so that if forces throttle when minimized, but it would involve bringing some osd stuff to the emu part.

bitbytebit · « **Reply #86 on:** May 08, 2011, 12:24:18 pm »

They are older ones, you will want the latest which is currently 012o or the o version. Basically any time you see an updated higher letter version it'll be better and fix bugs, o works well and I haven't had to make any fixed updates lately. Just use groovymame in
place of mame, for lcd tv viewing you may need to also enable hwstretch in the main ini file, might try d3d mode, see what works best. On an lcd it's quite different than an arcade monitor so those options might be better depending on your personal preferences.

Quote from: lettuce on May 08, 2011, 06:57:24 am

Ok thanks, i noticed there are 3 different downloads of the latest complied version ending in, M, N , O whats the difference between these 3? I take it i need to download the offical 0142.012 version of mame and just replace the exe file with the GroovyMame exe file?

Quote from: bitbytebit on May 07, 2011, 06:16:47 pm
Quote from: lettuce on May 07, 2011, 05:57:30 pm
How would this work with a 1080P LCD TV?? would i still get res below 480p?? Also has anyone complied the latest version, im crap at compling??

There are precompiled builds available, so ypu won't need to patch/compile it. Also if you are able to use git then can check out the source code already patched too.

With a 1080p Tv ( which I do test on sometimes) it has less of an advantage. You can get some though by having it choose the best one and somewhat making the best option decisions. Possibly with a better custom mode table setup for 16:9 it could be even more of an advantage. I haven't explored that as much, but it all should be possible.

zorrobandito · « **Reply #87 on:** May 08, 2011, 06:55:57 pm »

Quote from: Calamity on May 06, 2011, 04:28:29 pm

Hi zorrobandito,

Probably the last driver installation messed with the previous one. Try cleaning any ATI software using CatUninstaller.

I didn't use CatUninstaller (couldn't find a valid exe) but did remove both the drivers for the card(s) and the Catalyst Control Panel and that seemed to take it back to the hardware. I then installed your drivers without a problem.

Quote from: Calamity on May 06, 2011, 04:28:29 pm

Also that blue screen you had before should not happen unless there's some previous problem. Which version were you using 6.5/9.3 XP32/64? When did you download them? (try getting the newer ones)
Which AVGA model?

I used 6.5 XP32. I'm not sure of my AVGA model but it's > 5 years old so I'm guessing it's an old version

Quote from: Calamity on May 06, 2011, 04:28:29 pm

If you go back to the hacked drivers, see how many custom modes Arcade_OSD shows (it's the number showed between () ). If it's below 100 (60 probably) that means the hacked drivers are not the ones running, even if you have 15Khz output it's actually default Windows drivers the ones that take control, that would explain why upper resolutions make the system crash. That usually happens with XP distributions that ship their own MS drivers and for some reason the system refuses to accept our drivers taking its own decisions without informing us. In those cases you have to manually uninstall that default driver, from Device Manager/Display Adapters/Properties. You'll know your system is more likely to be receptive to our drivers if after rebooting it's unable to get a compatible device driver for your card.

Well spotted, absolutely correct. I had only 59 modes available. I now have hundreds.

Quote from: Calamity on May 06, 2011, 04:28:29 pm

That said, you actually NEED to use ddraw without hwstretch to benefit from hacked drivers + GroovyMame. It's GroovyMame the one that will use the right options for you, even hwstretch when there's the need for it. Our new -syncrefresh and -triplebuffer options are only implemented for DirectDraw. Create a new mame.ini with GroovyMame and only edit it with your roms path and your monitor type.

Let us know your progress.

After heaving a huge sigh of relief at restoring my system to a functional state, I went tinkering with Groovymame. I had implemented some hacks to get Rolling Thunder and Shinobi to stop tearing but I hadn't realised how awful they made the game look until I ran the Groovymame version! Wow! I did run Space Invaders as my first test and got a rolling but sharp picture.

Because I'm running MAMEWah, it's a relatively simple matter for me to run different flavours of MAME for different games, so I've run through some of the resolution / frequency combos and directed them to groovymame and it's working great so far (another piece of arcade machine mastery that no-one will ever notice ;-).

However, could someone run through the tearing root cause again? It's when the native frequency of the game is higher than the native frequency of the arcade screen? How does one know what the native frequency of one's screen is?

e.g. rthunder runs 288x224 at 60.606060hz so this suggests that my screen is <60.606060 but does the resolution make a difference and is it just the difference between them? i.e. that 58hz could be just as bad to a native 59hz monitor.

krick · « **Reply #88 on:** May 09, 2011, 01:33:11 am »

Quote from: zorrobandito on May 08, 2011, 06:55:57 pm

I didn't use CatUninstaller (couldn't find a valid exe)

You can find it linked directly from the ArcadeVGA installation page on the Ultimarc site...

http://www.ultimarc.com/cat-uninstaller.exe

Quote from: zorrobandito on May 08, 2011, 06:55:57 pm

After heaving a huge sigh of relief at restoring my system to a functional state, I went tinkering with Groovymame. I had implemented some hacks to get Rolling Thunder and Shinobi to stop tearing but I hadn't realised how awful they made the game look until I ran the Groovymame version! Wow! I did run Space Invaders as my first test and got a rolling but sharp picture.

Because I'm running MAMEWah, it's a relatively simple matter for me to run different flavours of MAME for different games, so I've run through some of the resolution / frequency combos and directed them to groovymame and it's working great so far (another piece of arcade machine mastery that no-one will ever notice ;-).

GroovyMAME is a godsend. The only games I've had any issues with are those few freaky vertical games where the resolution is over 288. Even games that are notoriously hard to get running properly like Pacman and the Mortal Kombat series look fantastic. I don't see the need to run different versions of MAME. Have you found any specific games that don't work well on GroovyMAME?

If you encounter sound stuttering issues, be sure to give the soundsync option a try in your mame.ini or in game specific ini files if you prefer to only turn it on as-needed.

A rolling picture generally means that you need to tweak your monitor. I had to adjust the vertical hold (or whatever it was called) pot until I was able to find a sweet spot where none of the resolutions cause rolling.

If you end up sticking with GroovyMAME, be sure to make a donation to encourage them to keep up the hard work.

I used to use MAMEWah with my old setup, but I'm giving Hyperspin a try. So far, I'm REALLY impressed. I'm looking forward to setting up other emulators eventually and Hyperspin supports most of the popular ones right out of the box.

lettuce · « **Reply #89 on:** May 09, 2011, 02:38:57 pm »

Ok i have downloaded, groovymame32_0142.012o.exe from http://mame.groovy.org/0142/. When i run the exe file i get the following message:

SwitchRes: Failed opening

Systemzcurrentcontrolset\control\video\DEB blah blah balh\000 registry entry with error 5

an ideas?

bitbytebit · « **Reply #90 on:** May 09, 2011, 04:28:59 pm »

Quote from: lettuce on May 09, 2011, 02:38:57 pm

Ok i have downloaded, groovymame32_0142.012o.exe from http://mame.groovy.org/0142/. When i run the exe file i get the following message:

SwitchRes: Failed opening

Systemzcurrentcontrolset\control\video\DEB blah blah balh\000 registry entry with error 5

an ideas?

What's the video card your using? That means the ATI registry entry isn't there, which would point to no ATI card/drivers existing on the system. It actually isn't a bad error if you don't expect to use custom resolutions, it's just a warning and could still use the system resolutions. What OS are you using, XP or other Windows version? Also possibly getting the log output and posting it here with the command line additional switches of '-verbose -md 4' might be interesting. Is it working though, even with that message, are you running the game at the mame command line? (the built in OSD with mame isn't really well tested with this, although I *think* it might sort of work, but not recommended to be used since resolution switching is harder to do through it).

lettuce · « **Reply #91 on:** May 09, 2011, 06:13:43 pm »

Im using a ATI 6970 card, on win 7. So the exe file is command prompt, and not win32? When running the program for the first time should it generate a mame.ini file. Or should get all the files and folders from mame32 install for example?

bitbytebit · « **Reply #92 on:** May 09, 2011, 06:26:17 pm »

Quote from: lettuce on May 09, 2011, 06:13:43 pm

Im using a ATI 6970 card, on win 7. So the exe file is command prompt, and not win32? When running the program for the first time should it generate a mame.ini file. Or should get all the files and folders from mame32 install for example?

Ah, yeah those cards aren't supported because they don't allow custom modelines for the Windows drivers. At least I'm pretty sure that's the case with anything ATI HD 5xxx or above, they unfortunately for the Windows driver locked out lower resolutions and custom ones I think, or at least lower dotclocks and horizontal frequencies. You would do the -createconfig option of mame/groovymame to create the mame.ini file, and definitely recommended to do first.

Calamity or someone else knowing more about the ATI Windows situation might be able to be more definite on that cards issues.

In Linux I haven't tested anything above the 5xxx series which do work in Linux, so it's not a hardware issue but isolated to Windows drivers. I am suspecting the 6xxx ones work there too but not sure, and the support for them has just been added more recently than the 5xxx ones so can't say how they work there either for arcade stuff.

Since your using the LCD though, probably fine actually and don't need custom resolutions and just use the system ones for now. Create the mame.ini file and then change the hwstretch and keepaspect options to be always enabled there, might want to turn on triplebuffer too, soundsync. With that card and an LCD, definitely the closest you'll get to having things look the best they can for the limitations of the LCD and that card not having drivers that play with our resolution setup. The custom resolutions would be nice to allow 16:9 resolutions to be setup, but then again those aren't fully explored and adapted for in groovymame currently anyways so there's probably no advantage right now to having that ability if using an LCD.

krick · « **Reply #93 on:** May 09, 2011, 10:41:07 pm »

Quote from: Calamity link=topic=110905.msg1183636#msg1183636

In order to force GroovyMame to use a specific resolution, use the -resolution param in combination with -nomodeline param. That will disable the internal modeline generator and use the resolution you ask for without recalculating it.

I created a file called "asteroid.ini" with the following contents...

modeline 0
resolution 720x480

...it appears to be ignored. I tried putting asteroid.ini in both the mame root directory and in the ini folder. No effect.

However the commandline works as expected...

groovymame -nomodeline -resolution 720x480 asteroid

Can someone try the ini file route and see if they can get it working on their system?

EDIT: I've attached a log file. GroovyMAME is definitely not parsing asteroid.ini for some reason

bitbytebit · « **Reply #94 on:** May 10, 2011, 05:30:24 am »

Quote from: krick on May 09, 2011, 10:41:07 pm

Quote from: Calamity link=topic=110905.msg1183636#msg1183636

In order to force GroovyMame to use a specific resolution, use the -resolution param in combination with -nomodeline param. That will disable the internal modeline generator and use the resolution you ask for without recalculating it.

I created a file called "asteroid.ini" with the following contents...

modeline 0
resolution 720x480

...it appears to be ignored. I tried putting asteroid.ini in both the mame root directory and in the ini folder. No effect.

However the commandline works as expected...

groovymame -nomodeline -resolution 720x480 asteroid

Can someone try the ini file route and see if they can get it working on their system?

EDIT: I've attached a log file. GroovyMAME is definitely not parsing asteroid.ini for some reason

Does it do this for all the games, try one that's not a vector and see. Try to put those lines in vector.ini and possibly that is the way to do it, seems to be parsing that file. I am not sure if the vector.ini file keeps mame from reading the individual vector games .ini files or not, so will be interesting if it's ignoring all games for you or just vector ones. Also may want to try it with modeline still enabled too, I think it'll be fine either way, shouldn't have to turn off the modeline part at all to get the 720x480 resolution forced like that (but maybe there's another side effect, which I'd be interested in, since it'd be a bug if so).

Calamity · « **Reply #95 on:** May 10, 2011, 08:17:15 am »

Quote from: bitbytebit on May 10, 2011, 05:30:24 am

Does it do this for all the games, try one that's not a vector and see. Try to put those lines in vector.ini and possibly that is the way to do it, seems to be parsing that file. I am not sure if the vector.ini file keeps mame from reading the individual vector games .ini files or not, so will be interesting if it's ignoring all games for you or just vector ones. Also may want to try it with modeline still enabled too, I think it'll be fine either way, shouldn't have to turn off the modeline part at all to get the 720x480 resolution forced like that (but maybe there's another side effect, which I'd be interested in, since it'd be a bug if so).

Hi bitbytebit,

I recommeded turning -modeline off as it's the only way I found to bypass the modeline generator when requesting a resolution by command line. So if you set -resolution 800x600 and you happen to have your -monitor option set to cga, it will process that resolution and probably virtualize it, resulting in different one that will have preference over the one we specified. However I might be wrong, and anyway the 720x480 case should not get virtualized at all.

On the other hand, I've just received a Dell 30" 2560x1600 LCD panel, and I'm doing some tests with GroovyMame just out of curiosity. I can confirm that having the -modeline mechanism on for a LCD screen does not make any sense, as the panel has a fixed frequency of 60 Hz. Also, the best we can do is to set the desktop resolution to the panel's native one and disable the -switchres option. So with these settings, Direct3D does a better job than DirectDraw, and actually is what Mame devs are recommending, then for LCD users:

video d3d
switchres 0

Disabling switchres actually overrides the -modeline option, however -waitvsync decisions are still made (from the calculated modeline, so possibly wrong). So you may need to manually enable -syncrefresh or -triplebuffer depending on your taste.

Calamity · « **Reply #96 on:** May 10, 2011, 08:22:43 am »

Quote from: lettuce on May 09, 2011, 06:13:43 pm

Im using a ATI 6970 card, on win 7. So the exe file is command prompt, and not win32? When running the program for the first time should it generate a mame.ini file. Or should get all the files and folders from mame32 install for example?

Yes, Win 7 is not currently supported, so that's probably the problem, combined with the HD 6970 card. Try using the settings for LCDs from my previous post, it should work fine that way.

jtslade · « **Reply #97 on:** May 10, 2011, 10:25:54 am »

I'm going to give this a shot.

AMD DualCore 4850e
Running XP sp3 32bit OS
Hyperspin FE
Groovy Mame 32bit version O

ATi HD2600 PCI-E video card inside

Connected Via-S-Video to a Hitachi PAL/NTSC multisystem 25" TV

When I run in default options from a fresh -cc (builds my ini file)

I get no screen tearing, smaller screen (some black boarders, about 1.5" all the way around)

But the lag and sound stutter is pretty bad.

Maybe I should update to the special catalyst 9.5 drivers from the Groovy Site / or reinstall DirectX ?

I have been trying to get rid of the awful screen tearing for a very, very long time......

Calamity · « **Reply #98 on:** May 10, 2011, 11:09:06 am »

Quote from: jtslade on May 10, 2011, 10:25:54 am

Connected Via-S-Video to a Hitachi PAL/NTSC multisystem 25" TV

That's the issue, you should be using the RGB input in case your TV has one, S-Video signal is reprocessed by your video card to that standard so we loose our advanced video setup in the way. Does your TV has a SCART?

krick · « **Reply #99 on:** May 10, 2011, 11:10:42 am »

Quote from: bitbytebit on May 10, 2011, 05:30:24 am

Does it do this for all the games, try one that's not a vector and see. Try to put those lines in vector.ini and possibly that is the way to do it, seems to be parsing that file. I am not sure if the vector.ini file keeps mame from reading the individual vector games .ini files or not, so will be interesting if it's ignoring all games for you or just vector ones.

According to the latest mame documentation, it should read the gamename.ini after the vector.ini. However, there might be a problem in baseline MAME, so I'm going to do some tests tonight.

http://mamedev.org/source/docs/config.txt.html

Quote

Configuration options
---------------------

-[no]readconfig / -[no]rc

   Enables or disables the reading of the config files. When enabled
   (which is the default), MAME reads the following config files in order:

   - mame.ini
   - <mymame>.ini (i.e. if MAME was renamed mame060.exe, MAME
   parses mame060.ini here)
   - debug.ini (if the debugger is enabled)
   - vector.ini (for vector games only)
   - <driver>.ini (based on the source filename of the driver)
   - <parent>.ini (for clones only, may be called recursively)
   - <gamename>.ini

   The settings in the later ini's override those in the earlier ini's.
   So, for example, if you wanted to disable overlay effects in the
   vector games, you can create a vector.ini with the "effect none" line
   in it, and it will override whatever effect value you have in your
   mame.ini. The default is ON (-readconfig).

bitbytebit · « **Reply #100 on:** May 10, 2011, 11:31:18 am »

Quote from: Calamity on May 10, 2011, 08:17:15 am

Quote from: bitbytebit on May 10, 2011, 05:30:24 am
Does it do this for all the games, try one that's not a vector and see. Try to put those lines in vector.ini and possibly that is the way to do it, seems to be parsing that file. I am not sure if the vector.ini file keeps mame from reading the individual vector games .ini files or not, so will be interesting if it's ignoring all games for you or just vector ones. Also may want to try it with modeline still enabled too, I think it'll be fine either way, shouldn't have to turn off the modeline part at all to get the 720x480 resolution forced like that (but maybe there's another side effect, which I'd be interested in, since it'd be a bug if so).

Hi bitbytebit,

I recommeded turning -modeline off as it's the only way I found to bypass the modeline generator when requesting a resolution by command line. So if you set -resolution 800x600 and you happen to have your -monitor option set to cga, it will process that resolution and probably virtualize it, resulting in different one that will have preference over the one we specified. However I might be wrong, and anyway the 720x480 case should not get virtualized at all.

On the other hand, I've just received a Dell 30" 2560x1600 LCD pannel, and I'm doing some tests with GroovyMame just out of curiosity. I can confirm that having the -modeline mechanism on for a LCD screen does not make any sense, as the pannel has a fixed frequency of 60 Hz. Also, the best we can do is to set the desktop resolution to the pannel's native one and disable the -switchres option. So with these settings, Direct3D does a better job than DirectDraw, and actually is what Mame devs are recommending, then for LCD users:

video d3d
switchres 0

Disabling switchres actually overrides the -modeline option, however -waitvsync decisions are still made (from the calculated modeline, so possibly wrong). So you may need to manually enable -syncrefresh or -triplebuffer depending on your taste.

That makes sense, yeah possibly adding a monitor option of 'lcd' I guess could be done and then basically avoid the modeline stuff and just redo the settings into the default mame ones again with the cabmame hacks enabled properly for that. Seems like that would be a way to make it easy for LCD users to get the benefits they need but avoid the extra stuff that is meant for arcade/CRT monitors only.

Calamity · « **Reply #101 on:** May 10, 2011, 11:54:35 am »

Quote from: zorrobandito on May 08, 2011, 06:55:57 pm

However, could someone run through the tearing root cause again? It's when the native frequency of the game is higher than the native frequency of the arcade screen? How does one know what the native frequency of one's screen is?

e.g. rthunder runs 288x224 at 60.606060hz so this suggests that my screen is <60.606060 but does the resolution make a difference and is it just the difference between them? i.e. that 58hz could be just as bad to a native 59hz monitor.

The "native frequency" of a given screen concept only makes full sense when you talk about LCDs that refresh their panels at a fixed 60 Hz frequency (whatever the signal's frequency they can admit).

So for CRTs (that is our main target), the screen doesn't have a native frequency, it's the signal our video card produces the one which has a given frequency. Most arcade monitors have actually a range of frequencies they can sync at, as wide as 1 KHz (horizontal) and 10 Hz (vertical). However, some older CRT TVs may have very narrow ranges around their standard frequency where they can actually sync, so if they're made for the PAL area they may only sync around 50 Hz. Think of it as if it was a transistor radio, you can "sync" to any radio station which frequency is inside the band your device supports (well it's not exactly that but hey)

That said, tearing happens whenever you write to your video card memory out of the vblank period. The vblank is a brief gap of time before each frame is drawn.

So even if you were able to program your video card to refresh the screen at exact 60 Hz, and your cpu (mame) to throw frames at exact 60 Hz, you would have tearing *unless* you manage to make the blitting coincide with the vblank gaps between each frame.

In the real world, things are even more difficult, because you *can't* make your video card work at exact 60 Hz: it will run at 60.013 or something around.

So tearing should happen *always*, unless you use some sort of vertical synchronization. What we do is to wait for the exact moment where the vblank gap happens, and right then we fed our video card with the new frame. In GroovyMame, there are two implementations of this, that are somewhat different to the mainstream Mame ones (at least for ddraw):

- syncrefresh: synchronous vblank wait, videocard clock rules emulation speed (the game may run quicker/slower depending on the video mode)
- triplebuffer: asynchronous vblank wait, cpu clock rules emulation speed (the game may have scroll stuttering depending on the video mode)

Calamity · « **Reply #102 on:** May 10, 2011, 12:13:23 pm »

Quote from: bitbytebit on May 10, 2011, 11:31:18 am

That makes sense, yeah possibly adding a monitor option of 'lcd' I guess could be done and then basically avoid the modeline stuff and just redo the settings into the default mame ones again with the cabmame hacks enabled properly for that. Seems like that would be a way to make it easy for LCD users to get the benefits they need but avoid the extra stuff that is meant for arcade/CRT monitors only.

Yes that would be very handy.

I'm also seeing the last triplebuffer patch is not so great when working with LCDs or when the target frequency is very different from the original on CRTs. So although it fixes previous problems and input lag, it's causing some visual artifacts as if a group of lines was missing randomly in some frames, it's rather fuzzy and driving me nuts actually, have tried many different approaches to get rid of it but no luck. On the other hand, it does not happen with d3d implementation of triplebuffer, I still need to confirm it, but the problem might come from the very DirectX stuff and old DirectDraw features not being fully supported since long. So although this is not a problem for LCDs as long as we set d3d for them, I'd like to repair it at least for CRTs, so that we can keep them using ddraw by now, but (I hate to say this) I'm considering in the future it would be a good idea to extend our patches to the d3d side...

krick · « **Reply #103 on:** May 10, 2011, 12:18:17 pm »

Quote from: bitbytebit on May 10, 2011, 11:31:18 am

That makes sense, yeah possibly adding a monitor option of 'lcd' I guess could be done and then basically avoid the modeline stuff and just redo the settings into the default mame ones again with the cabmame hacks enabled properly for that. Seems like that would be a way to make it easy for LCD users to get the benefits they need but avoid the extra stuff that is meant for arcade/CRT monitors only.

I think this would make a LOT of LCD users very happy.

I believe that most MAME users are overwhelmed with all the options in the INI file. It would be cool if it could be boiled down to a set of easy choices based on the target output device that will work for the majority of games. Then users can implement game-specific adjustments in other ini files as needed.

I'm not sure what are the most common choices, here's the ones I can think of off the top of my head. You guys would know better than me...

1) 15KHz ArcadeMonitor + "normal" ATI card + tweaked ATI drivers
2) tri-sync ArcadeMonitor + "normal" ATI card+ tweaked ATI drivers
3) 15KHz ArcadeMonitor + ArcadeVGA 2 + tweaked ATI drivers
4) tri-sync ArcadeMonitor + ArcadeVGA 2 + tweaked ATI drivers
5) 15KHz ArcadeMonitor + ArcadeVGA 3000 + Ultimarc drivers
6) tri-sync ArcadeMonitor + ArcadeVGA 3000 + Ultimarc drivers
7) LCD
8) PC Monitor
9) NTSC television (S-Video out)

There may be the need to distinguish between vertically and horizontally oriented monitors to get optimal default settings.

bitbytebit · « **Reply #104 on:** May 10, 2011, 01:57:57 pm »

Quote from: krick on May 10, 2011, 12:18:17 pm

Quote from: bitbytebit on May 10, 2011, 11:31:18 am

That makes sense, yeah possibly adding a monitor option of 'lcd' I guess could be done and then basically avoid the modeline stuff and just redo the settings into the default mame ones again with the cabmame hacks enabled properly for that. Seems like that would be a way to make it easy for LCD users to get the benefits they need but avoid the extra stuff that is meant for arcade/CRT monitors only.

I think this would make a LOT of LCD users very happy.

I believe that most MAME users are overwhelmed with all the options in the INI file. It would be cool if it could be boiled down to a set of easy choices based on the target output device that will work for the majority of games. Then users can implement game-specific adjustments in other ini files as needed.

I'm not sure what are the most common choices, here's the ones I can think of off the top of my head. You guys would know better than me...

1) 15KHz ArcadeMonitor + "normal" ATI card + tweaked ATI drivers
2) tri-sync ArcadeMonitor + "normal" ATI card+ tweaked ATI drivers
3) 15KHz ArcadeMonitor + ArcadeVGA 2 + tweaked ATI drivers
4) tri-sync ArcadeMonitor + ArcadeVGA 2 + tweaked ATI drivers
5) 15KHz ArcadeMonitor + ArcadeVGA 3000 + Ultimarc drivers
6) tri-sync ArcadeMonitor + ArcadeVGA 3000 + Ultimarc drivers
7) LCD
PC Monitor
9) NTSC television (S-Video out)

There may be the need to distinguish between vertically and horizontally oriented monitors to get optimal default settings.

Yeah the LCD monitor type fits in there and will be nice, for the most part the other combinations are supported through the svga/vga/multi/ntsc/pal monitor settings. For the avga cards, possibly an -monitor_avga option I guess or even a monitor type of 'auto' or 'system' or 'other' or 'none' that would essentially use the system modelines only and that would fit both an avga or other video card type besides ATI cards. It's weird because that gets into card types, and it's the 'monitor' type option, so it's one point that might become confusing or non-intuitive if not somehow split into new options. I sort of want to rename the options to be more intuitive and get away from having -monitor_ as a prefix for every option, seems like that would lead to being easier to add in a card type option possibly (and in turn could know the low dotclock issue cards and avga card unique needs).

There's actually some amazingly intelligent monitor orientation settings for groovymame, it can be set to do everything on a vertical horizontal or rotating monitor, and make all the right decisions. One of the features only a few have needed so far, but they are there and from switchres originally. I've wanted to play with those more myself someday when I get this tabletop built around my old 15khz wg7200 I have sitting around, and test the rotating monitor setup or tabletop with side control panel. From my tests though the orientation settings are quite good at doing the right thing every time, even horizontal games on a vertical monitor at least look correctly positioned. Now when we talk about Windows vs. Linux though for that, in Windows there would be a full custom modeline table with all the odd resolutions necessary to support this kind of setup since the standard resolutions wouldn't be as common for horizontal games on a vertical monitor.

Hopefully this weekend I'll have some time to add an lcd monitor type and avga one, which basically the avga one would just bypass the need to mode calculate and just focus on system resolutions. At least be cleaner in setup, and possibly change some of the settings defaults I guess although not sure if that's necessary or not.

krick · « **Reply #105 on:** May 11, 2011, 12:44:55 am »

Never mind my ranting about ini file parsing. It must have been user error on my part because it's working now.

jtslade · « **Reply #106 on:** May 11, 2011, 02:05:06 am »

I wish the tv had Scart! If only....
Maybe I can find a 25 inch tv with scart here I'm Germany, I look on eBay and other used for sale sites but finding one has been tough. What's even more difficult is the fact that all Pal TV's are 220v and I built my cab as 110v and run it on a transformer.

I am coming to the conclusion that a CRT Arcade 25" monitor tri-sync is the best option..

jtslade · « **Reply #107 on:** May 11, 2011, 06:12:26 am »

So I installed the special 9.3 catalyst ATI drivers from the Groovy site..
Updated/Reinstalled DirectX redist package...

Then started to mess with my Mame.ini file in the groovy mame directory..

AND I HAVE NO FRAME TEARING ANY MORE AT ALL!!!

THE SOUND IS PERFECT, with no skipping at ALL!

With the frameskip set to 2 my game speed will flip from 95% to 103% every half second like clockwork, back and forth, back and forth.

Vertical games like pacman look great, silk movement from characters.

Horizontal Sidescrollers like TMNT are so much better now, just unbelievable.

I will continue to work on it, but my rom set and CHD's now need to be updated so I'll start on that.

But a huge thank you to The Groovy Mame Team! WOW!

I don't want to jinx it, but this has been an ongoing problem for years. Of course in the future i'll get a CRT arcade monitor or PAL TV with SCART, but for now, its pretty freakin awesome!

I now have a very strange config (My INI file is below) Pretty much doing everything your not supposed to do like

monitor set to CGA (see my earlier post as I have a Svideo to a multi-system PAL/NTSC TV w/o SCART)

Using frameskip (set to 2)
Priority 1
Video on Ddraw (which used to look bad so I always went with D3D)
Hardware stretching enabled (always was considered a no-no)
Cleanstretch on
VSync on
Tripple Buffer off
Soundsync on
Changeres off
Switchres off
Prescale 2
refreshspeed 1

<UNADORNED0>

#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0

#
# CORE SEARCH PATH OPTIONS
#
rompath F:\Emulators\Mame\roms;E:\Arcade.SATA\chds
hashpath hash
samplepath samples
artpath artwork
ctrlrpath ctrlr
inipath .;ini
fontpath .
cheatpath cheat
crosshairpath crosshair

#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory cfg
nvram_directory nvram
memcard_directory memcard
input_directory inp
state_directory sta
snapshot_directory snap
diff_directory diff
comment_directory comments

#
# CORE OUTPUT DIRECTORY OPTIONS
#
hiscore_directory hi

#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
playback
record
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview internal
burnin 0

#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 2
seconds_to_run 0
throttle 0
sleep 1
speed 1.0
refreshspeed 1

#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0

#
# CORE ARTWORK OPTIONS
#
artwork_crop 0
use_backdrops 0
use_overlays 0
use_bezels 0

#
# CORE SCREEN OPTIONS
#
brightness 1.0
contrast 1.0
gamma 1.0
pause_brightness 0.65
effect none

#
# CORE VECTOR OPTIONS
#
antialias 1
beam 1.0
flicker 0

#
# CORE SOUND OPTIONS
#
sound 1
samplerate 48000
samples 1
volume 0

#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 0
joystick 1
lightgun 0
multikeyboard 0
multimouse 0
steadykey 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.3
joystick_saturation 0.85
natural 0

#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device keyboard
adstick_device keyboard
pedal_device keyboard
dial_device keyboard
trackball_device keyboard
lightgun_device keyboard
positional_device keyboard
mouse_device mouse

#
# CORE DEBUGGING OPTIONS
#
log 0
verbose 0
update_in_pause 0
debug 0
debugscript
debug_internal 0

#
# CORE MISC OPTIONS
#
bios
cheat 0
skip_gameinfo 0
uifont default
ramsize

#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch 0
disable_nagscreen_patch 0
disable_loading_patch 0

#
# CORE SWITCHRES OPTIONS
#
modeline 1
monitor cga
monitor_connector auto
monitor_orientation horizontal
monitor_aspect 4:3
monitor_debug 0
monitor_doublescan 1
monitor_dotclock 0
monitor_ymin 0
soundsync 1
cleanstretch 1
changeres 0
redraw 0
monitor_specs0 auto
monitor_specs1 auto
monitor_specs2 auto
monitor_specs3 auto
monitor_specs4 auto
monitor_specs5 auto
monitor_specs6 auto
monitor_specs7 auto

#
# WINDOWS DEBUGGING OPTIONS
#
oslog 0
watchdog 0
debugger_font "Lucida Console"
debugger_font_size 9

#
# WINDOWS PERFORMANCE OPTIONS
#
priority 1
multithreading 1
numprocessors auto
profile 0
bench 0

#
# WINDOWS VIDEO OPTIONS
#
video ddraw
numscreens 1
window 0
maximize 1
keepaspect 0
prescale 2
waitvsync 1
syncrefresh 1
menu 0

#
# DIRECTDRAW-SPECIFIC OPTIONS
#
hwstretch 1

#
# DIRECT3D-SPECIFIC OPTIONS
#
d3dversion 9
filter 0

#
# PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect auto
resolution auto
view auto
screen0 auto
aspect0 auto
resolution0 auto
view0 auto
screen1 auto
aspect1 auto
resolution1 auto
view1 auto
screen2 auto
aspect2 auto
resolution2 auto
view2 auto
screen3 auto
aspect3 auto
resolution3 auto
view3 auto

#
# FULL SCREEN OPTIONS
#
triplebuffer 0
switchres 0
full_screen_brightness 1.1
full_screen_contrast 1.0
full_screen_gamma 1.1

#
# WINDOWS SOUND OPTIONS
#
audio_latency 2

#
# INPUT DEVICE OPTIONS
#
dual_lightgun 0

zorrobandito · « **Reply #108 on:** May 11, 2011, 09:57:58 am »

Quote from: Calamity on May 10, 2011, 11:54:35 am

Quote from: zorrobandito on May 08, 2011, 06:55:57 pm
However, could someone run through the tearing root cause again? It's when the native frequency of the game is higher than the native frequency of the arcade screen? How does one know what the native frequency of one's screen is?

e.g. rthunder runs 288x224 at 60.606060hz so this suggests that my screen is <60.606060 but does the resolution make a difference and is it just the difference between them? i.e. that 58hz could be just as bad to a native 59hz monitor.

So tearing should happen *always*, unless you use some sort of vertical synchronization. What we do is to wait for the exact moment where the vblank gap happens, and right then we fed our video card with the new frame. In GroovyMame, there are two implementations of this, that are somewhat different to the mainstream Mame ones (at least for ddraw):

- syncrefresh: synchronous vblank wait, videocard clock rules emulation speed (the game may run quicker/slower depending on the video mode)
- triplebuffer: asynchronous vblank wait, cpu clock rules emulation speed (the game may have scroll stuttering depending on the video mode)

Thanks for the explanation. I'm now clear on how you get around it but not clear in which games I should be looking for it. I'm still reluctant to upgrade my setup to run groovymame by default, primarily because of the romset hassle. My heavily-trimmed set is from 0.99, and just testing groovymame, I've found a 30-50% ration of games that need new versions.

Maybe I can be convinced if I can understand the potential pitfalls of running groovymame? I tried it with vector games and with significant tweaking they look fantastic too! Maybe 'modern' vertical shooters on a horizontal screen? e.g. 19xx? I'll have to give that a try... Do you have any examples of games that might have the scroll stuttering or running quicker / slower?

lettuce · « **Reply #109 on:** May 11, 2011, 02:04:25 pm »

Ok, im about to install groovymame on to my cab, i curretly have a ati 4650 card with soft15khz installed, should i have soft15khz installed if im using the crt_emudriver_9.3_1.2_xp32_multisync.rar driver??

Calamity · « **Reply #110 on:** May 11, 2011, 02:15:44 pm »

Quote from: lettuce on May 11, 2011, 02:04:25 pm

Ok, im about to install groovymame on to my cab, i curretly have a ati 4650 card with soft15khz installed, should i have soft15khz installed if im using the crt_emudriver_9.3_1.2_xp32_multisync.rar driver??

NO. Run VMMaker and restart your system to restore the needed modelines.

EDIT: Oh wait! You were the one with the LCD, you'd better install regular ATI drivers and no soft15khz at all, unless you're going to use a CRT.

lettuce · « **Reply #111 on:** May 11, 2011, 02:49:23 pm »

Quote from: Calamity on May 11, 2011, 02:15:44 pm

Quote from: lettuce on May 11, 2011, 02:04:25 pm
Ok, im about to install groovymame on to my cab, i curretly have a ati 4650 card with soft15khz installed, should i have soft15khz installed if im using the crt_emudriver_9.3_1.2_xp32_multisync.rar driver??

NO. Run VMMaker and restart your system to restore the needed modelines.

EDIT: Oh wait! You were the one with the LCD, you'd better install regular ATI drivers and no soft15khz at all, unless you're going to use a CRT.

To confuse matters even more i also have a cab with a tri-sync monitor in lol. That whats im using at the moment, i uninstalled soft-15khz from my system and the ATI drivers, i then restarted the system and installed the drivers in the download folder from groovymame site. But have noticed that when i run grooymame and select a rom the monitor doesnt change screen res it just says at the windows res any ideas why the screen res doesnt change?

Calamity · « **Reply #112 on:** May 11, 2011, 03:01:08 pm »

Quote from: zorrobandito on May 11, 2011, 09:57:58 am

Maybe I can be convinced if I can understand the potential pitfalls of running groovymame? I tried it with vector games and with significant tweaking they look fantastic too! Maybe 'modern' vertical shooters on a horizontal screen? e.g. 19xx? I'll have to give that a try... Do you have any examples of games that might have the scroll stuttering or running quicker / slower?

Well, as we said before that strongly depends on your monitor

So for instance, if you're the lucky owner of a WG D9800, you'll virtually be able to have any single game perfectly synced at its native speed. This is not fully true as we are not usually able to get a 100% match of the original Hz with our modeline, we will always be some hundredths of Hz above or below, but that's not a problem cause GroovyMame will internally adjust the game speed to that so we won't notice, so for this reason GroovyMame is not the best Mame to look for tearing as it will hide it from us in most situations if our system is properly set up (right modelines installed).

However the problem appears if your monitor is not capable of covering the whole range of Hfreq and Vfreq that different Mame games require, actually what matters is the -monitor option you use in GroovyMame. Probably the easiest way to test this is to force Mame to only use PAL modes, that are restricted to 50Hz. As 50Hz is too far from 60Hz, GroovyMame won't try to sync and will let the game run at it's original speed (throttle).

- So use -monitor pal and the run a 60Hz game like wonderboy, you'll instantly notice the tearing.
- Now use the same settings but now add the -syncrefresh option: the speed should go down to 83%, scrool will be smooth, sound will stutter.
- Now add -soundsync option: you should have 83% speed, smooth scroll, smooth sound but lowered pitch.
- Now remove -syncrefresh and -soundsync and add -triplebuffer: speed will be 100%, sound will be perfect, scroll will stutter.

So this was a forced case but hopefully will help to explain other situations. Usually a standard arcade monitor will have a wider Vfreq range than the PAL standard so we should be able to sync to everything between 50-60Hz. The problem arises with vertical games rotated, that produce a resolution with too many lines: usually above 240 lines we won't be able to get a 60Hz modeline because our Hfreq would exceed the our monitor's limits. So in order to make an usuable modeline we have to lower its Vfreq to 58, 55, 50, etc. Hz. That's how we naturally get to the same situation we forced above. Typical cases are: dspirit, 1942, pacman, etc. For these games, you'll have to decide either: doing nothing (tearing), enabling -syncrefresh (lowered speed), enabling -triplebuffer (scroll stutter). Of course, it depends on the game one solution is better than the other.

Finally you have some vertical games that are just too tall when rotated so they can't be fixed by just lowering its speed. In those cases we "virtualize" (stretch+interlace). The bad thing about this is that we loose sharpness and detail. The nice thing is that, opposite to the previous case, we can match any Vfreq that we want by doing this, so "virtualized" games will run at perfect 100% without any other artifact. Typical cases are: donpachi, mazinger, etc.

Calamity · « **Reply #113 on:** May 11, 2011, 03:03:27 pm »

Quote from: lettuce on May 11, 2011, 02:49:23 pm

To confuse matters even more i also have a cab with a tri-sync monitor in lol. That whats im using at the moment, i uninstalled soft-15khz from my system and the ATI drivers, i then restarted the system and installed the drivers in the download folder from groovymame site. But have noticed that when i run grooymame and select a rom the monitor doesnt change screen res it just says at the windows res any ideas why the screen res doesnt change?

Yes, you need to lauch games either from command line or using a frontend, not from the internal menu. Also, create a new mame.ini (option -cc).

lettuce · « **Reply #114 on:** May 11, 2011, 03:53:27 pm »

Quote from: Calamity on May 11, 2011, 03:03:27 pm

Quote from: lettuce on May 11, 2011, 02:49:23 pm
To confuse matters even more i also have a cab with a tri-sync monitor in lol. That whats im using at the moment, i uninstalled soft-15khz from my system and the ATI drivers, i then restarted the system and installed the drivers in the download folder from groovymame site. But have noticed that when i run grooymame and select a rom the monitor doesnt change screen res it just says at the windows res any ideas why the screen res doesnt change?

Yes, you need to lauch games either from command line or using a frontend, not from the internal menu. Also, create a new mame.ini (option -cc).

Thanks its working now. Another question is there an easy way to setup so that all 15khz games are running at double the refresh rate so 120hz, as for some reason my monitor squashes up on the far right of the screen when running 15khz games, but doesnt have this for 31khz games. I remember back last year i got Aliens running at 120hz and the screen was perfect with not squashed effect on the right hand side of the screen

krick · « **Reply #115 on:** May 12, 2011, 01:35:36 am »

Occasionally, due to my using an ArcadeVGA3000 with it's resolution limitations coupled with my 15Khz arcade monitor, there are games that will be forced to run in interlaced modes.

One such game is 19xx, which is a vertical shooter with a native resolution of 224x384.

When I run GroovyMAME, it selects 640x480 interlaced.

I've mentioned before that 640x480 looks really bad on my monitor, and that 720x480 looks great.

It seems that when I make a custom 19xx.ini to force the resolution, I need the following three entries to get something that looks comparable to the default GroovyMAME results (but without the nasty doubled flickering of 640x480)...

hwstretch 1
keepaspect 1
resolution 720x480

Note, if I don't specify both hwstretch and keepaspect, the game's proportions don't come out right.

Is this the best I can do for this game?

Are there any other switches that I should be enabling in my 19xx.ini like waitvsync?

I'm not really sure what happens automatically behind the scenes these days.

Oh, and just to be sure... If I was running an ATI HD 4550 with Calamity's custom drivers, I think I would still would have to run 19xx in an interlaced video mode. My Hantarex Polo 25 low-res arcade monitor is the limitation, not the ArcadeVGA3000. Correct?

Calamity · « **Reply #116 on:** May 12, 2011, 04:06:20 am »

Quote from: krick on May 12, 2011, 01:35:36 am

It seems that when I make a custom 19xx.ini to force the resolution, I need the following three entries to get something that looks comparable to the default GroovyMAME results (but without the nasty doubled flickering of 640x480)...

hwstretch 1
keepaspect 1
resolution 720x480

Note, if I don't specify both hwstretch and keepaspect, the game's proportions don't come out right.

Is this the best I can do for this game?

Yes, those are the exact same options GroovyMame is setting, and are probably the best thing you can do, well actually the less bad thing if you ask me (the right way would be rotating your monitor).

Quote from: krick on May 12, 2011, 01:35:36 am

Are there any other switches that I should be enabling in my 19xx.ini like waitvsync?

I'm not really sure what happens automatically behind the scenes these days.

Remind waitvsync is now managed internally by GroovyMame, so whatever you set there will be overriden. However, note that with AVGA 3000, GroovyMame has not very accurate information of what's the actual video mode vfreq, it only has the integer "label" of it, like 60, 54, etc. to make decisions on, so if you feel it's not doing choosing the best option you can manually set -syncrefresh or -triplebuffer.

Quote from: krick on May 12, 2011, 01:35:36 am

Oh, and just to be sure... If I was running an ATI HD 4550 with Calamity's custom drivers, I think I would still would have to run 19xx in an interlaced video mode. My Hantarex Polo 25 low-res arcade monitor is the limitation, not the ArcadeVGA3000. Correct?

Yes, definitely.

However, it sounds weird that 720x480 looks better than 640x480, as the relevant part here is the vertical values... I would try to tweak the native 640x480 modeline using ArcadePerfect, probably you can make it look better.

Calamity · « **Reply #117 on:** May 12, 2011, 04:09:31 am »

Quote from: lettuce on May 11, 2011, 03:53:27 pm

Thanks its working now. Another question is there an easy way to setup so that all 15khz games are running at double the refresh rate so 120hz, as for some reason my monitor squashes up on the far right of the screen when running 15khz games, but doesnt have this for 31khz games. I remember back last year i got Aliens running at 120hz and the screen was perfect with not squashed effect on the right hand side of the screen

That's strange. So was it always squashed up on the right before this? We can probably fix that with a custom monitor_specs line, that will for sure be a better solution that doubling vfreq. Take a photo of your screen if you can se we can judge.

zorrobandito · « **Reply #118 on:** May 12, 2011, 10:03:32 am »

Quote from: Calamity on May 11, 2011, 03:01:08 pm

Well, as we said before that strongly depends on your monitor

I envy you guys with a sense of monitor identity. All I know is that it is a 26" arcade CRT from an Australian Leisure Allied generic cabinet. The brand has not been established :-( On the good side, mine has worked perfectly for about 6 years - hence my 'migrating' reservation.

I'm assuming it's a CGA as per the mame.ini... (attached)

Quote from: Calamity on May 11, 2011, 03:01:08 pm

<some snip in here>
However the problem appears if your monitor is not capable of covering the whole range of Hfreq and Vfreq that different Mame games require, actually what matters is the -monitor option you use in GroovyMame.

The problem arises with vertical games rotated, that produce a resolution with too many lines: usually above 240 lines we won't be able to get a 60Hz modeline because our Hfreq would exceed the our monitor's limits. Typical cases are: dspirit, 1942, pacman, etc. For these games, you'll have to decide either: doing nothing (tearing), enabling -syncrefresh (lowered speed), enabling -triplebuffer (scroll stutter). Of course, it depends on the game one solution is better than the other.

Finally you have some vertical games that are just too tall when rotated so they can't be fixed by just lowering its speed. In those cases we "virtualize" (stretch+interlace). The bad thing about this is that we loose sharpness and detail. The nice thing is that, opposite to the previous case, we can match any Vfreq that we want by doing this, so "virtualized" games will run at perfect 100% without any other artifact. Typical cases are: donpachi, mazinger, etc.

19xx looked much the same as it did under mame0.99, a bit squashed but fairly playable. As predicted, I didn't detect any artifacts but Halley Wars (halleys) had a definite sound stutter but adding the following to halleys.ini has fixed it.

triplebuffer 0
syncrefresh 0

There might be some tearing but on a black, starry background it's difficult to see :-)

Just tried 1942 with the same settings - seems perfect. Now I'm struggling though, does this mean my default groovymame.ini should have these settings?

Also, bit strange but I can't get the paths in mame.ini to display bezels or overlays.

# CORE ARTWORK OPTIONS
#
artwork_crop 1
use_backdrops 1
use_overlays 1
use_bezels 1

and

artpath artwork

Space Invaders (invaders) should look a lot better. Is it just me?

lettuce · « **Reply #119 on:** May 12, 2011, 11:28:18 am »

Quote from: Calamity on May 12, 2011, 04:09:31 am

Quote from: lettuce on May 11, 2011, 03:53:27 pm
Thanks its working now. Another question is there an easy way to setup so that all 15khz games are running at double the refresh rate so 120hz, as for some reason my monitor squashes up on the far right of the screen when running 15khz games, but doesnt have this for 31khz games. I remember back last year i got Aliens running at 120hz and the screen was perfect with not squashed effect on the right hand side of the screen

That's strange. So was it always squashed up on the right before this? We can probably fix that with a custom monitor_specs line, that will for sure be a better solution that doubling vfreq. Take a photo of your screen if you can se we can judge.

Its a Pentranic tri sync monitor (UK company), i bought the monitor brand new and this is the test screen from SF3....

I sent the board back as i thought it was faulty, the engineer hocked it all up and couldnt see the same problem above on the right had side. The only thing i can think of was that a proper arcade board doesnt give this display anomaly hence why the engineer didnt see the problem, and for some reason a PC based GFX isnt give the montior enough hz on either the vertical or horizontal??

Heres the complete thread of my cab build with monitor problems...

http://forum.arcadecontrols.com/index.php?topic=80807.0

If you could help me sort this out it would be great, i know its not much but really annoys me and alway notice it, on a scrolling game when sprites come in from the right there really thin and the get to there normal width. Regarding the double hz, i cant remember what i did in soft-15kh to get it to double the frequency, but the picture was then perfect and looked perfect on Aliens (which is a 15khz game). I think my monitor was only rated at doing 90hz on the horizontal or vertical (i cant remember which), but i contacted Pentranic and asked if it was safe to run at the 120hz i was getting from the Aliens rom, and whilst they said it can do it they dont recommend it, so i changed it back


Main	Restorations	Software	Audio/Jukebox/MP3	Everything Else	Buy/Sell/Trade
Project Announcements	Monitor/Video	GroovyMAME	Merit/JVL Touchscreen	Meet Up	Retail Vendors
Driving & Racing	Woodworking	Software Support Forums	Consoles	Project Arcade	Reviews
Automated Projects	Artwork	Frontend Support Forums	Pinball	Forum Discussion	Old Boards
Raspberry Pi & Dev Board	controls.dat	Linux	Miscellaneous Arcade	Wiki Discussion	Old Archives
Lightguns	Arcade1Up	Try the site in https mode		Site News


Unread posts \| New Replies \| Recent posts \| Rules \| Chatroom \| Wiki \| File Repository \| RSS \| Submit news