The NEW Build Your Own Arcade Controls
Software Support => GroovyMAME => Topic started by: bitbytebit on April 07, 2011, 06:15:47 am
-
Figured I'd break out of the CabMame thread where this has been talked about and have a separate one for GroovyMame specifically, with the announcement of 0143 patches which should be ready now. Explanation of what GroovyMame is below and how in both Windows and Linux with an ATI card you can use it to do what Advance mame did, plus cabmame and possibly other features too...
GroovyMame for Arcade Monitors, with custom modeline generation and switching...
- Version 0.146u4 of MAME has been patched to use Groovymame/Cabmame patches.
Get it from GroovyArcade's site (http://code.google.com/p/groovyarcade/downloads/list)
- GroovyMAME features:
* Generate custom modelines and use them as game calls for them
* In Windows with ATI cards we can alter the refresh rate of existing modelines for game requirements
* Resolution change capability with modeline switching in Windows and Linux, PSX games and others
* Multithreaded mode and waitvsync work together in Windows without throttle
* MKChamp hi score patch compatible/ Works with Linux too (hiscore.dat goes in the \hi\ directory)
* Froger/Galaxian resolution fixes for Windows and Linux (so they look normal for arcade resolutions)
* Sound sync for Windows (not in Linux) triplebuffer, capable of being turned off (default)
* Clean stretch both Windows and Linux
* Redraw frames so 30Hz games run at 60Hz like Tron in Windows and Linux
* Most settings and features are automatically set as needed depending on the resolution used,
like if throttling is necessary, or can use vsync instead, or fall back to triplebuffer.
* In Windows can use ArcadeVGA 3000 cards or others without any .ini files, picks best resolution automatically
Notes:
Always start with a fresh mame.ini file generated from groovymame, the defaults are
the best for modeline generation and different from normal mame or cabmame or any other
mame.
ATI cards, mostly 9200/9250 and HD2xxx and above cards should be used. In Linux
anything besides the X8xx series should work and in Windows your limited only by
ATI cards that work with Soft15khz (Since we use the same registry custom modelines).
In Linux possibly other cards work, it just depends on if xrandr can setup custom
modelines and the card can handle vsync interrupts properly. Any testing results of
stray cards are welcome, reports are helpful in getting more cards working in the future.
Calamity has custom ATI drivers, 32 and 64 bit, which contain preset custom modelines to
work best with groovymame. That way you don't need Soft15khz unless you want to add more
custom modelines, his drivers have the ability to store close to 120 modelines and that
is the limit (normally only 60 on regular catalyst drivers).
CRT_Emudriver's download site (in Spanish. ftp courtesy of Abubu) (http://postback.geedorah.com/foros/viewtopic.php?id=1424)
Download mirror (courtesy of Krick) (http://mame.3feetunder.com/windows-ati-crt-emudriver/)
#
# CORE SWITCHRES OPTIONS
#
-modeline generate modelines for arcade monitors (only ATI Radeon support in Windows)
-monitor monitor type (cga|generic|h9110|vga|d9200|d9800|m2929|ntsc|pal)
-monitor_connector Linux video card output (VGA-0|VGA-1|DVI-0|DVI-1)
-monitor_orientation monitor orientation (horizontal|vertical|rotate)
-monitor_aspect monitor aspect (4:3|3:3|3:4|16:9)
-monitor_debug monitor debugging
-monitor_doublescan Use doublescan if necessary, not available in Windows
-monitor_dotclock Lowest dotclock videocard accepts, 0 is the default
-monitor_ymin Minimum height to calculate, default is no minimum
-soundsync soundsync to adjust audio freq when using triplebuffer
-cleanstretch cleanstretch integer only scaling
-changeres change resolutions (work in progress)
-redraw multiply amount to draw game screen, make 30HZ games run at 60HZ when set to 2
-monitor_specs0 Add custom monitor specs, format: 15250.00-15700.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288.0,448
-monitor_specs1 Add custom monitor specs
-monitor_specs2 Add custom monitor specs
-monitor_specs3 Add custom monitor specs
-monitor_specs4 Add custom monitor specs
-monitor_specs5 Add custom monitor specs
-monitor_specs6 Add custom monitor specs
-monitor_specs7 Add custom monitor specs
Compiling notes
Apply patches in this order:
1) 0146u1.diff -> 0146u2.diff -> 0146u3.diff -> 0146u4.diff (http://mamedev.org/updates/ (http://mamedev.org/updates/))
2) hi_146.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
3) 0146u4_groovymame_013f.diff (GroovyArcade's site (http://code.google.com/p/groovyarcade/downloads/list))
-
This sounds very cool!! I am (finally) updating my from cabmame .136 to .142 I used cabmame in the past for the audio sync hack. Will groovy do the same thing?
I have so many questions so I'll just start with this one:
Which dist (cab or groovy) is better for someone like me running an ATI Arcade VGA w/ a D9200??
Thanks!!
-
This sounds very cool!! I am (finally) updating my from cabmame .136 to .142 I used cabmame in the past for the audio sync hack. Will groovy do the same thing?
I have so many questions so I'll just start with this one:
Which dist (cab or groovy) is better for someone like me running an ATI Arcade VGA w/ a D9200??
Thanks!!
It will do the soundsync hack, you have to turn it on since it's off by default, being aimed normally by default at getting the vertical refresh rate correct so then it isn't needed.
Which model of ArcadeVGA is it? With a d9200 and the older ArcadeVGA cards I do think it's good, since those cards will allow (I *think*) the normal ATI drivers Calamity has and the custom modelines. Now newer ArcadeVGA 3000 cards are unfortunately unable to play custom modelines in the registry, and are locked at the 30 or so resolutions they have in the video bios.
Basically this has the same ability cabmame, but has the modeline setup built in of Soft15khz, and ability to then go and completely setup different refresh rates of those modelines on the fly when loading a game. The drivers are able to hold more modelines, but essentially doing the same thing as Soft15khz registry modelines yet able to go to 120 or so instead of the normal limit, and contain custom modelines already to use. The options are tuned to trying to get vsync/refresh exactly to the games original settings, and so triplebuffer and soundsync usually aren't necessary but if needed then it'll set them for the game, when it can't match the original refresh rate.
-
This works AWESOME guys.. Thanks to Groovymame and Calamity's drivers I've totally gotten back into this hobby. This is after years of frustration with Soft15 and cabmame alone. The other cool benefit I've found personally is that I rarely have to adjust monitor settings manually between games anymore, it just works. No more living with the tearing vs sound clipping/slowdown compromises.
Fricken awesome, just like Advancemame was.
-
Newest Windows builds now have the ability to utilize the ArcadeVGA3000 and basically avoid needing any .ini files, also probably give you better results than the .ini files did. Might need to make a fresh mame.ini first, and possibly turn on soundsync too.
Also if you have other cards with modelines that are custom setup, with Soft15khz or any other method, should also be similar in performance now too. Now groovymame basically can see all the system resolutions, or active ones to Windows, and only difference from the ATI Radeon custom modelines is you are going to be using tripplebuffer instead of vsync (which probably is the case anyways else the games with the normal static modelines wouldn't match the refresh rates in most cases).
-
Kaspersky flagged the 32 bit version as containing a trojan.
-
Kaspersky flagged the 32 bit version as containing a trojan.
Odd, I highly doubt it's correct, probably one of those false positives I would guess. Might want to send it in to them and see what they say, might be a bug on their end I would guess. I'm uploading 012l builds here in a few minutes, might want to double check them. I'm fresh compiling/uploading them and not a system that is at all used for internet use, so I'm pretty sure they are not infected with anything. Maybe it's the name having 'groovy' in it or some other oddity it's connecting with common virus traits, is Kaspersky set to try and use AI to find new unknown viruses? Since this works with the registry, doing the modeline setup, maybe that's part of what it thinks is dangerous.
Also could always checkout through git or apply the .diff patches instead, see if it reports anything different with that when compiled locally, although I suspect it'll be the exact same binary either way.
Here's a link on reporting a false positive to them: http://forum.kaspersky.com/index.php?showtopic=13881 (http://forum.kaspersky.com/index.php?showtopic=13881)
I'm downloading the free system checker program from them to double check. Do you have the exact label it named the trojan? If it's the Generic one, and there's some setting on for Heuristics I'm guessing, then that makes sense because it's probably just thinking since the registry is accessed things might be acting similar to how trojans access the registry. It looks like priority is given to paying customers, even if something like this where they are reporting a false positive to a persons program, so guessing that they'll listen to you reporting it much quicker than me (and possibly the software has some interface to upload it as a false positive it seems).
-
No worries. Here is what I got:
4/15/2011 9:24:00 AM Malicious HTTP object <http://mame.groovy.org/0142/groovymame32_0142.012k.exe.7z//groovymame32_0142.012k.exe>: detected: virus 'HEUR:Trojan.Win32.Generic' (modification).
I was just gonna download it and install when I got home. Now I hope work doesn't yell at me for downloading mame stuff at work. :lol
-
No worries. Here is what I got:
4/15/2011 9:24:00 AM Malicious HTTP object <http://mame.groovy.org/0142/groovymame32_0142.012k.exe.7z//groovymame32_0142.012k.exe>: detected: virus 'HEUR:Trojan.Win32.Generic' (modification).
I was just gonna download it and install when I got home. Now I hope work doesn't yell at me for downloading mame stuff at work. :lol
Ah yeah, ok, this page explains it: http://malwarecrawler.com/?p=13 (http://malwarecrawler.com/?p=13) Which is basically what I thought, it's guessing at it and probably just the fact it accesses the registry so much, so they heuristic engine is just saying it has the characteristics of a virus. Best to send that into Kaspersky if possible, I'm checking around to see if I can too, so they can fix it.
-
installed it and made a fresh INI. I know that the custom modeline works because my d9800 hundred syncs UMK3 at 56 hx instead on my arcade vga's normal 52.3. however the sides are pinched in in every game and my d9800 is at the maximum for width. any ideas?
-
installed it and made a fresh INI. I know that the custom modeline works because my d9800 hundred syncs UMK3 at 56 hx instead on my arcade vga's normal 52.3. however the sides are pinched in in every game and my d9800 is at the maximum for width. any ideas?
Have you set the monitor setting to d9800 in the mame.ini? If not then that is most likely the issue.
-
yes I have.
-
yes I have.
Try to reset the monitor settings in the OSD to the defaults and see if that helps. I have a d9800 so with mine I don't have to set anything in the OSD at all, by default it all fits correctly. So definitely should technically work, possibly post a log of output with the '-verbose -md 4' as options to groovymame. Also are you using one of the patched/custom drivers for the ATI card? Those have enough modelines to make sure every game can fit correctly. The log output should help me see more though and know if it's the resolution of the modeline being picked or sopmething else.
-
You also need to create the mode list for your D9800 selecting it in VMMaker.ini and running VMMaker and restarting, because the default modelines installed are for standard arcade monitors only.
-
I am not using the custom drivers. Do I need them with the arcade VGA 3000?
-
I am not using the custom drivers. Do I need them with the arcade VGA 3000?
Nope, then possibly the output log would be interesting to see. Also try the newest 012m version of groovymame too since I did fix a bug there and could be an issue. I can look at the logs of 012m if the problem still exists, and see what I can find.
Are all games the same, or some ok and some having space at the sides? With the ArcadeVGA card one drawback is you only have 30 modelines to choose from and so a lot of games are going to not be able to fit perfectly, it's definitely not the card to best utilize the d9800 since there's so many more resolutions a d9800 can do. In a sense you might just do best by using cga mode actually as the monitor type, since that's really going to be the only resolutions anyways a AVGA3000 has available to output, they are all 15khz targeted for the most part basically.
-
Tried the newest version and everything works great!
-
Tried the newest version and everything works great!
Ah cool, it was the bug after all :) great, thanks for reporting everything.
-
With the ArcadeVGA card one drawback is you only have 30 modelines to choose from and so a lot of games are going to not be able to fit perfectly, it's definitely not the card to best utilize the d9800 since there's so many more resolutions a d9800 can do. In a sense you might just do best by using cga mode actually as the monitor type, since that's really going to be the only resolutions anyways a AVGA3000 has available to output, they are all 15khz targeted for the most part basically.
I don't think that's correct. The ArcadeVGA comes with a "tri-sync" utility that enables the higher resolutions on monitors that support them like the d9800. From the Ultimarc ArcadeVGA install page...
http://www.ultimarc.com/avgainst.html (http://www.ultimarc.com/avgainst.html)
After you reboot, the TriSync config utility will start. Select your correct monitor type.
This configures the card to permit the 640x480 and above resolutions to be displayed non-interlaced at 31Khz scan or above. This results in better picture quality for these resolutions but you can only do this if your monitor can display 31Khz scan or above. If its a standard-res arcade monitor it will not.
(http://www.ultimarc.com/images/trisync.jpg)
The top selection leaves the configuration unchanged. You can run this utility later if you upgrade to a multi-frequency monitor. To revert back from multi-frequency to standard res, you can simply re-install the drivers.
-
With the ArcadeVGA card one drawback is you only have 30 modelines to choose from and so a lot of games are going to not be able to fit perfectly, it's definitely not the card to best utilize the d9800 since there's so many more resolutions a d9800 can do. In a sense you might just do best by using cga mode actually as the monitor type, since that's really going to be the only resolutions anyways a AVGA3000 has available to output, they are all 15khz targeted for the most part basically.
I don't think that's correct. The ArcadeVGA comes with a "tri-sync" utility that enables the higher resolutions on monitors that support them like the d9800. From the Ultimarc ArcadeVGA install page...
http://www.ultimarc.com/avgainst.html (http://www.ultimarc.com/avgainst.html)
After you reboot, the TriSync config utility will start. Select your correct monitor type.
This configures the card to permit the 640x480 and above resolutions to be displayed non-interlaced at 31Khz scan or above. This results in better picture quality for these resolutions but you can only do this if your monitor can display 31Khz scan or above. If its a standard-res arcade monitor it will not.
(http://www.ultimarc.com/images/trisync.jpg)
The top selection leaves the configuration unchanged. You can run this utility later if you upgrade to a multi-frequency monitor. To revert back from multi-frequency to standard res, you can simply re-install the drivers.
It's good, I just mean that there's basically a limitless amount of possibilities with a d9800 and Linux, a very expansive amount of possibilities with a d9800 and Windows + 120 modelines using reconfigurable refresh rates, and a more limited amount of possibilities with a d9800 and 30 modelines. Basically the trisync utility gives you a few 24khz and a few 31khz resolutions, and 800x600 38khz resolution. So that is great, and works wonderfully, I'm just meaning that there are the extra lines in height, pixels in width that can be trimmed off and the refresh rates can be matched exactly for every game. I guess with this issue I get pretty technical, on a very core level of looking at really what is possible, and admit that I might be splitting hairs but for me it's really looking at the specs of height x width @ refresh rate capabilities. There is really nothing that can beat the AVGA 3000 in Windows with general arcade monitors and ease of use through multiple operating systems. There's just a big open space with a d9800 that you can really have any resolution between 15-38khz (even between 15-24 or 24-31 or 31-38, not fixed on those exact frequencies), there is a big open range of freedom I have seen with the d9800 that is quite amazing, and really not even obtainable with the windows patched ATI drivers even though they are quite a step above the AVGA 3000 at having only 30 or so resolutions compared to 120.
-
It's good, I just mean that there's basically a limitless amount of possibilities with a d9800 and Linux, a very expansive amount of possibilities with a d9800 and Windows + 120 modelines using reconfigurable refresh rates, and a more limited amount of possibilities with a d9800 and 30 modelines. Basically the trisync utility gives you a few 24khz and a few 31khz resolutions, and 800x600 38khz resolution. So that is great, and works wonderfully, I'm just meaning that there are the extra lines in height, pixels in width that can be trimmed off and the refresh rates can be matched exactly for every game. I guess with this issue I get pretty technical, on a very core level of looking at really what is possible, and admit that I might be splitting hairs but for me it's really looking at the specs of height x width @ refresh rate capabilities. There is really nothing that can beat the AVGA 3000 in Windows with general arcade monitors and ease of use through multiple operating systems. There's just a big open space with a d9800 that you can really have any resolution between 15-38khz (even between 15-24 or 24-31 or 31-38, not fixed on those exact frequencies), there is a big open range of freedom I have seen with the d9800 that is quite amazing, and really not even obtainable with the windows patched ATI drivers even though they are quite a step above the AVGA 3000 at having only 30 or so resolutions compared to 120.
Gotcha. I didn't know that the ArcadeVGA tri-sync resolutions were still limited. It's a shame that my cabinet is a funky narrow job that just barely fits my 25" monitor or I'd try to get my hands on a d9800. The inside width of my cabinet is exactly 24 inches, I think.
-
I'm running the latest groovymame64_0142.012n.exe on my ArcadeVGA 3000 on a 15KHz arcade monitor.
I was trying random games tonight and I noticed that Sinistar was running at 640x480 interlaced. Is this normal?
Here's the stats from MAWS...
display type raster
orientation vertical
resolution 240x292
frequency 60.096154Hz
If 640x480 is the best/closest resolution that the ArcadeVGA can do, that's fine. I just wanted to see if it was a bug or something. I think that's the only game that uses that funky resolution anyway (240x292) and it's almost impossible to play without the original rubber-band loaded joystick.
Doing a little googling, I found this thread...
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=48388&PHPSESSID=5ede15166544f3209dd336d000f9e069 (http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=48388&PHPSESSID=5ede15166544f3209dd336d000f9e069)
He's talking about running MAME 129u3 on linux using an ArcadeVGA2, so some of it may not be valid anymore.
However, in the first post, near the bottom, he says...
"Some games declare the wrong internal resolution or otherwise appear at the wrong size, especially those that resize themselves during gameplay. To get around this, you can call "xrandr" manually to set your resolution and use "-noswitchres" to keep it there:"
...and then he gives a list of "game-specific workarounds" for these problem games. Note that Sinistar is in the list and his workaround forces it to 480x288x50.00, which doesn't appear to be one of the supported resolutions listed on the ArcadeVGA page. However since he's running Linux, he's creating his own list of resolutions.
I'm going to play around with the games in his list tomorrow and see which, if any end up running "weird" resolutions on my current setup.
-
I'm running the latest groovymame64_0142.012n.exe on my ArcadeVGA 3000 on a 15KHz arcade monitor.
I was trying random games tonight and I noticed that Sinistar was running at 640x480 interlaced. Is this normal?
Here's the stats from MAWS...
display type raster
orientation vertical
resolution 240x292
frequency 60.096154Hz
If 640x480 is the best/closest resolution that the ArcadeVGA can do, that's fine. I just wanted to see if it was a bug or something. I think that's the only game that uses that funky resolution anyway (240x292) and it's almost impossible to play without the original rubber-band loaded joystick.
Doing a little googling, I found this thread...
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=48388&PHPSESSID=5ede15166544f3209dd336d000f9e069 (http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=48388&PHPSESSID=5ede15166544f3209dd336d000f9e069)
He's talking about running MAME 129u3 on linux using an ArcadeVGA2, so some of it may not be valid anymore.
However, in the first post, near the bottom, he says...
"Some games declare the wrong internal resolution or otherwise appear at the wrong size, especially those that resize themselves during gameplay. To get around this, you can call "xrandr" manually to set your resolution and use "-noswitchres" to keep it there:"
...and then he gives a list of "game-specific workarounds" for these problem games. Note that Sinistar is in the list and his workaround forces it to 480x288x50.00, which doesn't appear to be one of the supported resolutions listed on the ArcadeVGA page. However since he's running Linux, he's creating his own list of resolutions.
I'm going to play around with the games in his list tomorrow and see which, if any end up running "weird" resolutions on my current setup.
Oh no that's abnormal, I play it and it gets the resolution correct here. There's a couple possibilities, I'm hoping that the current ISO didn't get that same bug that was in the windows groovymame version there. That bug could have done such a thing, but also it might be the monitor type selection your picking too.
A couple things could be wrong, make sure the monitor type is setup right and the xorg configuration is getting correctly setup from that, and that groovymame is running with that monitor type correctly. The main way to do this would be to get the output of groovymame with the -verbose -md 4 argument just like in Windows, possibly the /etc/X11/xorg.conf file too, maybe the mame.ini file also.
That might point to if the bug is really happening, or it's the monitor setup. Actually if your running a monitor able to do more than just 15khz and do 31khz too then it should be picking progressive for the desktop and never using interlacing. So suspect it's the monitor selection that is wrong. Which monitor type are you picking?
Update: Ah crap, I think that the groovymame in the ISO is tainted with that bug too, at least I don't trust it and it was version 012j which in Windows had the issue. I made a change around there in how it checks for .ini files and it was fouled up at first. I'm rebuilding new ISO images and will have them up hopefully by later this evening, sorry about that. Also the logs might still be interesting to prove it's really this, just in case it isn't and there's something else. It does sound odd still that it's using interlaced at all there.
-
I got the 32 bit ISO uploaded, 1.560, see if it fixes the issue. If not get some logs possibly, and let me know the video monitor settings too, which monitor are you choosing. 64bit ISO will be up probably by this evening.
-
I think I might have confused you.
I'm running Windows on a low-res 15KHz monitor with an ArcadeVGA 3000.
I was seeing what I suspected is odd behavior with Sinistar in the latest GroovyMAME build for Windows.
THEN...
I started doing a little searching and I discovered that post from that fellow who was running SDLMAME on Debian.
I see that he had to do some workarounds to account for games that mis-reported their resolutions or otherwise didn't end up with the correct final resolution.
Sinistar was one of the games in the list. I thought it might be related.
-
I think I might have confused you.
I'm running Windows on a low-res 15KHz monitor with an ArcadeVGA 3000.
I was seeing what I suspected is odd behavior with Sinistar in the latest GroovyMAME build for Windows.
THEN...
I started doing a little searching and I discovered that post from that fellow who was running SDLMAME on Debian.
I see that he had to do some workarounds to account for games that mis-reported their resolutions or otherwise didn't end up with the correct final resolution.
Sinistar was one of the games in the list. I thought it might be related.
Ah I see, yeah I got confused. It might still be the version of groovymame in that ISO, would affect all monitor types with that. It sounds like it isn't actually modeswitching, which does seem like a symptom of that bug in the Linux side of things. It should be able to fit to that resolution quite easily at 15khz.
-
I've attached the output log from running Sinistar.
groovymame64_0142.012n.exe
Windows XP x64
ArcadeVGA 3000
Hantarex Polo 25 - standard res 25-KHz arcade monitor
-
I've attached the output log from running Sinistar.
groovymame64_0142.012n.exe
Windows XP x64
ArcadeVGA 3000
Hantarex Polo 25 - standard res 25-KHz arcade monitor
Ah ok, the issue is that it's a vertical game, and that 15khz monitor can't do the 296 scanlines it requires horizontally. So it has to virtualize to get enough and must do 640x480 interlaced to go above the 288 line limit. Plus the arcadeVGA doesn't have any better modelines for it either that aren't interlaced, it's picking the best one for that setup.
Now the question is can you give a smaller resolution than the needed vertical and have it basically scale down, is that better than interlaced? Calamity might know more about that, or you might from tests and previous usage with .ini files? It's basically the age old vertical game on horizontal monitor, which happens to go above the 288 limit so it's probably one of the few games that would run into this issue.
Yeah I was really confused, hah, well have been busy and read this all over a small iphone while bowling, brain was on the groovy arcade linux and d9800 monitors :) Ah well, the ISO probably had the same bug too so good to have updated it anyways.
-
Yes, you can use a progressive resolution of 400x288 and have your upper and lower borders chopped. It's a matter of taste, I prefer always having the whole picture in the screen even if it needs interlacing, and that was one of the premises of the modeline algorithm. However interlace looks horrible in some monitors and not so bad in others. You can try by using an ini for that game with 'resolution0 400x288' option.
-
I'm using 141u3, but didn't know where else to post. I'm just trying groovymame out with an ATI X800 and drivers set 9.3 . I created an ini through GM. I'm getting weird default resolutions, for example, 320x250 for DK. Some custom resolution for Pole Position that is 15.1khz/61hz .
-
I'm using 141u3, but didn't know where else to post. I'm just trying groovymame out with an ATI X800 and drivers set 9.3 . I created an ini through GM. I'm getting weird default resolutions, for example, 320x250 for DK. Some custom resolution for Pole Position that is 15.1khz/61hz .
In 0142 I've reworked the method of picking the right resolution quite a bit. It'll probably do much better in 0142 and using the newest drivers linked on the 0142 page. I now see what page, the older versions, that have the dead links. I'll change those when I get home, also I probably need to move the older versions to an archive directory since they are really behind in the ability of the newest developments.
-
In 0142 I've reworked the method of picking the right resolution quite a bit. It'll probably do much better in 0142 and using the newest drivers linked on the 0142 page.
It doesn't seem to be working that way.
I'm using an X800, have installed the 6.5 drivers, GM142, created an ini from it, and in DK and Mspac run vertical on horizontal monitor, I'm getting some weird interlaced-like image, even though it appears to be running at 640x240. Not only that, but the left side of the image is cut, and re-appears on the right edge of the screen.
It seems to prefer 320x250 for 256x240 games.
With the 9.3 drivers, I was getting 320x250 on DK. I don't remember what it used for horizontal games; maybe the same.
-
In 0142 I've reworked the method of picking the right resolution quite a bit. It'll probably do much better in 0142 and using the newest drivers linked on the 0142 page.
It doesn't seem to be working that way.
I'm using an X800, have installed the 6.5 drivers, GM142, created an ini from it, and in DK and Mspac run vertical on horizontal monitor, I'm getting some weird interlaced-like image, even though it appears to be running at 640x240. Not only that, but the left side of the image is cut, and re-appears on the right edge of the screen.
It seems to prefer 320x250 for 256x240 games.
With the 9.3 drivers, I was getting 320x250 on DK. I don't remember what it used for horizontal games; maybe the same.
Post a log of -verbose -md 4 as command line args to groovymame, that'll possibly help see what is going on.
-
This is my first post on the forum.
Hello to all.
Thanks for providing groovymame. I can now play games on my cab without tearing and no stuttering sound.
But I have one problem: The highscores wont get saved. I put the newest highscore.dat in the mame folder. In mame.ini I set "disable highscore patch" to 0. But there aren't any files in the hi folder.
I am using MaLa as a frontend.
Does anyone else has this problem.
-
But I have one problem: The highscores wont get saved. I put the newest highscore.dat in the mame folder. In mame.ini I set "disable highscore patch" to 0. But there aren't any files in the hi folder.
You either have to make some, or copy over old files of your own.
-
I thought, mame generates the hi-file when I run a game.
-
I'm using an X800, have installed the 6.5 drivers, GM142, created an ini from it, and in DK and Mspac run vertical on horizontal monitor, I'm getting some weird interlaced-like image, even though it appears to be running at 640x240. Not only that, but the left side of the image is cut, and re-appears on the right edge of the screen.
It seems to prefer 320x250 for 256x240 games.
With the 9.3 drivers, I was getting 320x250 on DK. I don't remember what it used for horizontal games; maybe the same.
Are you using 6.5 for XP-64? Are you generating more than 120 modelines for that?
Definitely a log with -v -md 4 will tell us what's happening.
-
I thought, mame generates the hi-file when I run a game.
Make the hi directory in your home folder or folder you run mame from (or one pointed to from mame.ini) and put the hiscore.dat file in that directory. It just has to be in the \hi\ directory now with the changes I've made.
-
Excellent. Problem solved.
Thank you
-
Please clarify your license, you can't link MAME against GPL code, and I've been told you're distributing your changes as GPL with no exception being made for MAME use.
-
Please clarify your license, you can't link MAME against GPL code, and I've been told you're distributing your changes as GPL with no exception being made for MAME use.
I had the old switchres files headers at the top, I have now removed those references to the GPL since this was never intended to be under any license other than the Mame license. It's in the git repository now, and the patch file is updated, so all files should no longer reference GPL and I being the sole person who put those references in them have revoked that and reverted them to the Mame license (which I originally intended them to be, just an oversite on removing the references from switchres code).
-
double posted, didn't realize it went into page number 2 :)
-
I've got two weird ones for you (see attached log files)...
1) wargods
Native resolution: horizontal 512x400
Resolution chosen by GroovyMAME: 800x600@59Hz (interlaced)
I'm confused on this one. It appears that 512x448@59Hz is one of the available resolutions, but it was skipped over for some reason.
2) 19xx
Native resolution: vertical 384x224 @59.63 (which is guess is actually 224x384 )
Resolution chosen by GroovyMAME: 640x480@59Hz (interlaced)
Now that I think about it, I think this is the same issue as Sinistar and I'll have to remedy it by forcing whatever resolution looks most acceptable. Maybe even running it in D3D mode and letting it hwstretch. It's gotta look better than interlaced.
As an aside, the main reason I'm having issues with the interlaced resolutions is that my monitor looks very bad interlaced. I think there might actually be something wrong with it because the alignment of the two "passes" aren't even close. It's not just flickering, it's misaligned by a scan-line or two. Asteroids at 640x480 interlaced looks particularly bad. It's like double-vision. I think I'm going to have to bite the bullet and do a cap kit on my monitor. I just didn't want to mess with anything because there's always the chance that after the cap kit, it won't work at all if I make a mistake.
-
In mame.ini, add a line like this:
monitor_specs0 15625.00-16200.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288.0,384
The important number here is the last one, we call it VirtualLinesLimit. Normally you would set it to 448 for standard arcade monitors. It means that any resolution below that number of lines will be stretched + interlaced. Above it, they will only be interlaced. So in your case, as you have to play with the standard ArcadeVGA resolutions, it's probably better to set it to 384.
This will fix the wargods one.
For 19xx it's choosing the best resolution available indeed, provided interlace was not a problem.
I'm aware of the problem that interlaced resolutions are to some monitors, I've seen what you say and it's truly unbearable. On the other hand, if your monitor can deal with interlacing properly then it's a great resource for virtually doubling your vertical resolution at the cost of loosing sharpness. All our methods assume interlace works fine, maybe an option for not using interlaced modes could be eventually added but that would involve changing the logic quite a bit.
-
Please clarify your license, you can't link MAME against GPL code, and I've been told you're distributing your changes as GPL with no exception being made for MAME use.
I had the old switchres files headers at the top, I have now removed those references to the GPL since this was never intended to be under any license other than the Mame license. It's in the git repository now, and the patch file is updated, so all files should no longer reference GPL and I being the sole person who put those references in them have revoked that and reverted them to the Mame license (which I originally intended them to be, just an oversite on removing the references from switchres code).
Ok, thanks for clearing that up so quickly :-)
-
Hi,
I have an ArcadeVGA2 card hooked to a WG7000 series arcade monitor. I love the way it sets the resolution without the additional .ini files.
I'm having a few issues with tearing which I thought was supposed to be corrected according to the features. Maybe someone can help me.
I did a clean install of GroovyMAME and generated the .ini file. First thing I noticed is that the games ran way too fast so I set throttle to 1 (0 by default, not sure why) which fixed that. Now, I still notice tearing in games (Mortal Kombats title screen sides and ladder scrolling are choppy and a few other side scrolling games as well that I have tried). I have tried all sorts of combination settings with waitvsync, syncrefresh, triplebuffer, soundsync etc. with no success of getting the tearing to stop. Can someone explain how I should have my ini files setup to get rid of this problem or post an example? Much appreciated.
Brett
-
Hi,
I have an ArcadeVGA2 card hooked to a WG7000 series arcade monitor. I love the way it sets the resolution without the additional .ini files.
I'm having a few issues with tearing which I thought was supposed to be corrected according to the features. Maybe someone can help me.
I did a clean install of GroovyMAME and generated the .ini file. First thing I noticed is that the games ran way too fast so I set throttle to 1 (0 by default, not sure why) which fixed that. Now, I still notice tearing in games (Mortal Kombats title screen sides and ladder scrolling are choppy and a few other side scrolling games as well that I have tried). I have tried all sorts of combination settings with waitvsync, syncrefresh, triplebuffer, soundsync etc. with no success of getting the tearing to stop. Can someone explain how I should have my ini files setup to get rid of this problem or post an example? Much appreciated.
Brett
Did you use the customized ATI drivers? For the older ArcadeVGA cards like yours based of the Radeon 92XX versions, those patched drivers will allow you to get the refresh rate matched properly. Calamity might have some more information on the issue, but I suspect it can be fixed by using the patched drivers instead of the ones that came with the ArcadeVGA.
Update: Another option, but less optimal, is to try with -nosyncrefresh, and -nomultithreading, not the best compared to the custom drivers but that enables triplebuffer, also in that case might want -soundsync too. That is the quick less optimal way to get it to avoid tearing, but best to use the custom drivers for that card.
-
I'm using the drivers that came with the ArcadeVGA card (or off the Ultimarc site, can't remember). I was afraid of messing with drivers but you think I should use these new drivers and that may fix the issues?
-
I'm using the drivers that came with the ArcadeVGA card (or off the Ultimarc site, can't remember). I was afraid of messing with drivers but you think I should use these new drivers and that may fix the issues?
Lets see what Calamity says to make sure to avoid messing with the drivers if it's not going to work, but I'm pretty sure it will. Do you have the AGP or PCIe version of the card? Isn't it the one that's a Radeon 9250?
Basically the custom drivers will put in 120 custom modelines, and those can have the refresh rate altered by groovymame dynamically on each game load. Otherwise with the normal Ultimarc drivers for that card you only have 30 resolutions and we can't alter the refresh rates, so can never match it unless it's just lucky and matches the 60hz or whatever value the default is for that modeline.
So I'm pretty sure it'll just work great with the custom drivers, and that's pretty much what Calamity and everyone else is doing, his custom drivers will work with an ArcadeVGA card just fine, unless it's the 3000 model, which is different than the others (which groovymame still works with, just can't do the same complex refresh rate altering on the 3000 unless it's used in Linux).
The alternative command line option though, could be tried until Calamity shows up, probably later today he'll respond. I'm curious how that works anyways, basically what it does is by specifying -nosyncrefresh -nomultithreading -soundsync it will use triplebuffer and setup things according to that, and avoid tearing that way which does have some downsides compared to the vsync refresh method used by the custom drivers when we are able to match the refresh rates exactly. This is the alternative when we can't know the refresh rates of the modelines and expect them most likely not to match exact, since they are not custom ones where we can actually see the timings and calculate the refresh rates from those timings (and then alter them if different).
-
Hi,
I have an ArcadeVGA2 card hooked to a WG7000 series arcade monitor. I love the way it sets the resolution without the additional .ini files.
I'm having a few issues with tearing which I thought was supposed to be corrected according to the features. Maybe someone can help me.
I did a clean install of GroovyMAME and generated the .ini file. First thing I noticed is that the games ran way too fast so I set throttle to 1 (0 by default, not sure why) which fixed that. Now, I still notice tearing in games (Mortal Kombats title screen sides and ladder scrolling are choppy and a few other side scrolling games as well that I have tried). I have tried all sorts of combination settings with waitvsync, syncrefresh, triplebuffer, soundsync etc. with no success of getting the tearing to stop. Can someone explain how I should have my ini files setup to get rid of this problem or post an example? Much appreciated.
Brett
Hi bgmagic,
First, make sure vsync does not work actually, use the -syncrefresh param that with GroovyMame basically forces the vsync mechanism whatever the refresh is. Leave throttle as 0 (it will be set to 0 by -syncrefresh anyway).
If doing this you still have tearing, or probably the game running full speed, then there's a big chance that your ddraw acceleration is not working, what usually is due to badly installed video drivers. Run 'dxdiag' and in the screen tab check if all ddraw/d3d features are enabled. If they're not, don't look any further, that's the issue. You'll need to uninstall/reinstall drivers, until dxdiag shows ddraw is enabled. You may need to do this several times (yes).
If you finally need to go through the driver reinstalling path, then it could be interesting to try the patched ones here: http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
Version 6.5 is the one that supports some older models of ArcadeVGA (1 & 2, not the 3000), just the ones which chipsets I've known (see the driver's .inf file for detais).
-
I'm pretty sure its the 9250 and its definitely the AGP one. I'll keep my eyes posted on here but I think you are right. When I set it up I used the drivers that Ultimarc sent and there was a little utility to generate ini files for each game. I took those ini's out and GroovyMame matched the resolution exactly if they were still there except I'm guessing it was NOT matching the refresh rate because I didn't have the custom drivers installed. So basically no matter what combination of settings I changed in the mame.ini file I got the same frame tearing result. I will try it tonight and see what happens.
-
Is your monitor a 15KHz monitor or a 25KHz monitor?
I'm using groovymame with the default settings aith an ArcadeVGA 3000 and the ultimarc drivers on a 15KHz monitor. I'm not having any speed issues with games at all. Is there something unique about the older ArcadeVGA card that makes it behave different?
However, I did notice that when I attached my ArcadeVGA to my desktop LCD, the games were unplayably fast, which doesnt make any sense.
-
Also, can I set these things like -nosyncrefresh -nomultithreading -soundsync in the ini or do I have to add them to the command line after mame.exe?
And its a 15Khz monitor.
-
Is your monitor a 15KHz monitor or a 25KHz monitor?
I'm using groovymame with the default settings aith an ArcadeVGA 3000 and the ultimarc drivers on a 15KHz monitor. I'm not having any speed issues with games at all. Is there something unique about the older ArcadeVGA card that makes it behave different?
However, I did notice that when I attached my ArcadeVGA to my desktop LCD, the games were unplayably fast, which doesnt make any sense.
Yeah in the older ArcadeVGA cards they didn't have the video bios based modelines, they were registry based. So older cards are pretty close to a normal Radeon, the 3000 has completely reworked the video bios so official ATI stuff won't work with it correctly.
Those options would be on the command line, in the .ini they would be...
syncrefresh 0
triplebuffer 1
soundsync 1
Which you should find the current setting in the mame.ini file and change them to these values, else the old one might override any new settings you put in there.
Update: Changed options above to what they should actually be :)
-
Try installing the latest DirectX using the web installer...
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en)
-
EDIT: I've moved this to the switchres thread to keep this one cleaner and for new comers...
http://forum.arcadecontrols.com/index.php?topic=106405.msg1181189#msg1181189 (http://forum.arcadecontrols.com/index.php?topic=106405.msg1181189#msg1181189)
-
Okay... I installed the Custom Drivers and reinstalled DirectX. All frame tearing issues are gone which is great but I have lots of sound skipping issues. Mortal Kombat music and sound effects double play sometimes and other games as well. I turned soundsync on and tried other combinations and can't seem to get it to go away. Any ideas on this one?
-
Okay... I installed the Custom Drivers and reinstalled DirectX. All frame tearing issues are gone which is great but I have lots of sound skipping issues. Mortal Kombat music and sound effects double play sometimes and other games as well. I turned soundsync on and tried other combinations and can't seem to get it to go away. Any ideas on this one?
Possibly posting the output with '-verbose -md 4' added to the groovymame command line will help, and also curious what Calamity thinks of that issue, he might have more ideas than me on that. Sounds strange, double playing like that, never experienced that before but it may be some windows specific reason for it that I haven't seen in Linux.
Also I'm uploading a new build 012o, which has a patch from Calamity which somewhat simplifies the logic in the setup for the mame.ini and refresh speed stuff. It should be uploaded in about 30 minutes or less, just make sure the file size isn't changing still and it should be done uploading and ready to download.
Here's his explanation of it, at least it'll give you more options possibly to deal with, and does some different stuff which I suspect might help, not 100% sure...
So now, the default behaviour (with everything off) is that groovymame decides
if enabling vsync or not. This will be fine for most games, but the ones for
which we don't get to match the refresh, or maybe in the AVGA 3000 where we
can't do custom modes. In these cases, tearing will happen.
In order to remove tearing, the user will have two options: -syncrefresh or
-triplebuffer.
With syncrefresh the action is forced to run at the refresh speed (soundsync
optional).
On the other hand, if triplebuffer is selected, it will override -syncrefresh
and just enable throttle to run 100% but flipping pages to remove tearing
(flips are synched to retrace but not action). There will be scroll hiccups
due to frameskipping but this is not an issue with games like pacman.
One can also use -syncrefresh as a general option, and just enable
-triplebuffer when needed.
All these options assume that multithreading is on, that is the default. If
it's off, then -triplebuffer will adjust the speed to the refresh in the same
way -syncrefresh does, but with really heavy input lag, so it's a combination
to avoid.
-
Okay... I installed the Custom Drivers and reinstalled DirectX. All frame tearing issues are gone which is great but I have lots of sound skipping issues. Mortal Kombat music and sound effects double play sometimes and other games as well. I turned soundsync on and tried other combinations and can't seem to get it to go away. Any ideas on this one?
What kind of cpu do you have and what speed? That sounds like the classic underpowered cpu symptoms in MAME.
-
I am having problems with two games:
1. Frogger
In MaLa the resolution of Frogger is listed as 768x224. When I start it, I get a interlaced small picture. When I edit the frogger.ini to 256x240 I only get some part of the screen whitch is much to big. In an older version of MAME32UI it runs fine at 256x240.
2. 19xx
Game runs at 86% when pressing F11. But it didn't look that slow. So I handstopped the time of the intro of the game and compared with MAME32UI and the groovymame runs at about 95% compared to MAME32UI.
My settings are : syncrefresh 1, vsync 0, tripplebuffer 0, sounsync 1
One further question: I am running Catalyst 6.5 and the soft15kHz patch. Is there any benefit in installing the patched drivers from Calamity.
Any help is appreciated.
-
I thought, mame generates the hi-file when I run a game.
Oh, I see, you hadn't it set right. It does create the files....though, there's no 'high score' beyond a game's defaults, until you make one.
I'm using an X800, have installed the 6.5 drivers, GM142, created an ini from it, and in DK and Mspac run vertical on horizontal monitor, I'm getting some weird interlaced-like image, even though it appears to be running at 640x240. Not only that, but the left side of the image is cut, and re-appears on the right edge of the screen.
It seems to prefer 320x250 for 256x240 games.
With the 9.3 drivers, I was getting 320x250 on DK. I don't remember what it used for horizontal games; maybe the same.
Are you using 6.5 for XP-64? Are you generating more than 120 modelines for that?
Definitely a log with -v -md 4 will tell us what's happening.
I'm using XP32, and was using cat 6.5 . I forgot to get a log. However, I decided to go back to my original configuration. I'll call if I head along this direction again and run into issues. Thanks.
-
One further question: I am running Catalyst 6.5 and the soft15kHz patch. Is there any benefit in installing the patched drivers from Calamity.
So you mean you installed Soft-15Khz over my drivers? That's probably the issue.
You don't need Soft-15Khz with these drivers, it will override our predifined resolutions that GroovyMame expects to find. Just install the drivers and run GroovyMame after that!
When you feel there's some tweaking needed for the video modes, use VMMaker app included to better adjust them for your particular monitor.
EDIT: Also, make sure to remove or rename your old ini folder, otherwise it will mess with GroovyMame setup.
-
No, I didn't install your drivers at all. I just found out about groovymame a few days ago and I was wondering if I should uninstall Catalyst 6.5 and install your dirvers instead. Is there any benefit?
-
No, I didn't install your drivers at all. I just found out about groovymame a few days ago and I was wondering if I should uninstall Catalyst 6.5 and install your dirvers instead. Is there any benefit?
Oh sorry man, I mistook your nick with bgmagic above :)
Yes, there's a big benefit in using the patched drivers, it doubles the number of resolutions your can use, so it will fit your games much better. Also the predefined resolutions are the ones that GroovyMame expects to find, so you'll find that it chooses a perfect resolution most of the times.
-
Ok, then I will try your drivers.
Just to make sure: Is it still possible with your drivers to set the resolution manually in the ini file?
There is a program called ArcadeVGARes whitch generates the ini files with the low arcade resolutions.
Another question: How can I find out which resolution on a certain game groovymame actually chooses. Is there some onscreen display or log-file to find out what resolution was chosen?
Thank you for your help.
-
Ok, then I will try your drivers.
Just to make sure: Is it still possible with your drivers to set the resolution manually in the ini file?
There is a program called ArcadeVGARes whitch generates the ini files with the low arcade resolutions.
Another question: How can I find out which resolution on a certain game groovymame actually chooses. Is there some onscreen display or log-file to find out what resolution was chosen?
Thank you for your help.
Yes you can use inis but that's not the intended way with GroovyMame. You can still use an ini for a particular game if you feel it's needed, but should never generate a complete ini folder.
Actually the VMMaker app included with the drivers can also generate inis much better than AVRes as they are done at the same time the modelines are calculated so the refreshes are really known, but that method is, let's say, the classic old one, and not the default any more (see VMMaker.ini for details).
If you want to know which resolution groovymame is using run it with the -v -md 4 params and it will prompt all the information about that.
-
One final (?) question before I install the drivers:
I have two cabs connected to one computer (one cab is for horizontal the other for vertical games).
I have an ATI Radeon 9600 card with one VGA output and one DVI. I use an VGA-adapter on the DVI output. The two monitors (actually one arcade monitor and one TV with scart connected to VGA) run in clone-mode. I activate the clone mode in the ATI control center.
I think with your drivers I don't have the control center any more. How can I active the clone mode?
Is it still possible to install the control center?
-
One final (?) question before I install the drivers:
I have two cabs connected to one computer (one cab is for horizontal the other for vertical games).
I have an ATI Radeon 9600 card with one VGA output and one DVI. I use an VGA-adapter on the DVI output. The two monitors (actually one arcade monitor and one TV with scart connected to VGA) run in clone-mode. I activate the clone mode in the ATI control center.
I think with your drivers I don't have the control center any more. How can I active the clone mode?
Is it still possible to install the control center?
Oh I see...
I'd just search for the control center that matches the Catalyst version you're going to use, and install it. It won't break anything provided you just use that for cloning.
I have never tried ATI's clone mode, will be interesting to see your results.
-
I have two cabs connected to one computer (one cab is for horizontal the other for vertical games).
For your setup, you'd better edit VMMaker.ini after driver's install, to set MonitorHorizontal param to 0. Then run VMMaker and restart.
Otherwise resolutions for vertical games would be generated as rotated.
Then, edit mame.ini and edit this param:
monitor_orientation rotate
-
I uninstalled the Catalyst driver, installed your driver and after that installed the Control Center.
Unfortunately the control center doesn't run with your driver. I get the error message that I dont have permission to change the settings in the control center.
So now I can not run the clone mode.
I guess I have to go back to Catalyst + soft15kHz.
Thank you for your help.
-
I uninstalled the Catalyst driver, installed your driver and after that installed the Control Center.
Unfortunately the control center doesn't run with your driver. I get the error message that I dont have permission to change the settings in the control center.
So now I can not run the clone mode.
I guess I have to go back to Catalyst + soft15kHz.
Thank you for your help.
Oh I see. Yours is not a common setup. I personally never install CCC, so can't be of much help :( Actually it should work provided it's the same version (it shouldn't notice the difference with regular drivers).
The clone feature, imho, is a BAD thing, just a quick workaround for people plugging TVs to their computers. When the clone mode is on, usually a minimum common compromise setup is applied to both monitors, loosing advanced hardware feature access, like custom refresh settings. Probably in your case it's working fine because both monitors are similar CRTs. The "professional" way to go is to have each monitor as a separate device with it's own independent desktop (you don't need CCC for this, just Screen/Properties tab), but I can't figure an easy way for you to set things like that with current GroovyMame.
Probably it's easier for you to go back to Catalyst + Soft15Khz, you'll still be able to have a rather enjoyable system with GroovyMame, specially if you have both horizontal and vertical monitors so you don't need SO many resolutions to make vertical games fit in a horizontal monitor.
-
Okay... I installed the Custom Drivers and reinstalled DirectX. All frame tearing issues are gone which is great but I have lots of sound skipping issues. Mortal Kombat music and sound effects double play sometimes and other games as well. I turned soundsync on and tried other combinations and can't seem to get it to go away. Any ideas on this one?
What kind of cpu do you have and what speed? That sounds like the classic underpowered cpu symptoms in MAME.
Its a single core AMD 3200+. Should be plenty to run most games. I basically get sound skipping every few seconds. The audio is clear but every few seconds there is a hiccup almost like the sound is trying to catch up to the video. Hard to explain but it does it on every game I tried last night which was about 50 of them. Its gotta be something stupid. I messed with the syncrefresh, waitvsync, triplebuffer, and soundsync settings and one of the settings gave me clean audio but the pitch was lower and the games ran a tad slower. I'm trying to figure out how you guys got this to produce no tearing and perfect audio. I just havent seen it yet.
-
Calamity, sorry I made a mistake.
Control Center not running had nothing to do with your drivers. The reason for the error was, I disabled a lot of (unnecessary(?)) Windows services in order to have a slim and fast system. But in order to run the control center I had to enable some of those services.
So, the control center runs with your drivers.
But there is another problem. I cannot enabel the secondary monitor.
With soft15k you have to separately patch both the primary and the secondary vga output.
Maybe with your driver only the primary output is patched.
Anyway, I went back to soft15k and everything runs ok.
Thank you for your help.
-
Calamity, sorry I made a mistake.
Control Center not running had nothing to do with your drivers. The reason for the error was, I disabled a lot of (unnecessary(?)) Windows services in order to have a slim and fast system. But in order to run the control center I had to enable some of those services.
So, the control center runs with your drivers.
But there is another problem. I cannot enabel the secondary monitor.
With soft15k you have to separately patch both the primary and the secondary vga output.
Maybe with your driver only the primary output is patched.
Anyway, I went back to soft15k and everything runs ok.
Thank you for your help.
Ah, good to know that CCC can be used there too. Yes, Soft-15Khz has better support for multi-monitor setups, it installs its modelines for both devices. So better use it for your setup. I'll add multi-monitor support in VMMaker and ArcadeOSD eventually, it's actually quite straight forward but right now it would introduce an additional layer of complexity for GroovyMame having to guess which monitor to use (I mean having them independent, not in clone-mode).
-
Anyone got any ideas on my sound issues?
-
Its a single core AMD 3200+. Should be plenty to run most games. I basically get sound skipping every few seconds. The audio is clear but every few seconds there is a hiccup almost like the sound is trying to catch up to the video. Hard to explain but it does it on every game I tried last night which was about 50 of them. Its gotta be something stupid. I messed with the syncrefresh, waitvsync, triplebuffer, and soundsync settings and one of the settings gave me clean audio but the pitch was lower and the games ran a tad slower. I'm trying to figure out how you guys got this to produce no tearing and perfect audio. I just havent seen it yet.
What follows is only valid for GroovyMame starting from 12o. Older versions work slightly different. Regular Mame is another story (we've somewhat modified the way -syncrefresh, -waitvsync, -triplebuffer are implemented).
Well basically we try to calculate modelines with a refresh that matches the game's original fps. But that's not always possible, due to the usual limitations of monitors that can only sync at some ranges of hfreq. So, what actually determines which frequencies we can produce is the monitor type option we select mame.ini.
If you leave the default "cga" monitor, all 240 lines resolutions will be fine, but you won't be able to set a video mode of i.e. 400x256@60, it will only reach around 400@256@57. So for a game like 1942 that runs at 60 Hz, GroovyMame by default will disable sync to vertical retrace, and you'll have tearing.
We can force to sync to vertical retrace by enabling -syncrefresh. Inmediately, the game 1942 will reduce its speed to 95% (57/60). Scroll will be perfectly smooth. As sound is processed separately, it still thinks we are running at 100%, so periodically it will have to stop to let the game catch with the sound. In order to force sound to also sync with our rendering speed, we need to enable the -soundsync option. Obviously this only can be achieved by modifying its frequency by the same factor, so there will be a clear difference in pitch. But this is the only possible and less bad thing you can do if you really want have perfect scrolls without sound stuttering when your refresh doesn't match the game's fps.
If you really can't bear with the slow down or it's too bad for a particular game, then there's still a way you can have your game run at 100% without any tearing: the -triplebuffer option. As we'll run at the original speed, we don't need any sound trick here. Of course, there is a catch: tearing is removed as triplebuffer enables page flipping, but we won't have perfect scrolls any more, as the game action will not be synchronized with our vertical refresh. Page flipping however is still synchronized to vertical retrace, that's why tearing doesn't happen.
Depending on the game -triplebuffer method will be better than the other, so for pacman it's good as there's no scrolling and -syncrefresh would affect its speed badly, but for 1942 you'll notice the scroll has some small hiccups, which you can tolerate or not. Triplebuffering (as it's currently done in Mame/GroovyMame) has an additional drawback: it will add some input lag. However, this won't be so bad if you always use -multithreading (on by default). That's why for gameplay,-triplebuffer is less desirable than -syncrefresh.
If you enable -triplebuffer, then -syncrefresh is automatically disabled, so you if you enable both of them only -triplebuffer will be used. If you are going to use -triplebuffer for some game, it's a good idea to create an ini for it so you don't use that option all the time.
You may wonder what's -waitvsync used for now. In GroovyMame, -waitvsync is used internally by the program, so any value that you set to this option will be overriden. So, if you leave the options by default, -waitvsync will be enabled/disabled internally to perform synchronization when required. By enabling -syncrefresh, what you do is to tell GroovyMame to always force -waitvsync, whatever the refresh is. (Notice that in regular Mame, -syncrefresh/-waitvsync are exactly the same option, they do the same, as the mainstream code is implemented).
Now, back to the monitor type option, if you are positive your monitor accepts a wider range of frequencies than the default "cga" template, you can either choose some of the predefined monitors or create your custom settings that fit your particular monitor. There is a potencial risk to damage your monitor when messing with this stuff, it's never bad to remind this.
So, what I do is to choose my model: h9110. With this monitor, I have a way wider range than using the cga one, so I'll be able to generate i.e. 400x256@60Hz modeline, and thus run 1942 at 100% without forcing things. As you see, usually the monitor option is what most directly affects final game speed (if we want to sync to vertical retrace), and most issues with stuttering sound are produced by trying to sync to wrong refresh rates rather than needing more cpu power.
Finally, there some games that really are too much for our cpu: most 3D games for instance. The problem here is that usually, the right refresh is achieved, so GroovyMame will automatically enable -waitvsync. By doing this, our fps can be dramatically cut off by 50%, because most of our cpu time is wasted just waiting for vertical retrace. Again, the -triplebuffer option comes in handy here, as it will revert the -waitvsync mechanism and let the game engine run freely while our frames are flipped independently at the refresh speed. As GroovyMame has no way to guess if your cpu is going to be enough for a given game, -triplebuffer here needs to be added manually by you when required.
-
His CPU is only single core, so multithreading isn't really going to work that well.
-
His CPU is only single core, so multithreading isn't really going to work that well.
Multithreading has been there much longer than dual core processors have existed, it will work fine :)
However, I'm now seeing a problem with the new implementation of -triplebuffer, a small but annoying flash that covers just some lines. It just happens here when I set the monitor type to 'cga', 'pal' or 'ntsc', that's why I hadn't seen it before. I'll try to find a fix for it.
-
I installed drivers and ran Arcade_OSD. I stepped through each resolution available in the list (using <- and ->) and pressed enter when it displayed correctly.
I accidentally selected one of the higher res' which causes an instant blue screen, how do I un-select that video mode?
Also, I run an older ArcadeVGA via a J-PAC and when I tested some of the games they give me a much smaller, squashed version of the games that looked fine before. This was mainly in vertical games though. But I tried a horizontal shooter (Side Arms) and it does not full screen and looks quite squashed.
I have a 26" monitor, so vertical games squeezed still look pretty good. I downloaded GroovyMAME to solve some of the tearing in some of my favourite games. But if I am relatively happy with D3D and hwstretch, I should stick with it?
-
Further to my previous comments, I cannot run any MAME games, either with groovymame or regular mame. As soon as the game loads, it immediately blue-screens and reboots. I've uninstalled the CRT_emudrivers and reinstalled the ArcadeVGA ones but now have exactly the same results. It's getting late and I'll have to get back to it tomorrow. I'm sure I'll be able to return it to working order but currently any change in resolution - whether a game or just switching MAMEWah themese will blue-screen the PC.
-
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.
-
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??
-
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.
-
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.
-
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?
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.
-
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.
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.
-
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.
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?
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.
-
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.
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
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.
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.
-
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 (http://www.ultimarc.com/cat-uninstaller.exe)
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.
-
Ok i have downloaded, groovymame32_0142.012o.exe from http://mame.groovy.org/0142/. (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?
-
Ok i have downloaded, groovymame32_0142.012o.exe from http://mame.groovy.org/0142/. (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).
-
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?
-
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.
-
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
-
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).
-
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.
-
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.
-
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......
-
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?
-
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 (http://mamedev.org/source/docs/config.txt.html)
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).
-
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.
-
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)
-
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...
-
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.
-
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.
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.
-
Never mind my ranting about ini file parsing. It must have been user error on my part because it's working now.
-
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..
-
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
-
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?
-
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??
-
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.
-
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?
-
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.
-
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).
-
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
-
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?
-
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).
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.
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.
-
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.
-
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 (http://www.flashingblade.net/?page_id=270). 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)
<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?
-
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....
(http://img92.imageshack.us/img92/916/img1912cs4.jpg)
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 (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 :(
-
Remind waitvsync is now managed internally by GroovyMame, so whatever you set there will be overriden.
That doesn't seem to be the case when you force a custom resolution in GroovyMAME from an ini. I'll do some experiments tonight to make sure.
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.
The problem isn't specific to MAME, 640x480 looks awful when displaying the windows desktop as well.
There's probably something wrong with my monitor. When running 640x480 it looks like the alignment of the two interlaced passes are several scanlines off. It's most visible in games like Asteroids due to the high contrast.
800x600 looks equally as bad, plus it folds over in the upper left corner and no amount of monitor adjusting fixes it.
On the other hand, 720x480 looks so good, it's almost hard to tell that it's interlaced at all.
I'll have to get some close-up pictures of of the screen so you can see what I'm talking about.
I could try running my ATI HD 4550 with Calamity's custom drivers to see if it looks the same, just to rule out the ArcadeVGA3000 or it's drivers.
What I should probably do is remove 640x480 as one of the available resolutions, that way GroovyMAME will (hopefully) pick 720x480 instead.
-
Its a Pentranic tri sync monitor (UK company), i bought the monitor brand new and this is the test screen from SF3....
I see. I'm have no knowledge on electronics so have no clue if that could be a hardware problem on your monitor. Does it happen with any video mode exactly the same? Anyway, I'd try to add more margins to the picture by software, and then compensate the borders back by opening a bit the horizontal amplitude potenciometer. Can't promise anything but that could help. To do that try a custom monitor_specs line, increasing the horizontal front porch mainly (right margin). Have a search through this thread to find an explanation on this. However be aware I've read scary stories of Pentranic monitors breaking when being set to an improper resolution!
-
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?
Yeah, those vertical games with 256 lines (halleys, 1942) are above the limit where a normal cga monitor can do 60 Hz. That's because in order to achieve 60 Hz with so many lines you need a 16.7 KHz modeline, and our monitor definition for cga is restricted to 15.7 KHz, so the maximum refresh you can get for 256 active lines is 56,68 Hz. So, you can choose one of this options:
- Remove -triplebuffer and -syncrefresh (what you did), so GroovyMame will run the emulation independent of your videocard refresh, speed will be 100%, sound will be perfect, but you'll have tearing. However tearing is not so noticeable in vertical games as it is in horizontal scrolling games.
- Add -syncrefresh. GroovyMame will reduce game's speed to 94%. No tearing, perfect scroll. Sound stuttering due to speed difference, solution: add soundsync too, so sound will sync to video at the cost of lowering its pitch.
- Add -triplebuffer. Groovymame will keep game's speed at 100%. No tearing, perfect sound, but scroll hiccups, due to game speed being different to videocard's refresh (note: adding triplebuffer actually overrides -syncrefresh so there's no point in activating both of them).
- Use another monitor type (at your own risk). For instance, Hantarex MTC 9110 (H9110) can go up to 16.7 KHz, so by choosing this monitor GroovyMame will be able to generate a 256 lines@60Hz modeline, so you won't need -syncrefresh/-triplebuffer as Groovymame will internally activate -waitvsync.
A quick, easy and force brute way to have GroovyMame set up so that any game runs smooth without video/sound artifacts is by enabling the syncrefresh + soundsync combo. So for the games that fall out of our monitor limits, you'll have a slowdown but everything will be smooth like silk apart from that.
If you leave the default options (-nosyncrefresh, -notriplebuffer), GroovyMame will only activate -waitvsync when it feels it's convenient.
So for those games it depends on your taste that you prefer smooth-but-somewhat-slowdown vs real-speed-but-tearing/hiccups, and also depending on the game it may be better or worse.
It would be good at some point to have an ui menu option for enabling/disabling -syncrefresh/-triplebuffer, I'll have a look at that.
Also, bit strange but I can't get the paths in mame.ini to display bezels or overlays.
No idea on this, sorry.
-
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?
I don't believe that you can use bezels with an arcade monitor. However, overlays and backdrops should be OK as long as you use artwork crop.
I haven't tried enabling artwork with any recent versions of MAME on my arcade monitor, so I'm not 100% sure that artwork still works with ddraw. I'll play around with it this weekend if I get a chance.
-
When running horizontal scrolling games I notice a horizontal line, below which the screen is 1 or 2 pixels behind in scrolling. The position of this horizonal line seems random. Sometimes it is in the upper half of the screen, other times it's in the lower part.
This is especially noticable in Shinobi, but also in other games, e.g. the second level of Ghosts'n'Goblins.
My settings: syncscreen 1, waitsync 0, tripplebuffer 0, soundsync 1.
I am using the latest version of Groovymame.
Any ideas?
Thanks
-
When running horizontal scrolling games I notice a horizontal line, below which the screen is 1 or 2 pixels behind in scrolling. The position of this horizonal line seems random. Sometimes it is in the upper half of the screen, other times it's in the lower part.
This is especially noticable in Shinobi, but also in other games, e.g. the second level of Ghosts'n'Goblins.
My settings: syncscreen 1, waitsync 0, tripplebuffer 0, soundsync 1.
I am using the latest version of Groovymame.
Any ideas?
Thanks
Hi blagger, that's probably the tearing artifact. Make sure you use -syncrefresh ("syncscreen" does not exist). If that doesn't make a change, run "dxdiag" and in the screen tab, check if DirectDraw acceleration is enabled, if it's not then your display drivers are not properly installed.
-
Hi Calamity, thanks for your answer.
yeah, sorry I meant syncrefresh.
I checked DirectDraw acceleration. It is enabled.
-
Hi Calamity, thanks for your answer.
yeah, sorry I meant syncrefresh.
I checked DirectDraw acceleration. It is enabled.
blagger, rereading your previous posts I remind you were using clone mode, isn't it? Try disabling it and only use your primary device for testing. I think that could be the issue.
-
I just checked again:
I ran Shinobi with both monitors turned on. I had this tearing artefact on my horizontal monitor, but no tearing on my vertically mounted monitor.
Then I disabled clone mode and now no tearing on my horizontal monitor.
This tearing artefact is a bit random, but I checked several times and there was no tearing.
Then I enabled clone mode again and now no tearing on both monitors. I rebooted my system and checked several times and the tearing seems to have disappeared. Strange, but I am not complaining.
If the tearing appears again I will let you know.
Thanks for your help.
-
Its a Pentranic tri sync monitor (UK company), i bought the monitor brand new and this is the test screen from SF3....
I see. I'm have no knowledge on electronics so have no clue if that could be a hardware problem on your monitor. Does it happen with any video mode exactly the same? Anyway, I'd try to add more margins to the picture by software, and then compensate the borders back by opening a bit the horizontal amplitude potenciometer. Can't promise anything but that could help. To do that try a custom monitor_specs line, increasing the horizontal front porch mainly (right margin). Have a search through this thread to find an explanation on this. However be aware I've read scary stories of Pentranic monitors breaking when being set to an improper resolution!
Thanks for the info, i looked back through the thread but could see any info on increasing the horizontal fron porch, can you give me a quick guide on how to do this for say Robocop?? Also what monitor would be best for me to select in the ini file as there is no Pentranic monitor in the list?
-
Calamity, I made some further tests:
I had tearing on the horizontal monitor and no tearing on the vertical monitor. Then in CCC I used the option "swap display mapping" and now its the other way round, tearing on the vertical and no tearing on the horizontal. This is reproducible.
So it seems that the secondary screen has sync problems.
-
Calamity,
I was trying to experiment with a non ArcadeVGA ATI card (Sapphire ATI HD 4550) with your custom drivers. I uninstalled all the ATI drivers, and ran cat uninistaller to make sure before trying to install your drivers. However at the end of the install, I got the error message "Error Copy file failed" in the attached screenshot. Any idea what happened? The drivers seemed to have installed otherwise.
EDIT: Some additional observations...
1) I am REALLY impressed. Every game I tried looks fantastic, even interlaced games. Wow! Just, Wow. You should work together with Andy @ Ultimarc. With his custom BIOS and low dot clock hardware, and your drivers, the results would be amazing.
2) Hyperspin no longer works. I installed crt_emudriver_9.3_1.2_x64_multisync.rar, which I thought was pre-configured to be under the Hyperspin limit. Is there something I have to do manually to get Hyperspin working again?
-
You should work together with Andy @ Ultimarc. With his custom BIOS and low dot clock hardware, and your drivers, the results would be amazing.
Unfortunately this has been refused, I tried, but he's afraid that it could leak out proprietary information about how the AVGA3000 operates and could endanger his business. It would be awesome to combine the AVGA3000 bios ability to do the modelines internally and use the modeline generator method of Calamity's, put the logic of groovymame in there too, interface directly with mame. I really think that could be awesome, but it'd be a change in what Andy has told me through talking to him about such things, so far it has been a not possible to do request.
-
Calamity, I made some further tests:
I had tearing on the horizontal monitor and no tearing on the vertical monitor. Then in CCC I used the option "swap display mapping" and now its the other way round, tearing on the vertical and no tearing on the horizontal. This is reproducible.
So it seems that the secondary screen has sync problems.
Interesting, so they are still in clone mode, aren't they? Yes, it seems harware acceleration (and thus vsync) is only possible for the primary device when in that mode. You may try to set each screen as an independent desktop (without CCC), just from screen/properties, extend desktop. Then manually target each one from Mame using the resolution0/resolution1 args instead of default "resolution", and see what happens. There's no way this can be done automatically with GroovyMame as it is now but will give us an idea of how that works.
-
Calamity,
I was trying to experiment with a non ArcadeVGA ATI card (Sapphire ATI HD 4550) with your custom drivers. I uninstalled all the ATI drivers, and ran cat uninistaller to make sure before trying to install your drivers. However at the end of the install, I got the error message "Error Copy file failed" in the attached screenshot. Any idea what happened? The drivers seemed to have installed otherwise.
Oh, no idea what that could be... did you see it copying files for both devices? Just to make sure drivers are properly installed run Arcade_OSD, and check the total number of custom modes (number between (), should be >= 60). I wish driver installation was a cleaner subject in Windows.
EDIT: Some additional observations...
1) I am REALLY impressed. Every game I tried looks fantastic, even interlaced games. Wow! Just, Wow. You should work together with Andy @ Ultimarc. With his custom BIOS and low dot clock hardware, and your drivers, the results would be amazing.
Good news are your monitor is fine with interlaced modes it seems. Well, if AVGA3000 is eventually supported by PowerStrip we could achieve this by directly feeding it with our custom modelines from GroovyMame.
2) Hyperspin no longer works. I installed crt_emudriver_9.3_1.2_x64_multisync.rar, which I thought was pre-configured to be under the Hyperspin limit. Is there something I have to do manually to get Hyperspin working again?
Yes, probably I need to edit the readme in the GroovyMame site. With the 6.5 XP32 version HS did work when reducing the total modes to 160 or so, but it was because at the same time it blocked all driver's native modes, so the total amount of modes was controlled. These 9.3 versions keep custom modes below 120 so at the beginning I thought it would be good enough to keep Hyperspin working but it turns out that hundreds of native modes are still created that add up to the custom ones so the total number is too big it seems, and I can do nothing to block those (have tried). Hopefully HS 2.0 will fix this issue. Actually I don't know if they might be using some sort of commercial library to deal with graphics that could be responsible for this issue, because if it's in their code it wouldn't be too hard to fix it, I could even help them.
-
Calamity,
However at the end of the install, I got the error message "Error Copy file failed" in the attached screenshot. Any idea what happened? The drivers seemed to have installed otherwise.
Oh, no idea what that could be... did you see it copying files for both devices? Just to make sure drivers are properly installed run Arcade_OSD, and check the total number of custom modes (number between (), should be >= 60). I wish driver installation was a cleaner subject in Windows.
I saw a bunch of stuff copying, but I only saw the error popup once at the very end of the install. In a possibly related note, I ALSO saw the same popup when I uninstalled your drivers and re-installed the Ultimarc drivers after swapping in my ArcadeVGA3000. Every time I install either set of ATI drivers, I get the error, so there must be an in-use locked file that is common to both driver sets. I wish the error message was a little more descriptive.
I'm not the only person seeing this error. These threads all mention it...
http://forums.amd.com/game/messageview.cfm?catid=279&threadid=109828 (http://forums.amd.com/game/messageview.cfm?catid=279&threadid=109828)
http://hardforum.com/showthread.php?p=1031133688 (http://hardforum.com/showthread.php?p=1031133688)
http://www.rage3d.com/board/showthread.php?p=1333730933 (http://www.rage3d.com/board/showthread.php?p=1333730933)
http://forums.guru3d.com/showthread.php?p=2396344 (http://forums.guru3d.com/showthread.php?p=2396344)
Also, something to note is that I didn't always see it. I don't think it showed up until I uninstalled and reinstalled drivers a few times.
Every game I tried looks fantastic, even interlaced games.
Good news are your monitor is fine with interlaced modes it seems.
The truly weird thing is that 640x480 interlaced looks great on my ArcadeVGA3000 as long as I don't install any drivers. As soon as I install the drivers, it looks crappy. Andy suggested that I try fiddling with the Ultimarc ArcadePerfect Utility to see if I can make it look better.
Is there any information that can be obtained by using Arcade_OSD that might explain why 640x480 looks good without drivers, but bad with drivers?
Hyperspin no longer works.
Hopefully HS 2.0 will fix this issue. Actually I don't know if they might be using some sort of commercial library to deal with graphics that could be responsible for this issue, because if it's in their code it wouldn't be too hard to fix it, I could even help them.
There doesn't seem to be a lot of information about this issue over on the HS forum. Maybe they need a high-profile thread to draw attention to the problem. You should start a thread over there documenting the issue and then every time someone on BYOAC encounters the issue, direct them to post on the HS thread to bump it to the top.
-
I saw a bunch of stuff copying, but I only saw the error popup once at the very end of the install. In a possibly related note, I ALSO saw the same popup when I uninstalled your drivers and re-installed the Ultimarc drivers after swapping in my ArcadeVGA3000. Every time I install either set of ATI drivers, I get the error, so there must be an in-use locked file that is common to both driver sets. I wish the error message was a little more descriptive.
I'm not the only person seeing this error. These threads all mention it...
http://forums.amd.com/game/messageview.cfm?catid=279&threadid=109828 (http://forums.amd.com/game/messageview.cfm?catid=279&threadid=109828)
http://hardforum.com/showthread.php?p=1031133688 (http://hardforum.com/showthread.php?p=1031133688)
http://www.rage3d.com/board/showthread.php?p=1333730933 (http://www.rage3d.com/board/showthread.php?p=1333730933)
http://forums.guru3d.com/showthread.php?p=2396344 (http://forums.guru3d.com/showthread.php?p=2396344)
Also, something to note is that I didn't always see it. I don't think it showed up until I uninstalled and reinstalled drivers a few times.
Oh thanks for the info, so the issue is not exclusive of my patched drivers. Probably a workaround would be to install/uninstall starting in Safe Mode, so no drivers are loaded and thus no file should be in use.
The truly weird thing is that 640x480 interlaced looks great on my ArcadeVGA3000 as long as I don't install any drivers. As soon as I install the drivers, it looks crappy. Andy suggested that I try fiddling with the Ultimarc ArcadePerfect Utility to see if I can make it look better.
Is there any information that can be obtained by using Arcade_OSD that might explain why 640x480 looks good without drivers, but bad with drivers?
That is probably because before you install drivers it's using a different modeline from its bios. I don't know how AVGA3000 actually works, but that would suggest the drivers add new modelines or at least pick different ones from the bios? According to Andy AVGA3000 does not use registry modelines that are the ones Arcade_OSD can read and edit, like Soft-15Khz, so I think I'd try modifying it with ArcadePerfect, probably changing its vertical geometry or vertical refresh a little bit (it would be great if ArcadePerfect accepted raw modelines as an option for advanced users, but it's not the case).
There doesn't seem to be a lot of information about this issue over on the HS forum. Maybe they need a high-profile thread to draw attention to the problem. You should start a thread over there documenting the issue and then every time someone on BYOAC encounters the issue, direct them to post on the HS thread to bump it to the top.
I wrote a pm to BadBoyBill with the info on the possible bug and got his answer, so maybe opening a thread could be a bit too much, don't know, possibly you're right. Actually I'm finding the most unexpected obstacle with this specific frontend to "persuade" people using crt_emudriver :-\
-
There doesn't seem to be a lot of information about this issue over on the HS forum. Maybe they need a high-profile thread to draw attention to the problem. You should start a thread over there documenting the issue and then every time someone on BYOAC encounters the issue, direct them to post on the HS thread to bump it to the top.
I wrote a pm to BadBoyBill with the info on the possible bug and got his answer, so maybe opening a thread could be a bit too much, don't know, possibly you're right. Actually I'm finding the most unexpected obstacle with this specific frontend to "persuade" people using crt_emudriver :-\
I'm pretty sure they're using Adobe FLEX + Adobe AIR (http://www.adobe.com/products/air/develop/flex/) to develop Hyperspin. I think there's some free development tools. It might be beneficial to work up a small test application to see if we can reproduce the bug. Maybe if it's an Adobe bug, we can get it fixed on their end.
As a side note: Does the same problem also exist with the Catalyst 6.5 drivers? If not, I could try to dig up an older Radeon that is compatible with the 6.5 drivers.
-
I'm pretty sure they're using Adobe FLEX + Adobe AIR (http://www.adobe.com/products/air/develop/flex/) to develop Hyperspin. I think there's some free development tools. It might be beneficial to work up a small test application to see if we can reproduce the bug. Maybe if it's an Adobe bug, we can get it fixed on their end.
Ah, interesting, I'll have a look at that, maybe testing another app built on that software might give us a clue.
As a side note: Does the same problem also exist with the Catalyst 6.5 drivers? If not, I could try to dig up an older Radeon that is compatible with the 6.5 drivers.
Yes we have the same problem with 6.5, but at least there it can be solved by defining only around 160 custom modes, that anyway is more of what you can get with 9.3 (120), so if you're not planning on using any non-Mame 3D game like SF IV or so, it's a better solution and my advice to everybody to go for a R9250 or even a X300 which I've both tested and work great.
-
I'm pretty sure they're using Adobe FLEX + Adobe AIR (http://www.adobe.com/products/air/develop/flex/) to develop Hyperspin. I think there's some free development tools. It might be beneficial to work up a small test application to see if we can reproduce the bug. Maybe if it's an Adobe bug, we can get it fixed on their end.
What would lead you to think that? I wasn't aware you could run AIR applications without the air framework installed. Hyperspin runs without the Air runtime.
-
What would lead you to think that? I wasn't aware you could run AIR applications without the air framework installed. Hyperspin runs without the Air runtime.
I could be totally wrong. I remember reading somewhere that Hyperspin was using flash. Do you know of any other way to get a flash based application running as a standalone app?
-
The truly weird thing is that 640x480 interlaced looks great on my ArcadeVGA3000 as long as I don't install any drivers. As soon as I install the drivers, it looks crappy. Andy suggested that I try fiddling with the Ultimarc ArcadePerfect Utility to see if I can make it look better.
That is probably because before you install drivers it's using a different modeline from its bios. I don't know how AVGA3000 actually works, but that would suggest the drivers add new modelines or at least pick different ones from the bios?
I figured out what the problem is with interlaced resolutions with my ArcadeVGA3000.
For both 640x480 and 800x600, the default vertical size is an odd number. If I load
ArcadePerfect and simply bump the vertical size up +1, it looks great.
For example, when I loaded windows without any drivers installed and ran ArcadePerfect,
the vertical size on the default 640x480 was 436, which has normal interlace flicker on
thin horizontal lines, but otherwise looks good.
After installing the drivers, when I run ArcadePerfect, the vertical size on 640x480 is
435 and it makes my eyes bleed. Bump it up once to 436 and it looks good, just like the
non-driver display.
Similarly 800x600 has the same problem. After installing the drivers, the vertical
height is 573 and looks terrible. Bumping it up one to 574 makes it look good.
I didn't check 720x480, but it looks good out of the box, so I'll bet that the vertical
height is an even number.
It seems that within a reasonable range, all the even heights look good, and all the odd
heights look terrible. It kind of makes sense that the height would have to be an even
number so that it can draw half of the lines on one pass and half on the next.
I've sent this off to Andy to see if he has any thoughts.
-
Good news then!
It seems that within a reasonable range, all the even heights look good, and all the odd
heights look terrible. It kind of makes sense that the height would have to be an even
number so that it can draw half of the lines on one pass and half on the next.
Well, it's actually the opposite for sure: interlaced resolutions need an *odd* number of total lines. If you see our modeline algorithms that's exactly what we're doing. That's why TV standards NTSC/PAL are 525/625 lines, so each field has 262.5/312.5 lines, and it's actually that half line at the end what makes each field have the correct relative displacement so it looks good.
It sounds weird that 640x480 has a "vertical size" of 436 (it should be 480+some_odd_number_of_blanking_lines), so I don't know what that figure exactly means but what is clear to me is that by making it even, you are getting an odd number of total lines even if its hidden.
-
Calamity,
So I am impressed big time with GroovyMame.. It solved a long time problem of getting games to play without tearing. I am limited to a multisync PAL/NTSC tv via svideo (no-RGB input).
Everything looks great but I have found some games (Carrier Air Wing) that seem very squished into a letterbox format. It's almost looks like when you are running a 3 monitor game on a single 4:3 monitor?
Any ideas, my INI file is below.
Video of gameplay in mame link below
http://www.flickr.com/photos/30329886@N08/5729797142/#secret2d395be420 (http://www.flickr.com/photos/30329886@N08/5729797142/#secret2d395be420)
<UNADORNED0>
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
rompath roms;E:Arcade.SATAchds
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 1
use_backdrops 1
use_overlays 1
use_bezels 1
#
# 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 1
joystick 1
lightgun 1
multikeyboard 0
multimouse 1
steadykey 0
offscreen_reload 1
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 mouse
lightgun_device lightgun
positional_device keyboard
mouse_device mouse
#
# CORE DEBUGGING OPTIONS
#
log 1
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 5
monitor vga
monitor_connector auto
monitor_orientation horizontal
monitor_aspect 4:3
monitor_debug 0
monitor_doublescan 0
monitor_dotclock 0
monitor_ymin 0
soundsync 1
cleanstretch 1
changeres 0
redraw 2
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
-
Everything looks great but I have found some games (Carrier Air Wing) that seem very squished into a letterbox format. It's almost looks like when you are running a 3 monitor game on a single 4:3 monitor?
Try disabling the -cleanstretch option, actually that one should not be used togeterh with -video ddraw.
If it doesn't work post the game's log using -v -md 4 args, so we can see which resolution it's choosing.
-
I am limited to a multisync PAL/NTSC tv via svideo (no-RGB input).
Everything looks great but I have found some games (Carrier Air Wing) that seem very squished into a letterbox format. It's almost looks like when you are running a 3 monitor game on a single 4:3 monitor?
Try disabling the -cleanstretch option, actually that one should not be used togeterh with -video ddraw.
If it doesn't work post the game's log using -v -md 4 args, so we can see which resolution it's choosing.
He said that he's using NTSC/PAL SVIDEO, so shouldn't he be using D3D with hwstretch (and possibly cleanstretch)?
-
He said that he's using NTSC/PAL SVIDEO, so shouldn't he be using D3D with hwstretch (and possibly cleanstretch)?
-hwstretch is ddraw specific.
-cleanstretch is a patch originally done by Sailorsat to be used with d3d. If you're using ddraw you shouldn't need this one. Actually it affects scaling and is probably the issue he's seeing.
Probably S-Video signal is being resampled by the videocard or something like that, so actually I'd avoid resolution switching at all by disabling switchres and use d3d instead of ddraw, and then use -syncrefresh or -triplebuffer to remove tearing.
-
Well, it's actually the opposite for sure: interlaced resolutions need an *odd* number of total lines. If you see our modeline algorithms that's exactly what we're doing. That's why TV standards NTSC/PAL are 525/625 lines, so each field has 262.5/312.5 lines, and it's actually that half line at the end what makes each field have the correct relative displacement so it looks good.
It sounds weird that 640x480 has a "vertical size" of 436 (it should be 480+some_odd_number_of_blanking_lines), so I don't know what that figure exactly means but what is clear to me is that by making it even, you are getting an odd number of total lines even if its hidden.
Yeah, it turns out that the vertical size listed in ArcadePerfect is some sort of relative geometry and not the actual number of lines. However, Andy has confirmed that I was correct in my diagnosis of the problem. He has updated the Windows XP x64 drivers so that both 640x480 and 800x600 are bumped up one "unit" and now look the way they should. 640x480 looks exactly the same, with and without drivers installed, and 800x600 is actually quite usable on my monitor now when I need the extra space. I'm not sure if any of the other drivers were affected or updated.
-
Hyperspin is not using Adobe Flex + AIR.
I'm pretty sure they're using a product called SWF Studio
I found the string "SWF Studio" in the hyperspin exe file.
Here's where you get it...
http://www.northcode.com/ (http://www.northcode.com/)
There's a free trial version, a $49 student version, and a $299 professional version.
Supposedly, the free trial version creates executables that stop working 1 day after they are run for the first time, but otherwise, it's the same as the full version.
I'd be curious if a small app built with the trial version will run with Calamity's patched drivers installed.
-
ok So I love this version of mame but am having a few issues depending on the card I use. When I use my AVGA 3000 with this a few resolutions dont work right. Tmnt wont fill the screen no matter what and mortal kombat wont run at at the correct refresh, however neogeo and capcom games look and play amazing. when I use my built in radeon 2100 with he custom drivers mortal kombat runs perfect but many games like joust and capcom games dont work. I am debating buying a better ATI card but would like some conformation on which one to use and if anyone uses a particular card what works and what dosnt I was thinking like a radeon hd3xxx or 4xxx. Thoughts?
-
ok So I love this version of mame but am having a few issues depending on the card I use. When I use my AVGA 3000 with this a few resolutions dont work right. Tmnt wont fill the screen no matter what and mortal kombat wont run at at the correct refresh, however neogeo and capcom games look and play amazing. when I use my built in radeon 2100 with he custom drivers mortal kombat runs perfect but many games like joust and capcom games dont work. I am debating buying a better ATI card but would like some conformation on which one to use and if anyone uses a particular card what works and what dosnt I was thinking like a radeon hd3xxx or 4xxx. Thoughts?
I'm using an AVGA 3000. I'll have to check out TMNT and Joust tonight when I get home. What Capcom game(s) are you having issues with? Be specific and I'll check those out too.
EDIT: TMNT and Joust are perfectly fine on my AVGA 3000. Did you delete your old mame.ini and game-specific ini files before testing GroovyMAME?
As for the refresh issues in Mortal Kombat, are you having problems with the sound? Make sure you enable "soundsync" in your INI file. The Mortal Kombat games work great on my system.
What operating system are you using? Is your CPU powerful enough for the games you're trying to run?
As for another card choice, if you plan on using Hyperspin as your front-end software, you probably want to pick up a used Radeon X1300 based card off of Ebay (they're really cheap) and use Calamity's patched Catalyst 6.5 drivers. Until they fix the bug in Hyperspin, that's probably the best you can do.
-
ok So I love this version of mame but am having a few issues depending on the card I use. When I use my AVGA 3000 with this a few resolutions dont work right. Tmnt wont fill the screen no matter what and mortal kombat wont run at at the correct refresh, however neogeo and capcom games look and play amazing. when I use my built in radeon 2100 with he custom drivers mortal kombat runs perfect but many games like joust and capcom games dont work. I am debating buying a better ATI card but would like some conformation on which one to use and if anyone uses a particular card what works and what dosnt I was thinking like a radeon hd3xxx or 4xxx. Thoughts?
What happens exactly with those capcom games that don't work? All games should work, at least load and run although their resolution is wrong, unless there's something else going on. Post a log using -v -md 4 args so we can have a look. Use Arcade_OSD to check your installed resolutions and see if all of them are working properly.
-
As for another card choice, if you plan on using Hyperspin as your front-end software, you probably want to pick up a used Radeon X1300 based card off of Ebay (they're really cheap) and use Calamity's patched Catalyst 6.5 drivers. Until they fix the bug in Hyperspin, that's probably the best you can do.
The ATI X family is well known for not accepting low dotclocks, with the exceptions of the most older models (x300 at least). There is a workaround with the dotclockmin option both in crt_emudriver/groovymame that basically doubles xres for the lower resolutions... I'm thinking that's the issue androtaz08 is probably seeing as it's probably the same with HD 2000/ HD 3000. On the other hand, HD 4000 work fine on this aspect.
-
The ATI X family is well known for not accepting low dotclocks, with the exceptions of the most older models (x300 at least).
It might be useful to have some specific recommended models on your driver download page so people know what to look for.
So far, the two issues I've seen are Hyperspin compatibility and low dot-clock support. Are there any others that you know of?
-
My ATI X800 has worked just fine with anything, including custom modes, Soft15 has thrown at it.
-
ok So I love this version of mame but am having a few issues depending on the card I use. When I use my AVGA 3000 with this a few resolutions dont work right. Tmnt wont fill the screen no matter what and mortal kombat wont run at at the correct refresh, however neogeo and capcom games look and play amazing. when I use my built in radeon 2100 with he custom drivers mortal kombat runs perfect but many games like joust and capcom games dont work. I am debating buying a better ATI card but would like some conformation on which one to use and if anyone uses a particular card what works and what dosnt I was thinking like a radeon hd3xxx or 4xxx. Thoughts?
ok so I reinstalled my AVGA 3000 tonight and tested some stuff out. turns out my issue with tmnt was that i had mame set to use artwork. now that works great. However the mortal kombat games are still making me scratch my head. I have sound sync enabled but there is sometimes a really noticeable slowdown in pitch. when I used my ati 2100 the game ran perfect at 54.8 hz, no slowdown or tearing. the AGVA runs that resolution at 53.2. So the questions I have are
1 Is there a way to force the AGVA to run at 54.8 instead of 52.3?
2 When using the slider controls to shift the refresh rate down from 54. to 52.7 I notice less sound slowdown, is that what other people do?
3 Which is the correct refresh and why does Andy's card do 52.3?
-
ok so I reinstalled my AVGA 3000 tonight and tested some stuff out. turns out my issue with tmnt was that i had mame set to use artwork. now that works great. However the mortal kombat games are still making me scratch my head. I have sound sync enabled but there is sometimes a really noticeable slowdown in pitch. when I used my ati 2100 the game ran perfect at 54.8 hz, no slowdown or tearing. the AGVA runs that resolution at 53.2. So the questions I have are
1 Is there a way to force the AGVA to run at 54.8 instead of 52.3?
2 When using the slider controls to shift the refresh rate down from 54. to 52.7 I notice less sound slowdown, is that what other people do?
3 Which is the correct refresh and why does Andy's card do 52.3?
I've played the hell out of the MK series on my AVGA3000 and I don't notice any slowdown, tearing, or pitch issues.
I'm using the stock INI file from GroovyMAME with soundsync enabled. Did you create a fresh INI file before you started testing GroovyMAME?
What are these "slider controls" you mention?
Can you try running the following from the command line in your MAME directory?...
groovymame -v -md 4 umk3 > umk3_log.txt
...then post the log file here so we can look at it.
-
I dont know how to do that as I am running groovymame from maximus arcade
-
Trying GM out for the first time today, Galaxian plays fine but Frogger clips off at the bottom for me.
What resolution should the fixed Frogger run at, do I need to trigger the hack somehow?
Thanks
-
i decided to give GM a try today and xp pro x64, so I loaded up a spare drive with them, and copied over my cab's mame folder set everything up..ect got it working except that some game's will not display at all they just displayed a scrambled screen like as if the monitor isn't capable of outputing that combination of resolution/vsync, all neogeo games did this, so did Kinst,Kinst2 and several other's. Now when i swap video adapter's to my avga3k useing andy's driver's none of this happens, but useing my onboard hd3450 with calamity's driver's it does happen. I'm useing a WG7k series monitor that is a stock MK1 monitor
any idea's? :dunno
-
but useing my onboard hd3450 with calamity's driver's it does happen. I'm useing a WG7k series monitor that is a stock MK1 monitor
Radeon X, HD 2000 and HD 3000 families can't use low dotclocks in Windows. Edit VMMaker.ini and set DotClockMin param to something like 7.010, then run VMMaker to recalculate modelines and restart. That will create double width resolutions for the cases where it's needed. GroovyMame will manage to pick the right modes still and the result should be perfect. Please let us know if it works.
Trying GM out for the first time today, Galaxian plays fine but Frogger clips off at the bottom for me.
What resolution should the fixed Frogger run at, do I need to trigger the hack somehow?
Please post a log using -v -md 4 as arguments, that will help us to know what's going on.
-
Please post a log using -v -md 4 as arguments, that will help us to know what's going on.
groovymame -v -md 4 frogger
Error: unknown option: -md
so I did this:
groovymame -v frogger
and here is the log
http://pastebin.com/D9sDPV5W (http://pastebin.com/D9sDPV5W)
-
Please post a log using -v -md 4 as arguments, that will help us to know what's going on.
groovymame -v -md 4 frogger
Error: unknown option: -md
so I did this:
groovymame -v frogger
and here is the log
http://pastebin.com/D9sDPV5W (http://pastebin.com/D9sDPV5W)
It's the same issue that bent98 reported:
DirectDraw: New blit size = 957x472
Though I haven't managed to reproduce that bug here, I have a test fix that might solve it, don't know, I'm uploading a binary named groovymame32_0142.012o_test, please check if it makes any difference.
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
-
Didn't work I'm afraid, here is the new log.
http://pastebin.com/ESnchU0R (http://pastebin.com/ESnchU0R)
Thanks for checking into this
-
LEt me know if you need me to test something as well
-
but useing my onboard hd3450 with calamity's driver's it does happen. I'm useing a WG7k series monitor that is a stock MK1 monitor
Radeon X, HD 2000 and HD 3000 families can't use low dotclocks in Windows. Edit VMMaker.ini and set DotClockMin param to something like 7.010, then run VMMaker to recalculate modelines and restart. That will create double width resolutions for the cases where it's needed. GroovyMame will manage to pick the right modes still and the result should be perfect. Please let us know if it works.
This worked, nearly every game I've tried has come up "almost" perfectly vertical games have issues, such as 1941,42,43, galaga/galaxian the resolution it picks is to tall, pacman picks a really weird resolution that makes my monitor over-scan at the bottom :dunno.
Gmame+Calamity's driver's are a REALY good solution for those that have a compatible video card, it's a shame though that Hyperspin won't run with it because that is my FE of choice. I'm very disappointed in XP Pro X64 though SF4 will not run on it full-screen it crash's so that's a deal breaker for me, and window's 7 x64 will not let you switch from a scan-line resolution to a non scan-line resolution with Ddraw on. SO I've come to a crossroads.
1. Ditch Window's 7+avga and go to XP Pro x64 using Gmame+calamity+onboard video, and loose SF4 and hyperspin
2. Keep Window's 7+avga+sf4+hyperspin and loose almost perfect game resolution compatibility.
OR
3. Buy a new WG D9000 26" replacement LCD and try that with both setups and my real PCB's and see what happens.... >:D
Seeing how i just love to throw money away on things that I'll never use or am disappointed in I'm going to go with option 3 haha, besides I'm sure alot of people on here want to know about these things and i've got the spare cash to throw at it, lets see what happens.
-
This worked, nearly every game I've tried has come up "almost" perfectly vertical games have issues, such as 1941,42,43, galaga/galaxian the resolution it picks is to tall, pacman picks a really weird resolution that makes my monitor over-scan at the bottom :dunno.
Good. The "issue" with vertical games is because their resolution is being virtualized using as many lines as your monitor is capable of for that given vertical refresh, so that overscan should be possible to be fixed by adjusting your vertical amplitude potenciometer (I do that all the time).
I don't know why SF4 should crash in XP64, have you done a web search on that? Does it have to do with CRT_EmuDriver or just happens all the time?
3. Buy a new WG D9000 26" replacement LCD and try that with both setups and my real PCB's and see what happens.... >:D
Well, if you replace your working CRT with that please make sure not to throw it away :)
You won't need CRT_EmuDriver with a LCD. Just leave it with its default resolution and use -video d3d -noswitchres to make the picture fit the screen. Be aware you'll need to run all games at 60 Hz in order to avoid video artifacts, this means that games like R-Type will run at 109%.
-
This worked, nearly every game I've tried has come up "almost" perfectly vertical games have issues, such as 1941,42,43, galaga/galaxian the resolution it picks is to tall, pacman picks a really weird resolution that makes my monitor over-scan at the bottom :dunno.
Good. The "issue" with vertical games is because their resolution is being virtualized using as many lines as your monitor is capable of for that given vertical refresh, so that overscan should be possible to be fixed by adjusting your vertical amplitude potenciometer (I do that all the time).
I don't know why SF4 should crash in XP64, have you done a web search on that? Does it have to do with CRT_EmuDriver or just happens all the time?
3. Buy a new WG D9000 26" replacement LCD and try that with both setups and my real PCB's and see what happens.... >:D
Well, if you replace your working CRT with that please make sure not to throw it away :)
You won't need CRT_EmuDriver with a LCD. Just leave it with its default resolution and use -video d3d -noswitchres to make the picture fit the screen. Be aware you'll need to run all games at 60 Hz in order to avoid video artifacts, this means that games like R-Type will run at 109%.
SF4 just doesn't like XPro x64 it will run in a window but full screen crashes, and as for the WG lcd from everything I've read and from what I've been told from the sales rep i talked to at happs, it is fully capable of displaying everything an old CRT can, just in a 16:9 format stretched or with pillars. But everywhere I've looked no one has ever bought one to see what it does "not just here but on all other mame/fe forum's i read" I think everyone is assuming it's just a stand LCD panel modified to accept 15khz signals and a r/g/b/g/s input, so they buy a computer LCD because they are WAY cheaper, I would do the same thing, but I own several PCB's MK1 proto 9,MK2,UMK3,bad dudes,sly spy,tekken 3,sf2-sfa2 and few others I can't remember off the top of my head, so a computer LCD is out of the question for me because if the itch should get me i can plug in one of my pcb's and play the real thing. But I also know that this 20 year old CRT isn't going to last forever and getting a replacement is going to be hard/impossible by the time it does go out "it's already got medium Tekken 3 burn in GRRRRR stupid PO", so i figure while I've got the money in pocket I can go ahead and get what will likely be the only option in a few year's, write up a detailed review of it with some pics and video's and do the community a favor.
"edit"
yea no I won't through my CRT away, what will likely happen if this LCD works out ok, I'll either sell it here, give it away or something, I won't let it go to waste
-
SF4 just doesn't like XPro x64 it will run in a window but full screen crashes, and as for the WG lcd from everything I've read and from what I've been told from the sales rep i talked to at happs, it is fully capable of displaying everything an old CRT can, just in a 16:9 format stretched or with pillars. But everywhere I've looked no one has every bought one to see what it does "not just here but on all other mame/fe forum's" I think everyone is assuming it's just a stand LCD panel modified to accept 15khz signals and a r/g/b/g/s input, so they buy a computer LCD because they are WAY cheaper, I would do the same thing, but I own several PCB's MK1 proto 9,MK2,MK3,bad dudes,sly spy,tekken 3,sf2-sfa2 and few others I can't remember off the top of my head, so a computer LCD is out of the question for me because if the itch should get me i can plug in one of my pcb's and play the real thing. But I also know that this 20 year old CRT isn't going to last forever and getting a replacement is going to be hard/impossible by the time it does go out "it's already got medium Tekken 3 burn in GRRRRR stupid PO", so i figure while I've got the money in pocket I can go ahead and get what will likely be the only option in a few year's, write up a detailed review of it with some pics and video's and do the community a favor.
Yeah definitely it will be interesting to see how it behaves with your MK pcbs at 54 Hz, the scrolling character selection screen will be the best test for it.
-
Calamity-
I've been unable to install your drivers on my XP64 machine. I've run the setup several times, as well as attempted to install the drivers manually through the "I have a disk" method from the computer manager.
Using the Setup.exe, there are no error messages, but the device does not start when the machine reboots. Using the "I have a disk" method, at the last screen you get:
An error occurred during the installation of the device
The parameter is incorrect
I have a Radeon HD 4350 and am trying to use the newest 9.3.1.2 x64 drivers from the GroovyMame site.
-
Hi cotmm68030,
Make sure to remove any sort of existing driver before you install. MS default drivers usually need to be uninstalled manually, CatUninstaller doesn't help here. First uninstall Catalyst. Then MS driver will be used. Go to the Device Manager and click in both devices and remove the driver in use. You'll know it's ready when after reboot you have a ? or ! yellow sign on the device meaning Windows has not drivers for it.
-
SF4 just doesn't like XPro x64 it will run in a window but full screen crashes
Make sure you have the latest DirectX installed...
http://www.microsoft.com/downloads/en/details.aspx?familyid=2da43d38-db71-4c1b-bc6a-9b6652cd92a3 (http://www.microsoft.com/downloads/en/details.aspx?familyid=2da43d38-db71-4c1b-bc6a-9b6652cd92a3)
-
Didn't work I'm afraid, here is the new log.
http://pastebin.com/ESnchU0R (http://pastebin.com/ESnchU0R)
Thanks for checking into this
I'm uploading a new groovymame32_0142.012o_test binary, please jimmy2x2x and bent98 check this one to see if it finally fixes the frogger issue.
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
-
Congratulations that man!
I think everything is working now, tested with:
Galaxian
Moon Cresta
Frogger
forced res to 256x240, rotated to vertical and they look great
I think there may be an issue with centering the image with all the border at the top of the play area, besides this minor issue it is working great for me.
MANY THANKS, expect a donation on payday ;)
-
I'm having an issue with Gauntlet Legends (gauntleg).
Important info...
groovymame64_0142.012o
Windows XP x64
ArcadeVGA 3000
standard resolution arcade monitor
I believe that gauntleg should be running at 640x480 interlaced, full screen, but instead, it runs in a small square in the middle of the screen with large borders on all sides. I've attached the log file.
I have all artwork disabled.
-
I'm having an issue with Gauntlet Legends (gauntleg).
Important info...
groovymame64_0142.012o
Windows XP x64
ArcadeVGA 3000
standard resolution arcade monitor
I believe that gauntleg should be running at 640x480 interlaced, full screen, but instead, it runs in a small square in the middle of the screen with large borders on all sides. I've attached the log file.
I have all artwork disabled.
MAME history says 640x480. Especially given the time of release, the type of graphics, and that VGA monitors were becoming common enough in arcade games by that time, I'd suspect they meant it to run 'progressive'.
As you can't do that, then doctor the ini or whatever so that interlace is forced.
-
The problem with that gauntleg game is that after selecting 640x480 it switchres its resolution again to 511x384, and as this second resolution does not exist it tries to virtualize it using system's resolution 800x600, but for some reason stretching does not work this time and the game is rendered as a small 511x384 box in the middle of the screen. I'll have to test that one in my cab, but that won't probably get fixed until bitbytebit back who knows better how that part works.
-
The problem with that gauntleg game is that after selecting 640x480 it switchres its resolution again to 511x384, and as this second resolution does not exist it tries to virtualize it using system's resolution 800x600, but for some reason stretching does not work this time and the game is rendered as a small 511x384 box in the middle of the screen. I'll have to test that one in my cab, but that won't probably get fixed until bitbytebit back who knows better how that part works.
Interesting, I was wondering that, maybe if stretching is invoked upon a resolution change and the original resolution didn't need it, it can't be enabled later?
I need to have some sort of TODO list page, somewhere, that we can have input the things that are needed to be done basically for different stuff. I have spurts of time, or will here in a week or so, where I can do work. Yet if I try to figure out what needs to be done, prioritize and stuff, it turns up taking all the time I have :/. Not sure how to do that best, some sort of post it board somewhere, to keep track of the TODO list would be ideal. I am sure I could come up with some php interface page with some time, any suggestions on this would be great :). Moving has been so much time and work, I had the last week off of work actually and still no extra time, new place is taking that up, still getting stuff out of the old house. At least when I'm settled, things should be good because I have my arcade machine in an awesome place, log cabin home on 10 acres in the country with 2 acre fishing pond. So I should be able to concentrate, and have plenty of stress relievers available around here. Just getting things settled is going to take awhile though, but having a concise TODO list somehow would help and also seems like a few more weeks prolly of me getting settled in. Fortunately mostly things are at a working state, but I really am excited about eventually getting into the detail work of making everything streamlined and the little fixes here and there. I know this Winter I'll be having lots of time to focus again for sure, because I'll probably be stuck indoors, but hopefully I get to it well before then :D.
-
I need to have some sort of TODO list page, somewhere, that we can have input the things that are needed to be done basically for different stuff. I have spurts of time, or will here in a week or so, where I can do work. Yet if I try to figure out what needs to be done, prioritize and stuff, it turns up taking all the time I have :/. Not sure how to do that best, some sort of post it board somewhere, to keep track of the TODO list would be ideal.
There's a few possibilities I can think of...
1) Set up some sort of free web-based bug tracking software like Bugzilla, Mantis, JIRA, etc... I definitely wouldn't try to roll your own.
2) Set up a support forum for GroovyMAME and dedicate one sticky thread to "known issues". You (or an admin/moderator) can then update the first post in the thread with issues as people post them and remove them as they get fixed.
The first is obviously more work to set up, but offers a lot more functionality. The second is easier to set up, and you might even want to ask Saint to make a GroovyMAME specific board here on BYOAC, which would make it virtually painless.
-
Interesting, I was wondering that, maybe if stretching is invoked upon a resolution change and the original resolution didn't need it, it can't be enabled later?
Could be that, I'm not fully sure.
Looking forward to having you back in the forum, take your time and relax, moving is one of the most stressing experiences I can think of :)
There's some new stuff I've been working at in the meanwhile. The version I posted with the frogger fix actually uses an experimental three-threaded method, so it's the first Mame build to implement a fully asynchronous triplebuffer (the other one had some issues), that should be as lag-free as plain throttle or syncrefresh. I'm also doing some tests driving Powerstrip from Arcade_OSD, it's very easy actually although it has some limitations I'm studying.
-
ok I just bought a radeon hd 4350 however when I try to install the emu crt drivers for xp64 I get this error "Thunk.exe Setup did not find a driver compatible with your current hardware or operating system setup will now exit"
I installed the default drivers from the ati site and used soft 15k and mame runs ok. a little bigger than it used to and I can not shrink some games down any. but at least I have my 54.8 refresh rate ok MK again. any ideas?
-
ok I just bought a radeon hd 4350 however when I try to install the emu crt drivers for xp64 I get this error "Thunk.exe Setup did not find a driver compatible with your current hardware or operating system setup will now exit"
Are trying to install the 9.3 x64 drivers?...
http://mame.groovy.org/WindowsATIDrivers/crt_emudriver_9.3_1.2_x64_multisync.rar (http://mame.groovy.org/WindowsATIDrivers/crt_emudriver_9.3_1.2_x64_multisync.rar)
You might want to try uninstalling soft15KHz, uninstall all ATI drivers from "Add or Remove Programs", then run the catalyst uninstaller utility to make sure everything is gone...
http://www.ultimarc.com/cat-uninstaller.exe (http://www.ultimarc.com/cat-uninstaller.exe)
Then re-install the crt emudriver version linked above.
If that doesn't work, make sure that you have the latest chipset drivers installed for your motherboard, and also make sure that any on-board video is disabled, especially if it's ATI based.
-
tried all of that still nothing.
-
I'm currently running groovymame via a nVidia 5200 AGP+soft15k into a UK scart tv, XP 32.
If I buy an ATI card will my setup be able to support to exact refresh rates offered by groovymame+an ATI card?
Do any of the ATI cards on the supported list perform better than others, I wouldn't have thought it would make much difference at such low resolutions..
Thanks
-
tried all of that still nothing.
Hi androtaz08, do you know your card's exact model and vendor? Is it by any chance a "Mobility" version? Is it new or comes from a scrap Dell machine? Please send me the hardware identifiers of your card (Device manager/display adapters/properties/details). They look like this:
PCI\VEN_1002&DEV_954F&SUBSYS_02A81043&REV_00
PCI\VEN_1002&DEV_954F&SUBSYS_02A81043
-
So I re-calculated the 'double' modes using Powerstrip. Worked great and was very easy to adjust geometry and what not. Now I've got a selection of resolutions that are twice the height/width of several 15kHz modes. I'll add more once I've got it working more correctly.
I'm guessing that Groovymame doesn't select 2x modes correctly yet? I tried to run a few games and it wasn't picking what I thought would be right:
Parsing mame.ini
Parsing mame.ini
SwitchRes: Entering switchres_modeline_setup (0)
SwitchRes: Setting Option -cleanstretch
SwitchRes: Monitor: m2929 Orientation: horizontal Aspect 4:3
SwitchRes v0.012o: [bublbobl] (1) horizontal (256x224@59.19)->(256x224@59.19)->(256x224@59.19)
SwitchRes: # bublbobl 256x224@59.19 30.0071Khz
SwitchRes: ModeLine "256x224x59.19" 13.923295 256 288 352 464 224 348 354 507 -HSync -VSync
SwitchRes: Found 15 custom of 29 active modelines
SwitchRes: 480 x 480 -> 50.20 Custom Modeline
SwitchRes: 512 x 480 -> 49.88 Custom Modeline
SwitchRes: 512 x 512 -> 49.56 Custom Modeline
SwitchRes: 512 x 528 -> 49.40 Custom Modeline
SwitchRes: 608 x 480 -> 48.92 Custom Modeline
SwitchRes: 640 x 480 -> 48.60 Custom Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 512 -> 48.28 Custom Modeline
SwitchRes: 640 x 576 -> 47.64 Custom Modeline
SwitchRes: 672 x 480 -> 48.28 Custom Modeline
SwitchRes: 704 x 512 -> 47.64 Custom Modeline
SwitchRes: 704 x 528 -> 47.48 Custom Modeline
SwitchRes: 704 x 576 -> 47.00 Custom Modeline
SwitchRes: 720 x 480 -> 47.80 Custom Modeline
SwitchRes: 720 x 480 -> 47.80 System Modeline
SwitchRes: 720 x 480 -> 47.80 System Modeline
SwitchRes: 720 x 576 -> 46.84 System Modeline
SwitchRes: 720 x 576 -> 46.84 System Modeline
SwitchRes: 720 x 576 -> 46.84 System Modeline
SwitchRes: 736 x 480 -> 47.64 Custom Modeline
SwitchRes: 768 x 576 -> 46.36 Custom Modeline
SwitchRes: 800 x 512 -> 46.68 Custom Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: Index 0/29 modeline DALDTMCRTBCD480X480X0X60 score 50.20 matches
SwitchRes: Got Custom modeline 480x480@60 - DALDTMCRTBCD480X480X0X60:
"480x480@60" 18.470000 480 496 544 608 480 481 484 498 -HSync -VSync
SwitchRes: Trying to recalculate modeline 256 x 224 != 480 x 480
SwitchRes: Setting Option -keepaspect
SwitchRes: New Modeline: ModeLine "480x480x59.19" 26.294034 480 528 648 856 480 482 488 519 -HSync -VSync
SwitchRes: Setting modeline registry entry for DALDTMCRTBCD480X480X0X60
SwitchRes: Setting Option -redraw 0
SwitchRes: Setting Option -cleanstretch
SwitchRes: Setting Option -rotate
SwitchRes: Setting Option -nosoundsync
SwitchRes: Enabling VSYNC
SwitchRes: Setting Option -nothrottle
SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 480x480@60
Video: Monitor 0000000000010001 = "\\.\DISPLAY1" (primary)
Direct3D: Using Direct3D 9
Direct3D: Configuring adapter #0 = ATI Radeon HD 4300/4500 Series
Direct3D: Selecting video mode...
480x 480@ 60Hz -> 4000.000000
512x 480@ 60Hz -> 2001.949341
512x 512@ 60Hz -> 2001.834839
512x 528@ 60Hz -> 2001.782471
608x 480@ 60Hz -> 2001.641968
640x 480@ 60Hz -> 2001.559937
640x 480@ 72Hz -> 73.948326
640x 480@ 75Hz -> 61.032917
640x 480@ 85Hz -> 38.853466
640x 480@ 90Hz -> 32.992374
640x 512@ 60Hz -> 2001.485840
640x 576@ 60Hz -> 2001.356812
672x 480@ 60Hz -> 2001.485840
704x 512@ 60Hz -> 2001.356812
704x 528@ 60Hz -> 2001.328003
704x 576@ 60Hz -> 2001.248413
720x 480@ 60Hz -> 2001.386841
720x 480@ 75Hz -> 60.859818
720x 480@ 85Hz -> 38.680367
720x 576@ 59Hz -> 844.674438
720x 576@ 60Hz -> 2001.223999
720x 576@ 75Hz -> 60.696842
736x 480@ 60Hz -> 2001.356812
768x 576@ 60Hz -> 2001.156128
800x 512@ 60Hz -> 2001.200439
800x 600@ 56Hz -> 239.999802
800x 600@ 60Hz -> 2001.085815
800x 600@ 70Hz -> 85.728287
800x 600@ 72Hz -> 73.474037
Direct3D: Mode selected = 480x 480@ 60Hz
Direct3D: Using dynamic textures
Direct3D: YUV format = RGB
Direct3D: Device created at 480x480
Direct3D: Max texture size = 8192x8192
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels
RawInput: APIs detected
Input: Adding Mouse #1: HID-compliant mouse
Input: Adding Gun #1: HID-compliant mouse
Input: Adding Mouse #2: HID-compliant mouse
Input: Adding Gun #2: HID-compliant mouse
Input: Adding Mouse #3: HID-compliant mouse
Input: Adding Gun #3: HID-compliant mouse
Input: Adding Kbd #1: HID Keyboard Device
Input: Adding Kbd #2: HID Keyboard Device
DirectInput: Using DirectInput 7
Input: Adding Joy #1: ATRAK Device #1
Input: Adding Joy #2: ATRAK Device #2
Starting Driver Device 'root'
(missing dependencies; rescheduling)
Starting Z80 'maincpu'
Starting Z80 'slave'
Starting Z80 'audiocpu'
Starting M6801 'mcu'
Starting Video Screen 'screen'
Starting Speaker 'mono'
(missing dependencies; rescheduling)
Starting YM2203 'ym1'
Starting YM3526 'ym2'
Starting Driver Device 'root'
(missing dependencies; rescheduling)
Starting Speaker 'mono'
Starting Driver Device 'root'
Direct3D: Error 88760868 during device present call
Direct3D: resetting device
SwitchRes: [1] Resolution change from 256x224 to 0x0
SwitchRes: Resolution change to 0x0@59
SwitchRes: Entering switchres_modeline_setup (1)
SwitchRes: Copy lastMode name 480x480@60
SwitchRes: Monitor: m2929 Orientation: horizontal Aspect 4:3
SwitchRes v0.012o: [bublbobl] (1) horizontal (256x224@59.19)->(256x224@59.19)->(256x224@59.19)
SwitchRes: # bublbobl 256x224@59.19 30.0071Khz
SwitchRes: ModeLine "256x224x59.19" 13.923295 256 288 352 464 224 348 354 507 -HSync -VSync
SwitchRes: 480 x 480 -> 50.20 Custom Modeline
SwitchRes: 512 x 480 -> 49.88 Custom Modeline
SwitchRes: 512 x 512 -> 49.56 Custom Modeline
SwitchRes: 512 x 528 -> 49.40 Custom Modeline
SwitchRes: 608 x 480 -> 48.92 Custom Modeline
SwitchRes: 640 x 480 -> 48.60 Custom Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 480 -> 48.60 System Modeline
SwitchRes: 640 x 512 -> 48.28 Custom Modeline
SwitchRes: 640 x 576 -> 47.64 Custom Modeline
SwitchRes: 672 x 480 -> 48.28 Custom Modeline
SwitchRes: 704 x 512 -> 47.64 Custom Modeline
SwitchRes: 704 x 528 -> 47.48 Custom Modeline
SwitchRes: 704 x 576 -> 47.00 Custom Modeline
SwitchRes: 720 x 480 -> 47.80 Custom Modeline
SwitchRes: 720 x 480 -> 47.80 System Modeline
SwitchRes: 720 x 480 -> 47.80 System Modeline
SwitchRes: 720 x 576 -> 46.84 System Modeline
SwitchRes: 720 x 576 -> 46.84 System Modeline
SwitchRes: 720 x 576 -> 46.84 System Modeline
SwitchRes: 736 x 480 -> 47.64 Custom Modeline
SwitchRes: 768 x 576 -> 46.36 Custom Modeline
SwitchRes: 800 x 512 -> 46.68 Custom Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: 800 x 600 -> 45.80 System Modeline
SwitchRes: Index 0/29 modeline DALDTMCRTBCD480X480X0X60 score 50.20 matches
SwitchRes: Got Custom modeline 480x480@60 - DALDTMCRTBCD480X480X0X60:
"480x480@60" 18.470000 480 496 544 608 480 481 484 498 -HSync -VSync
SwitchRes: Trying to recalculate modeline 256 x 224 != 480 x 480
SwitchRes: Setting Option -keepaspect
SwitchRes: New Modeline: ModeLine "480x480x59.19" 26.294034 480 528 648 856 480 482 488 519 -HSync -VSync
SwitchRes: Setting modeline registry entry for DALDTMCRTBCD480X480X0X60
SwitchRes: Setting Option -redraw 0
SwitchRes: Setting Option -cleanstretch
SwitchRes: Setting Option -rotate
SwitchRes: Setting Option -nosoundsync
SwitchRes: Enabling VSYNC
SwitchRes: Setting Option -nothrottle
SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 480x480@60
Direct3D: Configuring adapter #0 = ATI Radeon HD 4300/4500 Series
Direct3D: Selecting video mode...
480x 480@ 60Hz -> 4000.000000
512x 480@ 60Hz -> 2001.949341
512x 512@ 60Hz -> 2001.834839
512x 528@ 60Hz -> 2001.782471
608x 480@ 60Hz -> 2001.641968
640x 480@ 60Hz -> 2001.559937
640x 480@ 72Hz -> 73.948326
640x 480@ 75Hz -> 61.032917
640x 480@ 85Hz -> 38.853466
640x 480@ 90Hz -> 32.992374
640x 512@ 60Hz -> 2001.485840
640x 576@ 60Hz -> 2001.356812
672x 480@ 60Hz -> 2001.485840
704x 512@ 60Hz -> 2001.356812
704x 528@ 60Hz -> 2001.328003
704x 576@ 60Hz -> 2001.248413
720x 480@ 60Hz -> 2001.386841
720x 480@ 75Hz -> 60.859818
720x 480@ 85Hz -> 38.680367
720x 576@ 59Hz -> 844.674438
720x 576@ 60Hz -> 2001.223999
720x 576@ 75Hz -> 60.696842
736x 480@ 60Hz -> 2001.356812
768x 576@ 60Hz -> 2001.156128
800x 512@ 60Hz -> 2001.200439
800x 600@ 56Hz -> 239.999802
800x 600@ 60Hz -> 2001.085815
800x 600@ 70Hz -> 85.728287
800x 600@ 72Hz -> 73.474037
Direct3D: Mode selected = 480x 480@ 60Hz
Direct3D: Using dynamic textures
Direct3D: YUV format = RGB
Direct3D: Device created at 480x480
Direct3D: Max texture size = 8192x8192
512x480 would be the better mode here, and if I added a 512x448 it would be perfect.
Should I just generate a bunch of .ini files, do I have something configured wrong, or will Groovymame ONLY select perfect 2x modes?
-
So I re-calculated the 'double' modes using Powerstrip. Worked great and was very easy to adjust geometry and what not. Now I've got a selection of resolutions that are twice the height/width of several 15kHz modes. I'll add more once I've got it working more correctly.
Yes GroovyMame picks double modes automatically but the logic has some flaws yet it seems. When I tested it I generated the double modes using VMMaker and the results where ok but probably it was because I was generating both 448 and 480 lines modes. The issue here is probably because it's not properly scoring these two resolutions:
SwitchRes: 480 x 480 -> 50.20 Custom Modeline
SwitchRes: 512 x 480 -> 49.88 Custom Modeline
As 512x480 is not exact 512x448 (256x224 doubled), it's not considering it any better than 480x480, while the proper logic would be to consider 512 as good as 256 (unless 256 was present) and the difference in height as irrelevant because it usually does not affect the visual result (only few monitors auto-adjust vertical amplitude so 512x448 and 512x480+black borders look exactly the same).
-
I'll have to add more resolutions and see where it gets me.
-
PCI\VEN_1002&DEV_9552&SUBSYS_44721545&REV_00\4&3B252A0E&0&0010
-
PCI\VEN_1002&DEV_9552&SUBSYS_44721545&REV_00\4&3B252A0E&0&0010
Yes, that's a Mobility version:
http://pcidatabase.com/search.php?device_search_str=9552&device_search=Search (http://pcidatabase.com/search.php?device_search_str=9552&device_search=Search)
You'll need to patch the drivers before you can install them, using the ModTool, this thread explains how to do it:
http://forum.arcadecontrols.com/index.php?topic=109742.msg1163704#msg1163704 (http://forum.arcadecontrols.com/index.php?topic=109742.msg1163704#msg1163704)
-
I am trying to compile groovymame 0142
Ive got the base 0142 code, compiles fine
Applied hiscore patch, compiles fine
Can't apply 0142groovymame.diff
get this error (from command line)
patch -p0 -E <0142_groovymame.diff
patching file makefile
Assertion failed: hunk, file patch-2.5.4/patch.c, line 343
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Do I need to change all the CR to CRLF in the diff, if so how do I go about that?
Thanks
-
Thank you so much Calamity!! worked like a charm. only dumb question is why is running the crt emu driver better than running the regular ati driver soft 15k and groovymame? Thanks again!
-
Do I need to change all the CR to CRLF in the diff, if so how do I go about that?
Even if making a Windows buid, you need to add the 0142_hilinux.diff before the groovymame.diff, probably that's the issue.
Thank you so much Calamity!! worked like a charm. only dumb question is why is running the crt emu driver better than running the regular ati driver soft 15k and groovymame? Thanks again!
Great! With CRT_Emudriver you have 120 different video modes available, with regular Catalyst only 60. You actually need more than 100 to cover most variety of video modes used by Mame.
-
Do I need to change all the CR to CRLF in the diff, if so how do I go about that?
Even if making a Windows buid, you need to add the 0142_hilinux.diff before the groovymame.diff, probably that's the issue.
Still doesn't work.
C:\mamesrc>patch -p0 -E <hi_142.txt
patching file src/emu/emu.mak
patching file src/emu/emuopts.c
patching file src/emu/emuopts.h
patching file src/emu/hiscore.c
patching file src/emu/hiscore.h
patching file src/emu/machine.c
patching file src/emu/machine.h
patching file src/emu/mame.c
patching file src/emu/profiler.c
patching file src/emu/profiler.h
patching file src/emu/romload.c
patching file src/emu/ui.c
patching file src/emu/video.c
patching file src/emu/video.h
patching file src/mame/machine/cps2crpt.c
patching file src/osd/osdepend.c
patching file src/osd/osdepend.h
patching file src/osd/windows/video.c
patching file src/osd/windows/window.c
patching file src/osd/windows/window.h
patching file src/osd/windows/winmain.h
C:\mamesrc>patch -p0 -E <0142_hilinux.diff
patching file src/emu/emuopts.c
Assertion failed: hunk, file patch-2.5.4/patch.c, line 343
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
C:\mamesrc>patch -p0 -E <0142_groovymame.diff
patching file makefile
Assertion failed: hunk, file patch-2.5.4/patch.c, line 343
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Compiling using mingw-mame-w64-20100102, any idea what is going on here?
EDIT: It looks like the supplied diffs will not work with the MinGW PATCH command, but they do work with HeadKaze's Mame Compiler. I suspect this is down to missing Line Feeds after the CR's in the formatting of the text.
-
EDIT: It looks like the supplied diffs will not work with the MinGW PATCH command, but they do work with HeadKaze's Mame Compiler. I suspect this is down to missing Line Feeds after the CR's in the formatting of the text.
I see, I always use Mame Compiler so probably that's why it worked for me.
If you want to add the last galaxian patch open src\mame\includes\galaxian.h and edit this define (it's 3 by default):
#define GALAXIAN_XSCALE 1
-
EDIT: It looks like the supplied diffs will not work with the MinGW PATCH command, but they do work with HeadKaze's Mame Compiler. I suspect this is down to missing Line Feeds after the CR's in the formatting of the text.
I see, I always use Mame Compiler so probably that's why it worked for me.
If you want to add the last galaxian patch open src\mame\includes\galaxian.h and edit this define (it's 3 by default):
#define GALAXIAN_XSCALE 1
Thanks Calamity
-
If ever there was a thread in this forum's software board that needed stickying, this is it. Could we please get this stickied?
-
Maybe this is a stupid question, but anyway...
I would like to overclock the emulated cpu of some games.
When I do this with the slider controls (which by the way move extremely slow, it take ages to overclock to 200%) everything is fine.
Unfortunately when I exit the game the overclock setting isn't saved in the cfg file of the game.
So everytime I start the game I have to overclock again (which takes ages).
What can I do to save the setting?
-
Bought myself a Radeon 9800 pro and installed with crt_emudriver/groovymame - WOW! what an amazing job!
I think I have everything configured as it should be, but have a small issue with automatic resolution selection.
For example.
digdug (selects 640x480@ 61hz, should be 288,224) http://pastebin.com/zk1mABew (http://pastebin.com/zk1mABew)
bombjack (selects 320x448@ 60hz, should be 256x224) http://pastebin.com/N3kWSTGq (http://pastebin.com/N3kWSTGq)
btime2 (selects 688x512 @60hz, should be 240,240) http://pastebin.com/RN1eZrxg (http://pastebin.com/RN1eZrxg)
All 3 seem to select a much higher resolution than is required, the native resolution seems to be available for all 3 of these games
If I create an .ini file for these 3 games with just the native resolution (as shown in the game information panel in game) they work as intended - is there a way to use this information in the 'game information' screen as the default resolution?
The majority of games seem to select the correct resolution, Im not sure why its inconsistent on my system.
Thanks again for such an amazing project.
-
Hi jimmy2x2x, please paste your logs using -v -md 4 params so they show the switchres part and the logic used for picking resolutions.
-
-md 4 option only seems to work with the "_o" build for me (which selects different resolutions from 142, but not the correct ones)
here are the logs.
Bombjack http://pastebin.com/FBSnTmWb (http://pastebin.com/FBSnTmWb)
DigDug http://pastebin.com/SkpzFvPy (http://pastebin.com/SkpzFvPy)
Btime2 http://pastebin.com/vpewG2r1 (http://pastebin.com/vpewG2r1)
Thanks
EDIT: I am running a vertical TV connected via a homemade VGA to SCART cable if this makes a difference.
-
Hi. Is there any way i can patch mame 0.139 (windows) ?
:)
-
Calimity I just tried your test version and frogger does atleast size it closer to orginal botton of screen gets cut off. Also it messes up all the games like Dig Dug, pacman, Dkong. Dig Dug appears very small.
-
Probably selecting a larger resolution than it should be, so it doesn't scale properly.
Groovy mame needs it's own forum section.
-
Calimity I just tried your test version and frogger does atleast size it closer to orginal botton of screen gets cut off. Also it messes up all the games like Dig Dug, pacman, Dkong. Dig Dug appears very small.
I thought this was solved for me, but I am also having the same issues as bent98.
-
Yeah, that test version is buggy! It fixed the frogger issue but introduced another one, I was trying to repair a particular issue with my laptop and broke things... so go back to the "official" one and I'll upload a new one in an hour...
jimmy2x2x, you also need to set the right orientation of your monitor in mame.ini
-
New groovymame32_0142.012o_test.rar uploaded that should fix the wrong resolution picking issue.
jimmy2x2x, also, in VMMaker.ini set MonitorHorizontal = 0 and run VMMaker to recalculate the modes. That will make a more efficient use of your mode table by removing the resolutions needed for rotated vertical games on horizontal monitor.
-
jimmy2x2x, you also need to set the right orientation of your monitor in mame.ini
Which line do I need to change exactly?
EDIT: my current mame.ini http://pastebin.com/sq6V3AkG (http://pastebin.com/sq6V3AkG)
EDIT2: Changed the MonitorHorizontal = 0, ran VMMaker and rebooted - still the same.
looks like the latest test version is still picking wrong resolutions for the 3 test games
bombjack log http://pastebin.com/9CPMryV1 (http://pastebin.com/9CPMryV1)
EDIT3: Looks like the new test version somehow breaks 'Scramble' the map is corrupt at the start of the first level
Thanks for looking into this Calamity
-
Which line do I need to change exactly?
Thanks
EDIT: my current mame.ini http://pastebin.com/sq6V3AkG (http://pastebin.com/sq6V3AkG)
EDIT2: Changed the MonitorHorizontal = 0, ran VMMaker and rebooted - still the same.
looks like the latest test version is still picking wrong resolutions for the 3 test games
bombjack log http://pastebin.com/9CPMryV1 (http://pastebin.com/9CPMryV1)
That mame.ini is not GroovyMame's! :)
Create the right one by running groovymame -cc from command line. Then edit this line:
monitor_orientation horizontal
... set it to vertical.
-
Which line do I need to change exactly?
Thanks
EDIT: my current mame.ini http://pastebin.com/sq6V3AkG (http://pastebin.com/sq6V3AkG)
EDIT2: Changed the MonitorHorizontal = 0, ran VMMaker and rebooted - still the same.
looks like the latest test version is still picking wrong resolutions for the 3 test games
bombjack log http://pastebin.com/9CPMryV1 (http://pastebin.com/9CPMryV1)
That mame.ini is not GroovyMame's! :)
Create the right one by running groovymame -cc from command line. Then edit this line:
monitor_orientation horizontal
... set it to vertical.
Sorry about that (got confused testing various versions), the test version resolution switching is now perfect as far as I can see - Thanks
Scramble still has corrupted map in the test version
Frogger seems to be clipped at the bottom
Galaxian seems to be running about half speed
Gunsmoke has its screen shifted down, black bar at the top and clipped at the bottom (might be a problem with stock 142, not certain)
-
Scramble still has corrupted map in the test version
Frogger seems to be clipped at the bottom
Galaxian seems to be running about half speed
Gunsmoke has its screen shifted down, black bar at the top and clipped at the bottom (might be a problem with stock 142, not certain)
At this point it would be interesting to test this against the "official" 142.012o here: http://mario.groovy.org/GroovyMame/0142/, (http://mario.groovy.org/GroovyMame/0142/,) to see if those issues where there before or have been introduced by me.
I'm implementing a brand new blitting thread in that test version, it works perfectly here, but needs more testing. Also it might crash with d3d + games that switch resolutions. It can be disabled by setting multithreading to 0.
-
Scramble still has corrupted map in the test version
Frogger seems to be clipped at the bottom
Galaxian seems to be running about half speed
Gunsmoke has its screen shifted down, black bar at the top and clipped at the bottom (might be a problem with stock 142, not certain)
At this point it would be interesting to test this against the "official" 142.012o here: http://mario.groovy.org/GroovyMame/0142/, (http://mario.groovy.org/GroovyMame/0142/,) to see if those issues where there before or have been introduced by me.
I'm implementing a brand new blitting thread in that test version, it works perfectly here, but needs more testing. Also it might crash with d3d + games that switch resolutions. It can be disabled by setting multithreading to 0.
Grabbed the "official" 142.012o
deleted mame.ini, created new one
frogger doesnt appear to have resolution fix in this version, cant test clipped because of this
gunsmoke is the same, black bar at top of playfield, clipped at bottom
scramble map is not corrupt in this build
galaxian runs at the correct speed
-
I am not at home to test but if it doesnt work for you it wont work for me
-
Yes, I'm now seeing the same issues with Galaxian's speed and Scramble maps. It's due to the last fix I did, if removed they're gone, but we have the 768 wide resolution thing back. I don't ever play these games so I didn't notice the problems till now.
Frogger looks perfect here anyway.
Will see what can be done, thanks for testing!
-
Cool, hope you find a solution!
out of interest, what resolution does frogger run in for you?
-
Look foward to a solution. Thanks for your hard work.
-
Nvidia card drivers afford the ability for custom resolutions, that I think goes beyond the '32 mode limit', which may be one reason AdvMAME works with them. Have you explored this?
-
I've uploaded a new test version (groovymame32_0142.012o_test.rar), this one should finally fix the galaxian and scramble issues, at least at first sight, don't know if there are more hidden side effects or other games related to these that still have issues.
Nvidia card drivers afford the ability for custom resolutions, that I think goes beyond the '32 mode limit', which may be one reason AdvMAME works with them. Have you explored this?
The 32 mode limit for nVidia cards is not something that I've tested myself, but that read in the great documentation on different video cards made by Sailorsat for the German site.
Indeed, I've got an nVidia in this laptop and have defined about 100 modes using Powerstrip, that after all has to use the driver resources to make them available, so it seems likely that the driver itself let us define that amount of modes. But... the problem is that, like with Ati cards, there are two registry keys used for defining a video mode, first one is just the xres,yres,vfreq thing, second one is where you actually define the custom timings. The problem is that the driver can't read more than 32 of these second registry keys, so you can have many video modes but probably can't define a custom timing for more than 32 of them...
-
When we test these new versions do we need to re run vm maker to generalte new mode lines or just download and rune the groovymame.exe?
Just curious as I want to make sure I test correctly.
-
Still not correct here.
new mame.ini generated http://pastebin.com/TFV0jpz1 (http://pastebin.com/TFV0jpz1)
changed 3 things:
monitor_orientation vertical
disable_nagscreen_patch 0
disable_loading_patch 0
No game specific .ini files are present
Galaxian http://pastebin.com/dAMEQDcv (http://pastebin.com/dAMEQDcv)
seems perfect
Moon Cresta http://pastebin.com/NGdd5xby (http://pastebin.com/NGdd5xby) / Frogger http://pastebin.com/seGPubE0 (http://pastebin.com/seGPubE0)
have a large black bar at the top of the playfield and are clipped at the bottom of the playfield
Scramble http://pastebin.com/vY9zDYiK (http://pastebin.com/vY9zDYiK)
is not vsyncing and has screen tearing
then I ran Vmmaker with this .ini http://pastebin.com/JqJkHQtD (http://pastebin.com/JqJkHQtD)
producing this output http://pastebin.com/Am7NqJe8 (http://pastebin.com/Am7NqJe8)
and reset the pc, results are the same as above.
Would be interested in bent98's results, if you wouldnt mind testing?
Thanks for taking time out to try and resolve this Calamity
-
Moon Cresta http://pastebin.com/NGdd5xby (http://pastebin.com/NGdd5xby) / Frogger http://pastebin.com/seGPubE0 (http://pastebin.com/seGPubE0)
have a large black bar at the top of the playfield and are clipped at the bottom of the playfield
I'm seeing that the random blit size issue persists for these games:
DirectDraw: Mode selected = 256x 224@ 60Hz
DirectDraw: primary surface created: 256x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 319x472
DirectDraw: blit surface created: 319x472x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: Mode selected = 256x 224@ 60Hz
DirectDraw: primary surface created: 256x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 308x493
DirectDraw: blit surface created: 308x493x32 (R=00FF0000 G=0000FF00 B=000000FF)
It's strange because I haven't been able to reproduce that bug yet.
Scramble http://pastebin.com/vY9zDYiK (http://pastebin.com/vY9zDYiK)
is not vsyncing and has screen tearing
This is strange too. Please run dxdiag, go to the screen tab and check that both ddraw/d3d acceleration are enabled.
-
(https://lh5.googleusercontent.com/-5GXpG44KxuU/Tfske-CCbPI/AAAAAAAAAD0/d3CW70ZvTmM/s800/dxdiag.PNG)
-
Sorry, I can't see the picture you're posted, seems I can't access to some IPs at this moment :P
Are those options enabled?
-
Yes
DirectDraw Acceleration: Enabled
Direct3D Acceleration: Enabled
AGP Texture Acceleration: Enabled
No problems found.
I run lots of other scrolling games with groovymame, Scramble in this test build is the only one I have ever seen tearing.
-
Ok, so the problem must be somewhere else, I needed to discard that one. Later today I'll build a version that prompts more debug info, I need to trace where those random numbers come from, unfortunately I can't test that here because for some reason it won't happen in my system, but seems that both in your system and bent98's you're having similar issues. Thanks for your tests and debug info!
-
No worries, please post here when you have a new version ready I'll be lurking ;)
Sent you a donation as promised, keep up the great work!
-
Yea me two. Thanks. CAnt wait to try.
I just wish I could get Bill to finish Hyperspin 2.0
-
Will HS2.0 address the modeline limit?
-
I've uploaded a new test version, this one will prompt a lot of debug info that hopefully will help finding the bug. So run it as usual with -v -md 4 params but make sure to exit quickly, otherwise you'll get a huge log file.
Will HS2.0 address the modeline limit?
The author said he'd have a look at it.
-
frogger http://pastebin.com/fycDC69s (http://pastebin.com/fycDC69s)
mooncrst http://pastebin.com/8Vh76nru (http://pastebin.com/8Vh76nru)
scramble http://pastebin.com/ndgRaQWd (http://pastebin.com/ndgRaQWd)
Is there anything else you need Calamity?
Thanks
-
I'm now seeing which function the issue is comming from, we're getting closer...
-
Has anyone by change done a set of resolutions for LCD 16:9 1080p display?, as i have a media center PC under the LCD in the livining room at i would really like to put groovymame on, now i know it wont look anyway near as good as it should of a CRT screen but would be nice to have. Any ideas how low a res i could maintain on an LCD screen??
-
Has anyone by change done a set of resolutions for LCD 16:9 1080p display?, as i have a media center PC under the LCD in the livining room at i would really like to put groovymame on, now i know it wont look anyway near as good as it should of a CRT screen but would be nice to have. Any ideas how low a res i could maintain on an LCD screen??
Wouldn't HLSL effects be better suited to an LCD?
-
Has anyone by change done a set of resolutions for LCD 16:9 1080p display?, as i have a media center PC under the LCD in the livining room at i would really like to put groovymame on, now i know it wont look anyway near as good as it should of a CRT screen but would be nice to have. Any ideas how low a res i could maintain on an LCD screen??
Wouldn't HLSL effects be better suited to an LCD?
Indeed. The biggest feature of groovymame is the dynamic refresh rate modification, which I'm going to assume most LCDs wouldn't handle gracefully. Likewise most LCDs are going to have some kind of internal 'upscaler' when lower than native resolutions are sent to them-- possibly even stretching them to a 16:9 ratio, which distorts the image.
You will likely want to start with a stock groovymame mame.ini, turn off the changing of resolutions and enable clean stretch. That way it will only stretch the image as much as it can without going into fractional scaling. This will keep the image crisp.
-
Has anyone by change done a set of resolutions for LCD 16:9 1080p display?, as i have a media center PC under the LCD in the livining room at i would really like to put groovymame on, now i know it wont look anyway near as good as it should of a CRT screen but would be nice to have. Any ideas how low a res i could maintain on an LCD screen??
Wouldn't HLSL effects be better suited to an LCD?
Indeed. The biggest feature of groovymame is the dynamic refresh rate modification, which I'm going to assume most LCDs wouldn't handle gracefully. Likewise most LCDs are going to have some kind of internal 'upscaler' when lower than native resolutions are sent to them-- possibly even stretching them to a 16:9 ratio, which distorts the image.
You will likely want to start with a stock groovymame mame.ini, turn off the changing of resolutions and enable clean stretch. That way it will only stretch the image as much as it can without going into fractional scaling. This will keep the image crisp.
What is HLSL??
-
MAME's HLSL demonstrated in Mortal Kombat II (http://www.youtube.com/watch?v=aIm4EBCyHes#)
video effects using the video card.
-
thats the thing that always got me when adding scanlines it kills the contrast/brightness of the screen :(
-
frogger http://pastebin.com/fycDC69s (http://pastebin.com/fycDC69s)
mooncrst http://pastebin.com/8Vh76nru (http://pastebin.com/8Vh76nru)
scramble http://pastebin.com/ndgRaQWd (http://pastebin.com/ndgRaQWd)
Is there anything else you need Calamity?
Thanks
I've uploaded a new test version with even more debug info. Please paste your logs (frogger will be enough by now). Hopefully this one will bring us closer the origin of the problem. Just to discard stuff, are you using up-to-date roms for these games?
-
I am using 142roms set.
Do I need to run vmmaker or just run the test version of groovymame?
-
Also
Can you tell me the exactly command line you want me to run for frogger. I forgot what switchsto add and how to dump the debug info to a text file
-
frogger http://pastebin.com/fycDC69s (http://pastebin.com/fycDC69s)
mooncrst http://pastebin.com/8Vh76nru (http://pastebin.com/8Vh76nru)
scramble http://pastebin.com/ndgRaQWd (http://pastebin.com/ndgRaQWd)
Is there anything else you need Calamity?
Thanks
I've uploaded a new test version with even more debug info. Please paste your logs (frogger will be enough by now). Hopefully this one will bring us closer the origin of the problem. Just to discard stuff, are you using up-to-date roms for these games?
Everything is fully up to date for 0.142
Frogger log: http://pastebin.com/v7YFgSJ2 (http://pastebin.com/v7YFgSJ2)
Frogger looks the same as last couple of test builds, border at top of playfield and clipped at the bottom.
Thanks
bent98: I tried it before rerunning vmmaker and after running it (with a pc reset) same results.
groovymame32_xxx -v -md 4 frogger >test.txt
quit mame after frogger displays title screen
copy text from test.txt and paste it somewhere (I use pastbin)
-
Thanks for testing. Hopefully this will provide enough details calimity needs to fix.
-
bent98: Would you mind testing, so Calamity can see if our results are similar?
current test build http://mame.groovy.org/WindowsATIDrivers/groovymame32_0142.012o_test.rar (http://mame.groovy.org/WindowsATIDrivers/groovymame32_0142.012o_test.rar)
-
That link its broken and I cant find it in atidrivers section
-
Everything is fully up to date for 0.142
Frogger log: http://pastebin.com/v7YFgSJ2 (http://pastebin.com/v7YFgSJ2)
This last logs finally point to the exact place where the random values come:
bounds: (0.268079,0.171562)-(0.742655,0.973854)
However I have no clue why those values are used in your system, it might be an odd bug or something. I've made a temporary hack to set those values to (0,0)-(1,1) again, that seems to be the usual ones for all situations.
So test the new test version I've uploaded to see if it finally fix it.
Be aware that this is a hack and might break something else, let's see how it behaves.
-
im going to test right now
-
Thanks for testing. Hopefully this will provide enough details calimity needs to fix.
Try again, probably I was in the middle of uploading it.
BTW you don't need to run VMMaker unless you want to modify any of your monitor setup.
-
Well frogger didnt work well. frogger seemed too narrow left and right.
Heres log
-
also dig dug is shrunk down tiny and in center of screen, Here test file also
-
bent98, your logs look correct now, blit size is what's supposed to be, so I'm not sure what's the problem, would you mind posting some snapshots? Doesn't they look the same than other rotated vertical games?
-
New frogger log http://pastebin.com/HynqRm5d (http://pastebin.com/HynqRm5d)
graphics are scaled down losing definition
Game window is approx 50% width of screen, 75% height
(https://lh4.googleusercontent.com/-A-V8p15Y2Ls/Tfy-vJBX9QI/AAAAAAAAAD4/T7jyV7SI22Y/s800/0001.png)
-
New frogger log http://pastebin.com/HynqRm5d (http://pastebin.com/HynqRm5d)
graphics are scaled down losing definition
Game window is approx 50% width of screen, 75% height
(https://lh4.googleusercontent.com/-A-V8p15Y2Ls/Tfy-vJBX9QI/AAAAAAAAAD4/T7jyV7SI22Y/s800/0001.png)
So even if I hack the values at that point it doesn't fix things as the problem comes from a point deeper in the emulator code, as if it was using different interal sizes in your systems for some reason.
This is really, really strange. Please try deletting any frogger.cfg /.nv from the cfg and nv folder.
-
deleted .cfg
no nv file for frogger
no .ini file
same result
-
Have you tested disabling the 'modeline' option in mame.ini?
-
just tried that, did not rotate the screen and ran in 448x256 giving a very small game window
-
I think I got it, do you guys happen to have any frogger artwork inside artwork's folder? If so, either try running groovymame with -artwork_crop param or delete/rename your artwork folder...
-
I think I got it, do you guys happen to have any frogger artwork inside artwork's folder? If so, either try running groovymame with -artwork_crop param or delete/rename your artwork folder...
:notworthy: :notworthy: BRILLIANT! You have solved it my friend, well done ;)
All these are now working 100% for me in 15khz
Frogger
Moon Cresta
GunSmoke
Galaxian
Scramble
Everything seems fine, thank you for your determination Calamity - you saw the job through to its end :cheers:
Is the last build a hack with a special case for Frogger?
Could you test if hiscore support is working your end with the last build please?
EDIT:
Also, could I be so bold as to request an additional feature?
This might not be appropriate, but I will ask anyway:
Add 2 new parameters to .ini/command line.
Xadjust and Yadjust
These are pixel values that are added to the games native resolution to help with overscan issues
(add the Xadjust/Yadjust values to the native res before selecting a resolution)
I realise I could just supply a new resolution instead of this method, but it would be very long winded for a large gamelist.
What do you think?
Thanks again for all your hard work and commitment to this project!
-
I think I got it, do you guys happen to have any frogger artwork inside artwork's folder? If so, either try running groovymame with -artwork_crop param or delete/rename your artwork folder...
GroovyMAME should probably default to having artwork_crop on since its primary reason for existing is arcade monitors.
-
If ever there was a thread in this forum's software board that needed stickying, this is it. Could we please get this stickied?
Saint says that he'll create a dedicated GroovyMAME board if bitbytebit and/or Calamity want one...
http://forum.arcadecontrols.com/index.php?topic=112485.0 (http://forum.arcadecontrols.com/index.php?topic=112485.0)
-
Great! This issue was driving me nuts, it had to be something external to mame itself as there was no reason why the exact same binary was using totally random values in your system, but what??!! Fortunately the test builds turned out to point to the rendlay.c as the origin of the random values, and that's where artwork is managed.
However that seems a bug in stock Mame as it shouldn't mess things if artwork is not enabled.
Is the last build a hack with a special case for Frogger?
Could you test if hiscore support is working your end with the last build please?
My advice is to go back to the "official" groovymame build. The test builds should be just for testing new ideas and patches. If the original frogger/galaxian hack works, then we can keep it as it is. I tried a different approach to the frogger/galaxian patch than the original Cabmame's one, patching the galaxian driver itself to work at 256x224, thinking your issues were related to that, now it turns out it was the atwork so the new patch didn't make any difference, and possibly introduced new ones (tearing in scramble, did you see it now?). At least it seemed it is the right way to patch these games as you only need to change the value of the xscale.
However, I'll keep the test build rolling the last changes back as it also contains the new experimental three-threaded blitting mechanism that is the only one to allow perfect asynchronous lagless triplebuffering.
EDIT:
Also, could I be so bold as to request an additional feature?
This might not be appropriate, but I will ask anyway:
Add 2 new parameters to .ini/command line.
Xadjust and Yadjust
These are pixel values that are added to the games native resolution to help with overscan issues
(add the Xadjust/Yadjust values to the native res before selecting a resolution)
Actually, the ortodox way of targeting overcan is to edit your monitor's definition porch values in VMMaker.ini and mame.ini. That will add the extra margins you are requesting in a way that's transparent to Mame.
-
Actually, the ortodox way of targeting overcan is to edit your monitor's definition porch values in VMMaker.ini and mame.ini. That will add the extra margins you are requesting in a way that's transparent to Mame.
Im not familiar with this, could you explain a little please?
I assume this is the line I need to change in vmmaker.ini
monitor_specs_0 = "15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.160, 1.056, 0, 0, 288, 448"
so to increase the borders, what would I need to change here?
Thanks!
I have dropped back to stock groovymame and everything seems to be working fine ;)
I agree - there is definitely a bug with stock mame, you can see it with gunsmoke and frogger (probably more) with artwork present in the path but disabled.
-
Im not familiar with this, could you explain a little please?
I assume this is the line I need to change in vmmaker.ini
monitor_specs_0 = "15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.160, 1.056, 0, 0, 288, 448"
so to increase the borders, what would I need to change here?
Thanks!
monitor_specs_0 = "15625-16200, 49.50-65.00, 2.000(right margin), 4.700, 8.000(left margin), 0.064, 0.160, 1.056, 0, 0, 288, 448"
So if you want to increase those, use 2.500 and 8.5000 for instance, or either increase one of them if you want to center the picture... That's for vmmaker.ini. For mame.ini, format is the same but use monitor_specs0 and remove the quotations. You may only use the mame.ini line by now until you find your values. Another possibility is using Arcade_OSD to dynamically find your values and then copy them to the monitor_specs line.
On the other hand, vertical margins can't be modified by software usually, you'll need to use your monitor's potenciometers to regulate vertical amplitude.
-
Got it!, Thanks ;)
One last question (you wish!) is there a way to rotate my display 180 degrees from within mame.ini?
I have the monitor set to vertical and I cant seem to find the right combination to rotate it 180.
I can do this from within each game and the setting is saved in the .cfg file as rotate 180
-
Use the -ror / -rol, I think groovymame automatically uses -autorol when monitor orientation is set to vertical so I don't know if it'll override your settings anyway.
-
If ever there was a thread in this forum's software board that needed stickying, this is it. Could we please get this stickied?
Saint says that he'll create a dedicated GroovyMAME board if bitbytebit and/or Calamity want one...
http://forum.arcadecontrols.com/index.php?topic=112485.0 (http://forum.arcadecontrols.com/index.php?topic=112485.0)
Thanks krick! That would allow keeping different subjects in separate threads, so if you think it's a good idea I'll ask Saint to create one. However, I'd like to hear bitbytebit opinion on this as he's actually the man behind the whole groovymame thing.
-
If ever there was a thread in this forum's software board that needed stickying, this is it. Could we please get this stickied?
Saint says that he'll create a dedicated GroovyMAME board if bitbytebit and/or Calamity want one...
http://forum.arcadecontrols.com/index.php?topic=112485.0 (http://forum.arcadecontrols.com/index.php?topic=112485.0)
Thanks krick! That would allow keeping different subjects in separate threads, so if you think it's a good idea I'll ask Saint to create one. However, I'd like to hear bitbytebit opinion on this as he's actually the man behind the whole groovymame thing.
Sounds great to me!
-
I think I got it, do you guys happen to have any frogger artwork inside artwork's folder? If so, either try running groovymame with -artwork_crop param or delete/rename your artwork folder...
Holy Sh*t! It works perfect now. That was it. I love you.
Now if there was a way to pick and choose which resolutions you want and eliminate the ones you dont want that would help with the Hyperspin limitation right now.
-
I'm testing a possible workaround for the HS issue. Basically the idea is to only create 32 bpp modes. As Windows reports 16 and 32 bpps modes as different ones, by doing that we are dividing by two the total number of modes in the system, possibly allowing HS to start. I can confirm it works with v6.5 for xp64. If any of you are willing to try, please post your crt_emudriver version and for which xp system it is, as can only test this one version by now.
So use your own custom vmmaker.ini file but make sure to add this line (see the vmmaker.ini included):
Only32BPPModes = 1
Apart from that, I've re-included the RestrictedModes feature to restrict most of the driver's native modes to help saving space. Though this works fine in 6.5 xp32/64 and possibly 9.3 xp64, I'm suspecting it could cause some blue screens on 9.3 xp32, so be carefull and in the worst case reinstall the driver.
cotmm68030 tested this on 9.3 xp64(?) and had to lower the total number of modes to 100 to make HS load.
Finally, be aware some emulators can only use 16 bbps modes, so this trick will affect them, as is the case of neoraine for what I'm seeing.
-
Lol believe it or not i decided to give HS a try for giggles before doing anything else, and it works fine with 120 mod lines on xp pro x64 9.3 drivers /shrug haven't run into any problems yet.
-
Yes i've been testing on XP64 on a Radeon 4350HD.
And though it doesn't probably matter from a number of resolution stand point, i'm testing on a 31kHz arcade monitor, using resolutions scaled 2x.
-
how come there aren't any update versions? I'm dying to see the changes in mk4 in 142u6.
-
Because update versions are full of experimental stuff that sometimes breaks other stuff.
Plus, you have to update your ROM sets every update, which is a hassle.
Personally, I'd rather stick to the main (hopefully) stable releases for my arcade cabinet.
-
Lol believe it or not i decided to give HS a try for giggles before doing anything else, and it works fine with 120 mod lines on xp pro x64 9.3 drivers /shrug haven't run into any problems yet.
Interesting.
In your report on the WG D9000 you said it has no EDID. EDID info usually contains a buch video modes supported by the monitor that the driver reads and adds to its internal list, so probably not having an EDID is an advantage in this particular case.
-
it's that it doesn't have EDID it just that it's useless compared to a standard EDID
compare the WG EDID to my asus EDID
hell it might as well be blank that's why windows reports it as a non PnP monitor
-
Anyone have the black bars on the left and right side of Neo Geo MVS games?
For some reason I can not get them to go away?
-
Lol believe it or not i decided to give HS a try for giggles before doing anything else, and it works fine with 120 mod lines on xp pro x64 9.3 drivers /shrug haven't run into any problems yet.
Interesting.
In your report on the WG D9000 you said it has no EDID. EDID info usually contains a buch video modes supported by the monitor that the driver reads and adds to its internal list, so probably not having an EDID is an advantage in this particular case.
So what does that mean EDID?
-
Extended display identification data (EDID) is a data structure provided by a digital display to describe its capabilities to a video source (e.g. graphics card, Set-top box). It is what enables a modern personal computer to know what kinds of monitors are connected to it. EDID is defined by a standard published by the Video Electronics Standards Association (VESA). The EDID includes manufacturer name and serial number, product type, phosphor or filter type, timings supported by the display, display size, luminance data and (for digital displays only) pixel mapping data.
-
Also some video cards (particularly newer ones) will sometimes prevent arbitrary modes from working when the EDID is not provided. EDID spoofing dongles have been built/sold by SailorSat in the past for people having problems with video cards that would not work with Soft15kHz because of the missing EDID.
-
Can someone give me the monitor_specs line so that I can run my Neo Geo games at 320x240@59.18Hz? Pretty sure that's the correct values, but if someone has better ones for Neo Geo, let me know. Running ArcadeVGA 3000 w/ WG D7700.
Also, any plans for a no-nag option?
-
Can someone give me the monitor_specs line so that I can run my Neo Geo games at 320x240@59.18Hz? Pretty sure that's the correct values, but if someone has better ones for Neo Geo, let me know. Running ArcadeVGA 3000 w/ WG D7700.
Also, any plans for a no-nag option?
Check the internal menu in MAME. Neo-Geo is an odd bird in that games often have extra "crap" on the sides that the arcade operator would push off-screen by adjusting the monitor settings. If I recall correctly, there's an option in the MAME internal menu that allows you to show the screen with a black border around it that obscures the "crap". I think there's also an option that crops the game screen, but it won't yield arcade-accurate results on an arcade monitor. I thought there was a MAME FAQ about it, but I can't find one at the moment.
UPDATE - MORE INFO:
http://mamedev.org/devwiki/index.php/MAME_0.122u4 (http://mamedev.org/devwiki/index.php/MAME_0.122u4)
David Haywood and Aaron Giles added a default layout to neogeo games allowing for either cropping or stretching to the alternate 304x224 layout. Removed default cropping in the driver.
I think that there is a no-nag option, but it's disabled by default. Generate a mame.ini file by running GroovyMAME -cc and look for it.
-
Extended display identification data (EDID) is a data structure provided by a digital display to describe its capabilities to a video source (e.g. graphics card, Set-top box). It is what enables a modern personal computer to know what kinds of monitors are connected to it. EDID is defined by a standard published by the Video Electronics Standards Association (VESA). The EDID includes manufacturer name and serial number, product type, phosphor or filter type, timings supported by the display, display size, luminance data and (for digital displays only) pixel mapping data.
What ATI video cards don't have EDID? I'd like to see if it solves the HS problem.
-
What ATI video cards don't have EDID? I'd like to see if it solves the HS problem.
I thought that EDID was in the monitor and the video card driver could query it using Plug and Play API in Windows.
-
What ATI video cards don't have EDID? I'd like to see if it solves the HS problem.
I thought that EDID was in the monitor and the video card driver could query it using Plug and Play API in Windows.
this is correct. edid is generated by the monitor, queried by windows.
http://en.wikipedia.org/wiki/Extended_display_identification_data (http://en.wikipedia.org/wiki/Extended_display_identification_data)
-
What ATI video cards don't have EDID? I'd like to see if it solves the HS problem.
It's a monitor's feature actually, as they're saying.
You'd better try the HS workaround I posted above.
-
I'm testing a possible workaround for the HS issue. Basically the idea is to only create 32 bpp modes. As Windows reports 16 and 32 bpps modes as different ones, by doing that we are dividing by two the total number of modes in the system, possibly allowing HS to start. I can confirm it works with v6.5 for xp64. If any of you are willing to try, please post your crt_emudriver version and for which xp system it is, as can only test this one version by now.
So use your own custom vmmaker.ini file but make sure to add this line (see the vmmaker.ini included):
Only32BPPModes = 1
Apart from that, I've re-included the RestrictedModes feature to restrict most of the driver's native modes to help saving space. Though this works fine in 6.5 xp32/64 and possibly 9.3 xp64, I'm suspecting it could cause some blue screens on 9.3 xp32, so be carefull and in the worst case reinstall the driver.
cotmm68030 tested this on 9.3 xp64(?) and had to lower the total number of modes to 100 to make HS load.
Finally, be aware some emulators can only use 16 bbps modes, so this trick will affect them, as is the case of neoraine for what I'm seeing.
What is 16bbps? 16 bit color?
-
What is 16bbps? 16 bit color?
Sure, 16 bits per pixel.
-
Any idea why these 2 games select 640x480 when they are 320x240 games?
Brave Blade
Aero Fighters Special
Should I need to enable throttle to get juno first running at 100%? (runs at 200% with throttle disabled)
-
Any idea why these 2 games select 640x480 when they are 320x240 games?
Brave Blade
Aero Fighters Special
Should I need to enable throttle to get juno first running at 100%? (runs at 200% with throttle disabled)
According to maws those games are 640x480 indeed. Paste your logs so we can have a look at the 200% speed issue.
-
juno first log http://pastebin.com/PLQhEged (http://pastebin.com/PLQhEged)
weird about those other games, they show as 320x240 in game information when running the game and that looks like the correct resolution to me.
-
For juno first you need to enable -redraw option, as it originally runs at 30 Hz.
For the others, have a look at your logs and see what logic its using to pick that resolution, remind to use the -md 4 param. Here aerofgt reports 320x224. Are you setting your rotate options right?
-
Thanks Calamity, just to clarify:
I only enable -redraw for Juno First (and any other games running at 30hz) or can I enable for all games?
I have built my own version of Groovymame from the supplied diffs, is the -md 4 param enabled in this build (did not work here)
I think I must have used one of the supplied binaries for the -md 4 option previosly, I will check next time ;)
The rom for Aero Fighter Special is: aerofgts.zip (brvblade.zip is the other, same oberservation)
when you load the rom, press tab and select game information it says 320x240, groovymame selects 640x480
is the res incorrect or maybe the game uses resolution switching?
-
Yes, I've tested aerofgts and it switches resolutions: 640x480 -> 256x240 -> 320x240 so you need to enable the -changeres option.
You can enable -redraw globally as it won't hurt games that don't need it. Same with -changeres.
-
ok I have enabled both options
Juno First is still running at 200% with throttle off
Aero Fighters Special looks like it is staying in 640x480 res
do you have different results?
Thanks
-
Here juno first runs 100%, and the others change resolutions as expected. I'm suspecting either your binary is missing the groovymame patches (your logs have no mention to the switchres part) or you have the -modeline option disabled?.
-
The 32 mode limit for nVidia cards is not something that I've tested myself, but that read in the great documentation on different video cards made by Sailorsat for the German site.
Indeed, I've got an nVidia in this laptop and have defined about 100 modes using Powerstrip, that after all has to use the driver resources to make them available, so it seems likely that the driver itself let us define that amount of modes. But... the problem is that, like with Ati cards, there are two registry keys used for defining a video mode, first one is just the xres,yres,vfreq thing, second one is where you actually define the custom timings. The problem is that the driver can't read more than 32 of these second registry keys, so you can have many video modes but probably can't define a custom timing for more than 32 of them...
I guess you'd have to test it. If that isn't the way, then somehow AdvanceMAME dynamically programmed the video board without 'a list of modes'. It wonder whether svgawin works with Vista or 7.
-
I guess you'd have to test it. If that isn't the way, then somehow AdvanceMAME dynamically programmed the video board without 'a list of modes'. It wonder whether svgawin works with Vista or 7.
Sure, AdvanceMame used its own video driver to handle harware directly.
-
When I use this:
groovymame64_0142.012o.exe.7z 10.64 Meg April 29 2011 21:28:30
Juno First runs at 100%
Aero Fighters Special still seems locked to 640x480 (at least I think so, looks interlaced and was expecting non interlaced in gameplay demo)
also my screen is displayed upside down for all games and I cant seem to resolve this (its fine in my base 142+hiscore+gm diff build)
aero fighters log http://pastebin.com/RV54F5UC (http://pastebin.com/RV54F5UC)
mame.ini http://pastebin.com/8xVr4ybE (http://pastebin.com/8xVr4ybE)
-
Yes, I'm seeing the same issue here, I'll have a fix for it later today.
-
Aero Fighters Special still seems locked to 640x480 (at least I think so, looks interlaced and was expecting non interlaced in gameplay demo)
also my screen is displayed upside down for all games and I cant seem to resolve this (its fine in my base 142+hiscore+gm diff build)
New groovymame32_0142.012o_test.rar uploaded that should fix those issues.
Notice that' I've changed the default direction that monitor is supposed to be rotated.
-
Juno First runs at the correct speed
Monitor rotation is now correct
Aero Fighters Special http://pastebin.com/w94cSsHi (http://pastebin.com/w94cSsHi) / Brave Blade http://pastebin.com/SjC67dFR (http://pastebin.com/SjC67dFR) still seems to be locked to 640x480
MKChamp options are present in the newly generated .ini but hiscore support seems to be broken in this build
Thanks Calamity.
-
What are the res for those games? Could it be gmame is defaulting to 640x480 because it cant find a sutiable resolution
-
I think its 320x240 In game
If I force that res from command line, in game looks perfect to me
and thats the res listed in 'game information' in game for each game.
-
Im betting that thats whats happening, is that gmame is defaulting to 640x480 because it cant find a sutable resolution, fimd another 320x240 game and see if it does 640x480
-
ddonpach runs at 320x240, along with countless others
-
Im out of ideas then lol, guess its something calamity will have to figure out
-
Thanks anyway!
You could try running 'aero fighters special' or 'brave blade' see if your results are the same as mine if you like?
-
mine actually selects 760x240 lol, it's got the correct A/R though centered in the middle of the screen vertical like pacman or galaga.
-
Juno First runs at the correct speed
Monitor rotation is now correct
Aero Fighters Special http://pastebin.com/w94cSsHi (http://pastebin.com/w94cSsHi) / Brave Blade http://pastebin.com/SjC67dFR (http://pastebin.com/SjC67dFR) still seems to be locked to 640x480
MKChamp options are present in the newly generated .ini but hiscore support seems to be broken in this build
Thanks Calamity.
New test version uploaded, should fix aerofgts issue.
I don't have a clue why hiscore patch would not work, I never check that so probably it got broken in my test build some time ago, how do you check if it works?
-
Play an easy game to get a hiscore, say galaga
once you have beat the highscore, end your game by getting killed
quit mame
reload mame
you new hiscore should be displayed (and should also be in the mame\hi folder as galaga.hi)
if it doesnt work, the old hiscore will be displayed
-
Also..
Grab the latest hiscore.dat from here http://highscore.mameworld.info/download.htm (http://highscore.mameworld.info/download.htm)
Make sure you have a 'hi' folder in your mame folder
Make sure you don't have hiscores disabled in MKChamp options in mame.ini
Juno First running great!
Aero Fighters Special running great!
Brave Blade running great!
Calamity, If you manage to fix the hiscores, could you provide a .diff or possibly compile a 64 bit version?
Thanks ;)
-
New test version uploaded, should fix aerofgts issue.
Is the problem with aerofgts related to the gauntleg resolution switching issue I posted about earlier in this thread?
-
Calamity, If you manage to fix the hiscores, could you provide a .diff or possibly compile a 64 bit version?
Yes, I need to do that .diff anyway to make sure I preserve the new patches until they can be added to the mainline groovymame. Hopefully during the weekend I have some time for that. The hiscore patch not working could be due to the patch for the 3-threads model built in the test version, will need to test that. I can't compile a 64 bit version at the moment as the build tools for that won't work on the 32 bit system I use for compiling.
Is the problem with aerofgts related to the gauntleg resolution switching issue I posted about earlier in this thread?
Maybe, I'm not sure. I needed to change the place where the changeres patch was inserted inside the render.c file, as the resolution switching was triggered in some situations where it shouldn't, i.e. when maximizing/minimazing the window. In addition, that change turned out to be the one needed to make aerofgts work properly. There is an extra issue yet with the changeres patch, that only affects vertical games on horizontal monitor which switch resolutions, I still need to fix that one.
Finally, 12o version's implementation of the find best mode algorithm has a logic flaw that happens when a resolution is virtualized. This had worked great before but I've noticed rthat the last mainline verison doesn't always pick the best resolution in these cases.
-
Great news Calamity, keep up the fantastic work!
-
I finally got around to getting this up and running and all I can say is WOW. So much for the argument about arcade monitors being too much trouble. This thing picks absolutely perfect refresh rates and resolutions for every game I've tried so far on the auto setting. This is also the only time I've ever seen MAME with absolutely no screen tearing or sound glitches. I'm especially impressed at the vertical games like DoDonPachi which groovymame picks a custom 320 line resolution at exactly the correct refresh rate on my D9400. Thanks so much for this software.
:applaud: :cheers: :notworthy:
How difficult would it be to release a mame-ui based build of groovymame?
-
Groovy mame needs it's own forum section.
you got your 5 minutes of fame and allready want a forum section, ive seen posts larger then this threat, i remember uncle t having its own section,not to mention powermame and skjukebox and dos sections are dead...
-
Groovy mame needs it's own forum section.
you got your 5 minutes of fame and allready want a forum section, ive seen posts larger then this threat, i remember uncle t having its own section,not to mention powermame and skjukebox and dos sections are dead...
But I bet they are still full of relevant information for whomever might want to run them, or have run them in the past.
Between the Groovy build and the drivers, there are a lot of possibilities for different configurations on different display devices that would be more easily serviced in individual threads. Even if it were abandoned in a year there would still be a good bit of searchable information there.
Currently I'm running on an SVGA monitor, but essentially using native resolutions/refresh rates without visible scaling, and filling the screen on every resolution. I don't think that's something that had been easily done previously. Likewise I recently tested it on an LCD with a variable refresh rate range and was able to run MK1 at ~99% speed with perfect sync-- even on the infamous character scroll screen there was no visible tearing or judder. If the monitor had supported a slightly wider range of refresh rates it would have been synced at 100%.
I think there is too much active development going on for a single thread to be a viable place to discuss it. Even a dozen threads on an existent board would be scattered and hard to correlate.
-
Groovy mame needs it's own forum section.
you got your 5 minutes of fame and allready want a forum section, ive seen posts larger then this threat, i remember uncle t having its own section,not to mention powermame and skjukebox and dos sections are dead...
I don't understand why you just posted that. You sound like adding a dedicated GroovyMAME forum here at BYOAC somehow personally harms you. Are you paying for the bandwidth, storage, or other hosting fees here at BYOAC out of your own pocket?
-
I guess you'd have to test it. If that isn't the way, then somehow AdvanceMAME dynamically programmed the video board without 'a list of modes'. It wonder whether svgawin works with Vista or 7.
Sure, AdvanceMame used its own video driver to handle harware directly.
I'm wondering....maybe it circumvented the card drivers and made direct vga calls?
-
I finally got around to getting this up and running and all I can say is WOW. So much for the argument about arcade monitors being too much trouble. This thing picks absolutely perfect refresh rates and resolutions for every game I've tried so far on the auto setting. This is also the only time I've ever seen MAME with absolutely no screen tearing or sound glitches. I'm especially impressed at the vertical games like DoDonPachi which groovymame picks a custom 320 line resolution at exactly the correct refresh rate on my D9400. Thanks so much for this software.
:applaud: :cheers: :notworthy:
How difficult would it be to release a mame-ui based build of groovymame?
Agreed, I would love to see a UI in a future build. I would also like to see a build for misiftmame as it is no longer being updated and I enjoy playing UMK3 juggernaut hack on my cab with perfect resolution and refresh.
-
Agreed, I would love to see a UI in a future build.
Disagreed. A GUI seems like a waste of limited developer talent.
I challenge anyone who wants a GUI to go ahead and create one. This IS open source software, after all.
I'd rather see the brains behind this operation go to keeping up-to-date with current versions of MAME, squashing bugs, and polishing existing features... But I'm not going to ask for any of those things. Instead, I will extend my thanks to bitbytebit and Calamity for burning their free time to create this fine piece software.
-
I will extend my thanks to bitbytebit and Calamity for burning their free time to create this fine piece software.
Make sure you donate too. I encourage anyone who is using GroovyMAME and/or the custom ATI drivers to donate.
-
Has anyone successfully compiled GroovyMAME in any other Linux distros? I'm trying to do so in Arch, but am getting snagged up here:
obj/sdl/groovymame64/libocore.a: could not read symbols: Malformed archive
collect2: ld returned 1 exit status
make: *** [obj/sdl/groovymame64/build/makedep] Error 1
Any ideas?
-
To clarify (and update) I get the above error when trying to make after doing:
git clone git://git.groovy.org/groovy/groovymame0142.git
If I try to prepare the source myself, I run into problems similar to those described here (http://forum.arcadecontrols.com/index.php?topic=111930.0). 0142_hi.diff applies just fine, but 0142_hilinux.diff fails, which of course causes 0142_groovymame.diff to fail.
I unzip the virgin MAME 0.142 source with:
unzip -aa mame.zip
I do not apply any update patches. I then apply 0142_hi.diff, 0142_hilinux.diff, and
0142_groovymame.diff (in order) with:
patch -p0 -E <0142_hi.diff
Following this method, patch -p0 -E <0142_hilinux.diff spits out the following:
patching file src/emu/emuopts.c
Hunk #1 FAILED at 194.
1 out of 1 hunk FAILED -- saving rejects to file src/emu/emuopts.c.rej
patching file src/emu/hiscore.c
Hunk #1 FAILED at 349.
1 out of 1 hunk FAILED -- saving rejects to file src/emu/hiscore.c.rej
patching file src/osd/sdl/osdsdl.h
Hunk #1 FAILED at 242.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/osdsdl.h.rej
patching file src/osd/sdl/video.c
Hunk #1 FAILED at 351.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/video.c.rej
patching file src/osd/sdl/window.c
Hunk #1 FAILED at 1006.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/window.c.rej
patching file src/osd/sdl/window.h
Hunk #1 FAILED at 129.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/window.h.rej
-
Just something to try: check if applying the patches using Mame Compiler for Windows works, then make your build under Linux.
-
Groovy mame needs it's own forum section.
you got your 5 minutes of fame and allready want a forum section, ive seen posts larger then this threat, i remember uncle t having its own section,not to mention powermame and skjukebox and dos sections are dead...
But I bet they are still full of relevant information for whomever might want to run them, or have run them in the past.
Between the Groovy build and the drivers, there are a lot of possibilities for different configurations on different display devices that would be more easily serviced in individual threads. Even if it were abandoned in a year there would still be a good bit of searchable information there.
Currently I'm running on an SVGA monitor, but essentially using native resolutions/refresh rates without visible scaling, and filling the screen on every resolution. I don't think that's something that had been easily done previously. Likewise I recently tested it on an LCD with a variable refresh rate range and was able to run MK1 at ~99% speed with perfect sync-- even on the infamous character scroll screen there was no visible tearing or judder. If the monitor had supported a slightly wider range of refresh rates it would have been synced at 100%.
I think there is too much active development going on for a single thread to be a viable place to discuss it. Even a dozen threads on an existent board would be scattered and hard to correlate.
I was just teasing, actualy i think this project its great, im still lurking on it.....
-
Calamity, have you had any time to produce a new .diff with the most recent changes (+ hiscores working)?
Or will you guys be waiting for 0.143 for the next release (I suspect its coming towards the end of the .142 cycle)?
Any news on the BYOAC GroovyMame forum, will it have sub forums for 'nix and drivers, how are you going to structure it?
Many thanks
-
Calamity, have you had any time to produce a new .diff with the most recent changes (+ hiscores working)?
I had a look at the hiscore issue but found no reason why it shouldn't work... you say it does work for the mainline Groovymame?
I'm working on fixing some of the issues I mentioned above, will have it ready soon hopefully.
Or will you guys be waiting for 0.143 for the next release (I suspect its coming towards the end of the .142 cycle)?
Yes, 0.143 is about to come, if bitbytebit isn't back by then I'll try to adapt the patches for the new version, it shouldn't be too difficult unless they've changed too much stuff in the involved files since 0.142 version, however later patches where quite clean to apply.
Any news on the BYOAC GroovyMame forum, will it have sub forums for 'nix and drivers, how are you going to structure it?
Many thanks
I think an unique subforum should be more than enough to keep the different subjects in separate threads. Honestly I'm happy enough with these spaghetti threads but I understand that it is a mess to get any information from for the newcomers.
-
Yes, for me Highscores stopped working in the test versions but do work fine in my compile of groovymame (from the supplied diff)
Ps. Glad you saw the light with the LCD refresh rate thread - that guy is poison.
-
Just something to try: check if applying the patches using Mame Compiler for Windows works, then make your build under Linux.
That did the trick, thank you - I probably should have been able to figure that out based on jimmy2x2x's posts above, but for whatever reason I tuned them out as being a "Windows solution."
Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.
In case this helps... This occurs in ArchLinux using a kernel built with bitbytebit's GroovyLinux patches on an AVGA3000 with the stock open source ATI driver feeding a 25" Wells-Gardner k7191.
-
Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.
In case this helps... This occurs in ArchLinux using a kernel built with bitbytebit's GroovyLinux patches on an AVGA3000 with the stock open source ATI driver feeding a 25" Wells-Gardner k7191.
I've seen that happen when running GroovyMAME on my PC monitor with a normal video card, but when running on my arcade cabinet (Windows XP x64 + ArcadeVGA 3000 + Hantarex Polo 25), I've never seen it happen unless GroovyMAME loses focus.
What specific games do this in your build? I'd like to try them on my setup with the stock Windows GroovyMAME build (groovymame64_0142.012o) to see if I can reproduce it.
-
Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.
The multithreading full-speed issue was fixed before and was even added to the mainline Mame, so I'm not sure what this new problem could be. Probably is due to how -waitvsync is managed, but it's sure it has worked before. Please post a complete log by running a game with the -v -md 4 params so we can have a look.
Yes, for me Highscores stopped working in the test versions but do work fine in my compile of groovymame (from the supplied diff)
For some reason I can't get my hiscores recorded even with the "official" groovymame. Testing 1942a, must be doing something wrong (hiscore.dat is in the same folder as Mame.exe, hiscore_directory hi, deleted .nv files, hiscore patch enabled...)
-
I've seen that happen when running GroovyMAME on my PC monitor with a normal video card, but when running on my arcade cabinet (Windows XP x64 + ArcadeVGA 3000 + Hantarex Polo 25), I've never seen it happen unless GroovyMAME loses focus.
What specific games do this in your build? I'd like to try them on my setup with the stock Windows GroovyMAME build (groovymame64_0142.012o) to see if I can reproduce it.
You may be onto something with the "losing focus" deal. I'm not using a window manager - just plain old X. I autologin using SLiM, and then launch wahcade -f from .xinitrc. It works great, however I'm not really sure how window focus is handled when no window manager is used. I'll try installing a window manager to see if it makes a difference.
Several (all?) games that use neodrvr.c suffer from this "bug." In particular I observed it with Twinkle Star Sprites (twinspri). I also observed it with DonPachi (donpachi) which uses cave.c.
Please post a complete log by running a game with the -v -md 4 params so we can have a look.
I will do that once I get home.
-
You may be onto something with the "losing focus" deal. I'm not using a window manager - just plain old X. I autologin using SLiM, and then launch wahcade -f from .xinitrc. It works great, however I'm not really sure how window focus is handled when no window manager is used. I'll try installing a window manager to see if it makes a difference.
It could be due to Mame not getting access to the vysnc features. When GroovyMame considers the calculated refresh is close enough to the target one it disables the throttle option and just uses waitvsync as a timer, but if for some reason vsync is not working it will make it run fullspeed. But it's strange that it just happens with multithreading enabled. Try glxgears to see if vsync works.
-
Yes, for me Highscores stopped working in the test versions but do work fine in my compile of groovymame (from the supplied diff)
jimmy2x2x, try moving hiscore.dat inside the "hi" directory, I think that's necessary once 0142_hilinux.diff is applied.
-
Mame 0.143 is out ;) It would be a great start for the new forum if you guys are ready?
I will test the highscore today and let you know.
Thanks
-
You may be onto something with the "losing focus" deal. I'm not using a window manager - just plain old X. I autologin using SLiM, and then launch wahcade -f from .xinitrc. It works great, however I'm not really sure how window focus is handled when no window manager is used. I'll try installing a window manager to see if it makes a difference.
It could be due to Mame not getting access to the vysnc features. When GroovyMame considers the calculated refresh is close enough to the target one it disables the throttle option and just uses waitvsync as a timer, but if for some reason vsync is not working it will make it run fullspeed. But it's strange that it just happens with multithreading enabled. Try glxgears to see if vsync works.
As usual, I was over-thinking the problem. After successfully compiling GroovyMame, I generated the default config (per the documentation). I tested it the default config, and found out that it worked... So I decided to start changing things (because I'm a chronic tinkerer). In any event, I discovered that many (but not all) games suffer from speedup under the following scenarios:
waitvysnc 1
syncrefresh 0
multithreading 1
waitvysnc 0
syncrefresh 0
multithreading 1
The problem does not appear with multithreading 0. This obviously has something to do with the way Groovymame handles waitvsync (as described earlier in the thread). I would also guess that toggling triplebuffer and throttle may have an effect here.
Anyway - I'm sorry for n00bing up the thread with my incompetence. That said, I still think the multithreading link is an interesting one. I wouldn't have guessed that it would have an effect on any of the above options.
-
The problem does not appear with multithreading 0. This obviously has something to do with the way Groovymame handles waitvsync (as described earlier in the thread). I would also guess that toggling triplebuffer and throttle may have an effect here.
So in order to make it work all the time you need to have -syncrefresh enabled?
I don't know the SDL part as well as the Windows one as far as the vsync options are concerned, I'll have a look anyway.
The triplebuffer option has no effect under Linux, AFAIK.
I'm trying to port the groovymame patches to the 0.143 version, let's see if it works...
-
So in order to make it work all the time you need to have -syncrefresh enabled?
Correct.
I'm trying to port the groovymame patches to the 0.143 version, let's see if it works...
Can't hardly wait!
-
;D I was uploading my Groovymame 0.143 binary just to realize that bitbytebit already has the new diff here: http://mario.groovy.org/GroovyMame/0143/ (http://mario.groovy.org/GroovyMame/0143/)
-
Brilliant!
Does that .diff include all your recent changes Calamity?
Thanks
-
Brilliant!
Does that .diff include all your recent changes Calamity?
Thanks
No, I assume those are the .12o patches adapted to 0.143.
I'm removing my diff in http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/) to avoid confusions.
I'll add the experimental test patches to this one as soon as I can.
-
Just uploaded 0143.013 version of groovymame :). I had time to build the patch, binaries and patches are up now.
Calamity, let me know any diffs possibly that you have worked on and I will include those, if you feel they are ready. I haven't been paying much attention to the threads here but saw mame 0143 came out last night and so have updated the patches for it, but see you've been getting some things improved to fix the frogger issues and possibly others, looks exciting.
ISO's will be up in a day or two most likely.
-
Does the (do the) owner (owners) of GroovyMame want a dedicated subforum?
-
Does the (do the) owner (owners) of GroovyMame want a dedicated subforum?
Sure, that sounds good to me, guessing Calamity probably feels the same.
-
Just uploaded 0143.013 version of groovymame :). I had time to build the patch, binaries and patches are up now.
Thanks! I compiled yesterday, and things are working smoothly.
-
bitbytebit: is 0143_hilinux.diff required for windows builds?
Thanks
-
bitbytebit: is 0143_hilinux.diff required for windows builds?
Thanks
Yes, you need to apply all of them even if you're going to make a windows build, otherwise the groovymame.diff will fail to apply.
-
Interesting, it will compile without it for me.
Without 0143_hilinux.diff (base 0.143 + hi_143.txt + 0143_groovymame.diff)
hiscores work as expected
screen rotation works as per stock mame
With 0143_hilinux.diff (base 0.143 + hi_143.txt + 0143_hilinux.diff + 0143_groovymame.diff)
hiscore.dat has to be in the hi folder, otherwise hiscores will not work
screen rotation is upside down for me (vertical monitor), rotating 90 CW in tab/video options menu fixes this but leaves the gui upside down. I think you have to do this for each game, as I cant seem to get it right with mame.ini settings. (Calamity fixed this issue for 0.142, is this .diff essential?)
Thanks
-
Just uploaded 0143.013 version of groovymame :). I had time to build the patch, binaries and patches are up now.
Calamity, let me know any diffs possibly that you have worked on and I will include those, if you feel they are ready. I haven't been paying much attention to the threads here but saw mame 0143 came out last night and so have updated the patches for it, but see you've been getting some things improved to fix the frogger issues and possibly others, looks exciting.
ISO's will be up in a day or two most likely.
I've attached the diff file with the fixes I've been doing, this must be applied over after the 0143_groovymame.diff in order to work.
I'm going to sum up the different fixes before I forget about the details. Feel free to add or drop all or part of them:
emu\render.c
------------
- Moved changeres code from "render_target::get_primitives()" to "compute_visible_area", this fixes an issue when minimazing/maximizing the window that invoked many false changeres events that made this process very slow. Also, doing this fixes the aerofgts issue when displayed fullscreen on vertical monitor.
- Removed the frogger/galaxian fix
- TO DO: fix the changeres patch for the case of a vertical game displayed on horizontal monitor which changes resolutions (i.e. aerofgts). The issue here is that after a resolution change the display size obtained by the changeres patch is already rotated, say 240 x 320, but as the stored game info says it's a vertical game, the resolution is rotated again in the modeline generator producing a chopped display.
emu/switchres/switchres.c
-------------------------
- Changed the rotate options from autol, rol, to autoror, ror, as this the usual orientation for rotated monitors, otherwise the display was upside down, however it would be nice to have an option for this eventually.
/mame/drivers/galaxian.c
/mame/includes/galaxian.h
-------------------------
- Patch for galaxian/frogger. I was reluctant to patch anything on the mame part of the source code, but this patch is so simple it seems that mame devs already thought of this possibility. Actually it would be enougth to change the GALAXIAN_XSCALE constant in galaxian.h if it wasn't because some "3" values are hardcoded in galaxian.c.
/osd/windows/switchres.c
------------------------
- Commented out the part where it orders the mode table, as the swap function was not swapping the string labels, corrupting the mode table if the mode list returned by the system is not perfectly ordered already. This one was hard to figure out.
- In the find_best_mode algorithm, now interlaced resolutions are not penalized if we are looking for a virtualized resolution (I added this at some point trying to fix an issue though I'm not sure it's really necessary).
/osd/windows/window.c
-----------------------
- All the changes in this file are experimental for the new blitting thread method, so can be safely discarded, though I've come to a point where it's really stable here, so would be glad if someone wants to test (this patch was already included in the test version some people here have been using).
For a brief explanation: normal mame, when in multithreading mode, uses two processing threads: main thread and window thread. The idea is that the main thread handles the emulator thing, while the window thread deals with input and output (video). Everything is fine with this design unless you decide to vsync. As the vsync functionality is inside the video part this means that waiting for vsync freezes the window thread during instant, locking the window for input, enough to cause a noticeable input lag.
On the other hand normal Groovymame patches partially fix this issue for -syncrefresh by performing the wait in the main thread, but unfortunately -triplebuffer is still done in the window thread to allow for asynchronous blitting, keeping some input lag that's specially bad when native refresh is very different than the achieved one (60Hz vs 53Hz modeline). Additionally, this situation causes visual artifacts as more or less intermittent flashing.
Finally, this new patch uses three different threads: main thread (emulator, as always), window thread (input), and blitting thread (video). This way, we always wait for vsync in a separate thread, leaving the window thread free to process input as it comes, and additionally we can achieve a totally asynchronous -triplebuffer without video artifacts nor any input lag penalty. At least this is the idea. I don't mean this is the best possible implementation, there might be some issues left with the maximizing/minimizing process, but I think that at some point Mame devs should consider to make input and video threads trully independent to improve the emulator experience.
-
Can I apply those fixes now, or do they need to be integrated with the 0143_groovymame.diff?
-
Can I apply those fixes now, or do they need to be integrated with the 0143_groovymame.diff?
You can apply them right after the 0143_groovymame.diff (make sure to have applied the hi_linux diff before)
-
ok, tried that with mame compiler 64 v1.22
base 0.143 + hi_143.txt + 0143_hilinux.diff + 0143_groovymame.diff
(all fine)
then
0143_groovymame_fixes.diff
gives this output:
Applying Diff Patch...
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/emu/render.c c/src/emu/render.c
|--- b/src/emu/render.c 2011-06-29 20:28:44.000000000 +0200
|+++ c/src/emu/render.c 2011-06-29 20:54:13.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Finished!
0 Hours 0 Minutes and 0 Seconds Elapsed.
Skipping patch.
6 out of 6 hunks ignored
can't find file to patch at input line 116
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/emu/switchres/switchres.c c/src/emu/switchres/switchres.c
|--- b/src/emu/switchres/switchres.c 2011-06-29 20:28:44.000000000 +0200
|+++ c/src/emu/switchres/switchres.c 2011-06-29 20:45:35.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 144
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/mame/drivers/galaxian.c c/src/mame/drivers/galaxian.c
|--- b/src/mame/drivers/galaxian.c 2011-05-12 00:50:02.000000000 +0200
|+++ c/src/mame/drivers/galaxian.c 2011-06-29 21:22:30.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
3 out of 3 hunks ignored
can't find file to patch at input line 174
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/mame/includes/galaxian.h c/src/mame/includes/galaxian.h
|--- b/src/mame/includes/galaxian.h 2011-04-27 07:11:20.000000000 +0200
|+++ c/src/mame/includes/galaxian.h 2011-06-29 21:23:38.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 186
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/osd/windows/switchres.c c/src/osd/windows/switchres.c
|--- b/src/osd/windows/switchres.c 2011-06-29 20:28:45.000000000 +0200
|+++ c/src/osd/windows/switchres.c 2011-06-29 21:02:04.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
6 out of 6 hunks ignored
can't find file to patch at input line 253
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/osd/windows/window.c c/src/osd/windows/window.c
|--- b/src/osd/windows/window.c 2011-06-29 20:28:45.000000000 +0200
|+++ c/src/osd/windows/window.c 2011-06-29 21:16:27.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
19 out of 19 hunks ignored
-
Does the (do the) owner (owners) of GroovyMame want a dedicated subforum?
Hi Saint,
Yes, it would be great to have a dedicated subforum for GroovyMame, if you think it's a good idea, and probably move the Switchres thread and this one into there so we have something to start with. Newcomers will find information easier, as now there's a lot of valuable information buried in these threads that's difficult to find when needed even for us.
Thanks,
Calamity
-
Yes, it's not finding the files because I made the diffs against my source trees that ares b/src and c/src, so if you remove the b/ and c/ from diff lines it should work.
-
Yes, it's not finding the files because I made the diffs against my source trees that ares b/src and c/src, so if you remove the b/ and c/ from diff lines it should work.
That worked, now compiling ;)
Thanks Calamity
-
all done, looks great so far
I have found a couple of bits, but I will hold off until the new forum is up and running ;)
-
all done, looks great so far
I have found a couple of bits, but I will hold off until the new forum is up and running ;)
Great!
I'm travelling abroad for some days so I'll probably be disconnected, will be back next week.
-
Just uploaded 0143.013 version of groovymame :). I had time to build the patch, binaries and patches are up now.
Calamity, let me know any diffs possibly that you have worked on and I will include those, if you feel they are ready. I haven't been paying much attention to the threads here but saw mame 0143 came out last night and so have updated the patches for it, but see you've been getting some things improved to fix the frogger issues and possibly others, looks exciting.
ISO's will be up in a day or two most likely.
I've attached the diff file with the fixes I've been doing, this must be applied over after the 0143_groovymame.diff in order to work.
I'm going to sum up the different fixes before I forget about the details. Feel free to add or drop all or part of them:
emu\render.c
------------
- Moved changeres code from "render_target::get_primitives()" to "compute_visible_area", this fixes an issue when minimazing/maximizing the window that invoked many false changeres events that made this process very slow. Also, doing this fixes the aerofgts issue when displayed fullscreen on vertical monitor.
- Removed the frogger/galaxian fix
- TO DO: fix the changeres patch for the case of a vertical game displayed on horizontal monitor which changes resolutions (i.e. aerofgts). The issue here is that after a resolution change the display size obtained by the changeres patch is already rotated, say 240 x 320, but as the stored game info says it's a vertical game, the resolution is rotated again in the modeline generator producing a chopped display.
emu/switchres/switchres.c
-------------------------
- Changed the rotate options from autol, rol, to autoror, ror, as this the usual orientation for rotated monitors, otherwise the display was upside down, however it would be nice to have an option for this eventually.
/mame/drivers/galaxian.c
/mame/includes/galaxian.h
-------------------------
- Patch for galaxian/frogger. I was reluctant to patch anything on the mame part of the source code, but this patch is so simple it seems that mame devs already thought of this possibility. Actually it would be enougth to change the GALAXIAN_XSCALE constant in galaxian.h if it wasn't because some "3" values are hardcoded in galaxian.c.
/osd/windows/switchres.c
------------------------
- Commented out the part where it orders the mode table, as the swap function was not swapping the string labels, corrupting the mode table if the mode list returned by the system is not perfectly ordered already. This one was hard to figure out.
- In the find_best_mode algorithm, now interlaced resolutions are not penalized if we are looking for a virtualized resolution (I added this at some point trying to fix an issue though I'm not sure it's really necessary).
/osd/windows/window.c
-----------------------
- All the changes in this file are experimental for the new blitting thread method, so can be safely discarded, though I've come to a point where it's really stable here, so would be glad if someone wants to test (this patch was already included in the test version some people here have been using).
For a brief explanation: normal mame, when in multithreading mode, uses two processing threads: main thread and window thread. The idea is that the main thread handles the emulator thing, while the window thread deals with input and output (video). Everything is fine with this design unless you decide to vsync. As the vsync functionality is inside the video part this means that waiting for vsync freezes the window thread during instant, locking the window for input, enough to cause a noticeable input lag.
On the other hand normal Groovymame patches partially fix this issue for -syncrefresh by performing the wait in the main thread, but unfortunately -triplebuffer is still done in the window thread to allow for asynchronous blitting, keeping some input lag that's specially bad when native refresh is very different than the achieved one (60Hz vs 53Hz modeline). Additionally, this situation causes visual artifacts as more or less intermittent flashing.
Finally, this new patch uses three different threads: main thread (emulator, as always), window thread (input), and blitting thread (video). This way, we always wait for vsync in a separate thread, leaving the window thread free to process input as it comes, and additionally we can achieve a totally asynchronous -triplebuffer without video artifacts nor any input lag penalty. At least this is the idea. I don't mean this is the best possible implementation, there might be some issues left with the maximizing/minimizing process, but I think that at some point Mame devs should consider to make input and video threads trully independent to improve the emulator experience.
Looks great, I added this into the git and the patch file is updated. I'm building windows executables now and should be up as version 0143.013a with this changes shortly. I like the frogger fix, amazing, that's definitely the right way to do it.
-
Does anyone know what setting I should choose for the Betson 27" Multisync monitor?
Thanks in advance...
D
-
Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.
I am also experiencing this issue. The game I'm testing all this on it UMK3. However, I noticed that when you press the tab key to bring up the options, the game returns to normal speed. Press Tab again and it's breakneck speed again.
-
Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.
I am also experiencing this issue. The game I'm testing all this on it UMK3. However, I noticed that when you press the tab key to bring up the options, the game returns to normal speed. Press Tab again and it's breakneck speed again.
Set:
multithreading 0
syncrefresh 0
or
multithreading 1
syncrefresh 1
As for settings - this review (http://retroblast.arcadecontrols.com/reviews/betson2.html) links to a service manual for your monitor:
http://retroblast.arcadecontrols.com/files/KT-XX14X-SM.pdf (http://retroblast.arcadecontrols.com/files/KT-XX14X-SM.pdf)
I don't have time to look closely at the moment, but hopefully there will be enough information there to setup a custom monitor_specs line in mame.ini formatted as follows:
HfreqMin-HfreqMax,VfreqMin-VfreqMax,HfrontPorch,HsyncPulse,HbackPorch,VfrontPorch,VsyncPulse,VbackPorch,HorPolarity,VerPolarity,ActiveLinesLimit,VirtualLinesLimit
Example (from my config):
monitor_specs0 15100.00-16800.00,47.00-63.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288,448
EDIT: I should mention that it is possible to damage your display by editing these settings - so be very sure, and very careful before you start plugging in strange numbers.
-
Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.
I am also experiencing this issue. The game I'm testing all this on it UMK3. However, I noticed that when you press the tab key to bring up the options, the game returns to normal speed. Press Tab again and it's breakneck speed again.
Is this the same type of issue that I was experiencing with Wayne Gretksty 3D Hockey & Mace...? They ran at 200-400% until I tabbed the menu screen...then it backed down to 100%. It never was resolved so I wrote these two games off...
-
Have you tried toggling throttle on/off?
-
Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.
I am also experiencing this issue. The game I'm testing all this on it UMK3. However, I noticed that when you press the tab key to bring up the options, the game returns to normal speed. Press Tab again and it's breakneck speed again.
As a quick fix, try enabling -triplebuffer, that should make the games run at normal speed.
Anyway that's not the solution. I really need to know if that issue happened before with GroovyMame v0.142 or has been introduced with the new patch present in v.0143.
It's likely that ddraw acceleration is not enabled in your system. Unlike vanilla Mame, GroovyMame relies absolutely in the vsync feature of your video card to properly achieve correct timing, so if the vsync feature is missing (ddraw acceleration disabled), it will result in the emulator running full speed.
Run dxdiag, screen tab, and check if ddraw acceleration is enabled.
-
Is this the same type of issue that I was experiencing with Wayne Gretksty 3D Hockey & Mace...? They ran at 200-400% until I tabbed the menu screen...then it backed down to 100%. It never was resolved so I wrote these two games off...
That should be a different issue, as the one you are referring affects the Linux version if I'm right, and only to these games that share the same driver and resolution (640x480@57). Unfortunately they are chd games which I don't have here to test, however I'll try to get them, thanks for reminding that.
-
Make sure you donate too. I encourage anyone who is using GroovyMAME and/or the custom ATI drivers to donate.
I donated and don't even use it.
-
hi,
im currently using advance mame for Dos and also a later hacked version of vsync mame,
just wondering ,would this groovymame be nearly as good for getting the right resolutions
and smoothness?,im v.happy with what ive got but there is always room for improvement.
-
hi,
im currently using advance mame for Dos and also a later hacked version of vsync mame,
just wondering ,would this groovymame be nearly as good for getting the right resolutions
and smoothness?,im v.happy with what ive got but there is always room for improvement.
Could try the ISO liveCD to see, and from that choose if it's worth it and if to use Windows or Linux. The liveCD should give a quick view of if things are going to be acceptable or not, then from there Windows is close to the same and Linux installs are a duplicate in how it'll look.
-
cheers,ive been watching these threads about this project for a while,
i was thinking sooner or later a better way of dealing with mame resolutions must
come!, there are some really nice front ends and things under windows too,
so i will have to try when i get some time.
-
Can GroovyMame be used on an Nvidia card?? I know it wont be able to do the generated resolutions, but want to use it for the timing and screen tearing tweaks that is uses??
I would suggest that if this discussion goes anywhere, it should be branched into its own thread.
-
Hello,
thx for this, i can't use groovymame on WIn7 (and i know why), but hyperspin launch fine with soft CRT driver AND soft 15khz (not without)!
Don't know why :cheers: but advmame run fine too ^^ (pretty impressive since vgawin doesn't like soft 15khz) :)
i don't like Xp, so, any version for win7 coming soon??
Really want to test GM, even if i 've calculate my modelines
Thx for your hard work !!
sorry for my english
cheers from France
-
Hi,
Hello,
thx for this, i can't use groovymame on WIn7 (and i know why), but hyperspin launch fine with soft CRT driver AND soft 15khz (not without)!
If you run Soft-15Khz over CRT_Emudriver it will install its own list of video modes, around a total of 30 I believe, so that's why HS works, because the list is much shorter. Keep in mind that CRT_Emudriver is just a slightly hacked Catalyst driver in order to allow more than 100 video modes, so if you're only going to use 30 then you'd better stick to regular Catalyst drivers (GroovyMAME will still work, although not that cool).
Don't know why :cheers: but advmame run fine too ^^ (pretty impressive since vgawin doesn't like soft 15khz) :)
i don't like Xp, so, any version for win7 coming soon??
Really want to test GM, even if i 've calculate my modelines
Thx for your hard work !!
sorry for my english
cheers from France
Even if not posting much lately I'm still actively researching the video mode subject in case there's room for any breakthrough. However, I'm still focusing on WinXP and ATI cards. The reason is practical: there's a limitation in the platforms I can test simultaneously. In order to get consistent results, the tests need to be painstaking. It's even a nightmare to support four versions of the same thing (XP 32/64, 6.5/9.3).
We need to understand that operating systems and their video drivers are not designed to allow what we are doing here. Even if our desire would be to support all cards and operating systems, that gets really difficult to achieve for a project like this. Win7 is not appealing a priori because it sets even more restrictions than WinXP. However, this is an open source project so anyone could research on that system and eventually add support for it.
-
If you run Soft-15Khz over CRT_Emudriver it will install its own list of video modes, around a total of 30 I believe, so that's why HS works, because the list is much shorter. Keep in mind that CRT_Emudriver is just a slightly hacked Catalyst driver in order to allow more than 100 video modes, so if you're only going to use 30 then you'd better stick to regular Catalyst drivers (GroovyMAME will still work, although not that cool).
ok, thanks for this explanation :) but arcade os give me 162 modeline and HS word :)
anyway If i could help, i will do, but im just a noob in code :)
merci !
-
ok, thanks for this explanation :) but arcade os give me 162 modeline and HS word :)
That's interesting. So you used a custom modeline list for Soft-15khz?
-
Hello,
Yeah, create my custom list for my monitor, calculate and try with modeline soft under winxp. Hyperspin doesn't lauch under Xp but work on win7 with your driver and soft15khz.
cheers
-
Hello,
Yeah, create my custom list for my monitor, calculate and try with modeline soft under winxp. Hyperspin doesn't lauch under Xp but work on win7 with your driver and soft15khz.
cheers
Are you using CRT_Emudriver with Win7???!!!! Please tell me more, which version? does it even install there?
How many modelines are you using for your custom modeline list?
-
hello,
Are you using CRT_Emudriver with Win7???!!!! Please tell me more, which version? does it even install there?
i just install the driver (force it, not recognized with setup.exe 9.3X 32 bits).
How many modelines are you using for your custom modeline list?
will tell you later work for now.
cheers
update Arcade OSD:
54 modelines for my personnal usermodes soft 15 khz:
crt drivers : 202 modelines (arcade OSD) hyperspin failed
crt drivers + soft 15 khz (54 modelines) : total 142 modelines (arcade OSD) hyperspin OK
modelines generates with Vmmaker (a lot) + usermodes (personnal) + crt drivers: total 162 modelines hyperspin works
used modeline for custom freq eg double dragon @ 57 khz
-
Can you detail what you did to force win7 to accept Calamiy's driver? I'm using the linux groovymame, but I have another pc just begging to be put to good use.
Which driver were you using. ver 6.XX or ver 9.XX ??
-
Can you detail what you did to force win7 to accept Calamiy's driver? I'm using the linux groovymame, but I have another pc just begging to be put to good use.
Which driver were you using. ver 6.XX or ver 9.XX ??
9.xx for hd4350, device manager, upgrade driver and point the *.inf :)
-
An idea what monitor i should select in the mame.ini file for my Pentranic 29" Multi-sync monitor?? These are the only spec i could find in the pdf manual...
(http://img638.imageshack.us/img638/932/penav.jpg) (http://imageshack.us/photo/my-images/638/penav.jpg/)
Or though it states 800x600 it actually does 1024x768
-
Just done a fresh install of windows xp on my mame cab. And have installed groovyMame and installed the 9.3 custom drivers for my 4 series ATI card. But i dont appear to be getting scanlines on the games, for instance when loading Aliens, dos reports that switchres is stating the game as 288x224@60.00 but my monitor reports its displaying 640x480. Do i need to change anything in the default created mame.ini file??
EDIT: Sorted now need to run VMmaker.exe
-
Is there a work around yet to get the CRT_EmuDriver 9.3 xp 32bit drivers to work with HyperSpin??
-
They do work with Hyperspin, just at a lower limit of mode lines.
Edit VMMaker to limit the lines to somewhere around 90; run, reboot, launch HS. If it works, bump it up by 10. Keep going until HS fails to load, then back it down until it works. I'm not sure if it's been pinned down why there is a variable number of lines that HS will work with under various configurations.
-
I'm not sure if it's been pinned down why there is a variable number of lines that HS will work with under various configurations.
Hyperspin uses a product called SWF Studio from Northcode, Inc. ( http://www.northcode.com/ (http://www.northcode.com/) ).
SWF Studio takes an Adobe Flash SWF file and turns it into a Windows executable by wrapping it in a Flash runtime environment. The environment has hooks that you can use to allow your SWF to interact with the outside world including graphics, sound, and interface controls.
My understanding is that there is a problem where the SWF Studio flash runtime crashes when enumerating resolutions when the number is too high. I don't know if this issue has been reported to Northcode as the Hyperspin folks are fairly tight-lipped regarding their development.
I wish that I had the time and/or resources to develop some test cases to help nail down this bug for Northcode. My gut feeling as a software developer is that this is some sort of overflow issue. Possibly they didn't allocate a large enough array to hold the list of resolutions or something along those lines.
-
Right, but why would different numbers overflow on various systems? That was more my point than "we don't know why it crashes".
Has anyone contacted Northcode and just asked "Hey, got an app crashing when there's lots of resolutions. Think its the compiler or the end program?"
-
I wish that I had the time and/or resources to develop some test cases to help nail down this bug for Northcode. My gut feeling as a software developer is that this is some sort of overflow issue. Possibly they didn't allocate a large enough array to hold the list of resolutions or something along those lines.
I'm almost sure that's the issue indeed, because after spending some time debugging HS I found that when the crash happens the EnumDisplaySettings API address is still shown in the stack, so it seems it crashes right after that function is called. The problem is, as you say, that the bug might probably be located in some external library they're using. So if a fixed array is used, it's likely to be overflowed as the number of video modes more than doubles the ones you'll expect to find in a normal system.
I uploaded somewhere in this thread a possible workaround, a modified version of VMMaker that allows to only create 32 bit modes, so this shortens the list quite a lot a probably help in some cases. I don't know if someone else than cotmm68030 actually tested it. I'll repost it within the next days in a separate thread.
Probably, the reason why different number of modes work in different systems is that the actual total number of modes changes depending on your setup, so even if we always add 120 custom modes, the driver will add some native modes, and depending on the monitor's edid some of them will be added or not.
The driver has a built in mechanism to allow the user restrict some modes, but due to the nature of the patch, in version 9.3 I needed to disable that feature, that's why we can't restrict those unneeded modes.
There is a way I'd like to explore at some point, it's to create a custom edid to override the one in the monitor, that would be an alternate way to tell the driver which modes we don't want.
At the moment, I'm concentrating in finding a way to enable custom resolutions on the fly, without rebooting. This would solve all the problems once and forever, as we wouldn't need to store a precalculated mode list any more. The probabilities of success are scarce, but anyway... I've dropped a message on the AMD board, in case there's someone on the other side:
http://forums.amd.com/devforum/messageview.cfm?catid=347&threadid=153032&enterthread=y (http://forums.amd.com/devforum/messageview.cfm?catid=347&threadid=153032&enterthread=y)
AMD drivers have an API called ADL that allows enabling custom resolutions on the fly, indeed, since Catalyst 9.3. We have some problems however:
- Available headers (2.0 and 3.0) don't seem to work with old Catalyst 9.3
- Even if they worked, this API rejects anything below 640x480
-
I'm almost sure that's the issue indeed, because after spending some time debugging HS I found that when the crash happens the EnumDisplaySettings API address is still shown in the stack, so it seems it crashes right after that function is called. The problem is, as you say, that the bug might probably be located in some external library they're using. So if a fixed array is used, it's likely to be overflowed as the number of video modes more than doubles the ones you'll expect to find in a normal system.
EnumDisplaySettings is part of the Windows API...
http://msdn.microsoft.com/en-us/library/dd162611%28v=VS.85%29.aspx (http://msdn.microsoft.com/en-us/library/dd162611%28v=VS.85%29.aspx)
The SWF Studio runtime "wrapper" does all the interaction with the underlying operating system, so I'm fairly certain that's where the bug lies.
What I'm not sure of is whether the bug still exists in the latest version of SWF Studio. For all I know, this bug may have been reported and fixed a long time ago, but still after the latest version of Hyperspin.
I uploaded somewhere in this thread a possible workaround, a modified version of VMMaker that allows to only create 32 bit modes, so this shortens the list quite a lot a probably help in some cases. I don't know if someone else than cotmm68030 actually tested it. I'll repost it within the next days in a separate thread.
I'll have to check that out.
-
Some bugs fixed, I've attached a diff...
- Fixed this issue:
- TO DO: fix the changeres patch for the case of a vertical game displayed on horizontal monitor which changes resolutions (i.e. aerofgts). The issue here is that after a resolution change the display size obtained by the changeres patch is already rotated, say 240 x 320, but as the stored game info says it's a vertical game, the resolution is rotated again in the modeline generator producing a chopped display.
- Fixed an existing bug when using multiple monitor_specs lines, now all of them are actually used.
- Fixed possible bug in the m2929 monitor definition.
-
I've opened a new thread for reporting problematic games in GroovyMAME:
http://forum.arcadecontrols.com/index.php?topic=113382.0 (http://forum.arcadecontrols.com/index.php?topic=113382.0)
Please use that one so the bugs you find are not forgotten and can be addressed at some point. I remind krick reported Gauntlet Legends and possibly some others.
-
Some bugs fixed, I've attached a diff...
- Fixed this issue:
- TO DO: fix the changeres patch for the case of a vertical game displayed on horizontal monitor which changes resolutions (i.e. aerofgts). The issue here is that after a resolution change the display size obtained by the changeres patch is already rotated, say 240 x 320, but as the stored game info says it's a vertical game, the resolution is rotated again in the modeline generator producing a chopped display.
- Fixed an existing bug when using multiple monitor_specs lines, now all of them are actually used.
- Fixed possible bug in the m2929 monitor definition.
Thanks, I've updated the git repository and patch with these changes, binaries will be up shortly.
-
I've attached a patch that should fix the Gauntlet Legends issue. It just forces to refresh the video options (hwstretch, etc.) right after new modeline is calculated. I think the same thing should be done on the Linux side.
-
What's the d2929 issue?
-
What's the d2929 issue?
Bug in way I added the definition, so it wasn't being setup for the most part.
-
Hi guys
Groovymame really is an awesome piece of work.
Please could someone help me out with monitor settings for a Hantarex Polo?
The service manual doesn't give a lot away.
Many thanks
-
Please could someone help me out with monitor settings for a Hantarex Polo?
I'm running a Hantarex Polo 25. It's a standard 15KHz arcade monitor so the default GroovyMAME settings work great.
The only thing I usually enable that isn't enabled by default is the "SoundSync" option.
-
Thank you for your reply krick :)
Would I need to set the MonitorType in VMMaker.ini to GENERIC? or do I not need to run VMMaker at all?
Also I'm getting lots of screen tearing even after enabling SoundSync. I do not get this tearing in CabMame143. Perhaps this is because I set SyncRefresh and Multithreading to 0 due to having the issue where games run too fast. Any ideas?
P.S I'm new here, so thank you for being so welcoming.
-
Would I need to set the MonitorType in VMMaker.ini to GENERIC? or do I not need to run VMMaker at all?
Also I'm getting lots of screen tearing even after enabling SoundSync. I do not get this tearing in CabMame143. Perhaps this is because I set SyncRefresh and Multithreading to 0 due to having the issue where games run too fast. Any ideas?
I have never run VMMaker. I've run GroovyMAME two ways...
1) ArcadeVGA 3000 + Ultimarc drivers
2) Generic ATI card + CRT_EmuDriver (http://mame.groovy.org/WindowsATIDrivers/)
Both work great with GroovyMAME. In fact, option #2 is a little better in terms of accuracy, but it is not compatible with Hyperspin FE due to too many resolutions. So I'm sticking with my ArcadeVGA for now.
You should rename your old mame.ini file and create a clean, new one by running...
GroovyMAME -cc
...from the command line in your MAME directory.
As long as your games run full screen, GroovyMAME should sync to the monitor refresh rate and prevent the games from running too fast.
-
Thank you for your reply krick :)
Would I need to set the MonitorType in VMMaker.ini to GENERIC? or do I not need to run VMMaker at all?
Also I'm getting lots of screen tearing even after enabling SoundSync. I do not get this tearing in CabMame143. Perhaps this is because I set SyncRefresh and Multithreading to 0 due to having the issue where games run too fast. Any ideas?
P.S I'm new here, so thank you for being so welcoming.
Hi Higgs79,
The settings for Hantarex MTC 9110 (H9110) might more or less be fine for you. Select that MonitorType, run VMMaker and reboot.
The soundsync option can't be causing any screen tearing by itself. Make sure the directdraw acceleration is enabled (run dxdiag, check screen tab). If its disabled, that's the cause of all the other issues: you need to reinstall the drivers until directdraw acceleration works (use catunistaller, etc.). You may need to repeat the process several times.
-
The settings for Hantarex MTC 9110 (H9110) might more or less be fine for you. Select that MonitorType, run VMMaker and reboot.
Calamity,
I'm confused. Why does he need to run VMMaker at all?
When I was using a generic ATI card with my Hantarex Polo 25, I just installed your custom ATI drivers and ran GroovyMAME with the default settings and it worked great for the games that I tried. I never ran VMMaker. Should I have?
-
Well, that's not really necessary, just convenient. If you use the default settings, generic CGA monitor timings are used, that means you are constrained to a narrower hfreq range around 15.7 kHz, what is fine for most games.
However, if you are possitive your monitor supports a wider range of hfreq then it's worth setting GroovyMAME so that it makes use of that extra horizontal frequency available. This is highly useful for running vertical games on horizontal monitor closer to their native vfreq.
For instance, 1942 won't run at 60 Hz with CGA settings. 256 are too many lines, it will only reach 58 Hz or so. However, if you use the H9110 settings, that game will be rendered at 16.6 kHz hfreq, so it will run at exact 60 Hz.
Anyway this can be selected from mame.ini, so why running VMMaker?
The reason is that the optimal video mode list is monitor dependent. In Windows, GroovyMAME can't create video modes on the fly, it (unfortunately) needs to rely on the list of modes available on the system. If we change the monitor type settings, GroovyMAME will be expecting a somewhat different mode list.
Although it can work just fine with the existing one most of the time (as well as using a fixed table as with the AVGA3000), it's a good idea to recalculate the mode list. This is specially true for "virtualized" resolutions.
Virtualized resolutions (interlaced + stretched) are used by vertical games which number of lines exceeds our monitor's capabilities. We need as much vertical resolution as our monitor can give us, so those resolutions are chosen by VMMaker/GroovyMAME depending on our monitor's definition.
Games like twincobr or donpachi, look incredibly better when using the H9110 settings on a monitor that supports that, than with the default settings, although you'd probably need to adjust your vertical amplitude potenciometer to get all the lines into the screen.
-
Well, that's not really necessary, just convenient. If you use the default settings, generic CGA monitor timings are used, that means you are constrained to a narrower hfreq range around 15.7 kHz, what is fine for most games.
However, if you are possitive your monitor supports a wider range of hfreq then it's worth setting GroovyMAME so that it makes use of that extra horizontal frequency available. This is highly useful for running vertical games on horizontal monitor closer to their native vfreq.
Hmmm... Makes sense.
The obvious next question is how can one be positive that their monitor supports a wider range of hfreq?
My monitor is an original "Polo", not a "Polo/2", "Polo/3", or "PoloStar".
According to this Hantarex Polo manual, which I believe is the correct one...
http://mame.3feetunder.com/byoac/hantarex_polo.pdf (http://mame.3feetunder.com/byoac/hantarex_polo.pdf)
...it supports...
Horizontal 15,700 ± 500 Hz adjustable
Vertical 45-65 Hz adjustable
-
Calamity - Many thanks for the excellent explanation.
When running groovymame with a fresh mame.ini I do get games running too fast. That said I have not yet checked whether directdraw acceleration is enabled. This may take me a while as I'm using an nlited and minlogon'd install of xp and dxdiag has been stripped out :(
krick - If you do manage to find correct specs for the hantarex polo I will be very intererested. I will keep searcing as well. In the meantime I will try the H9110 and let you know how I get on.
Thanks again to both of you
-
Hmmm... Makes sense.
The obvious next question is how can one be positive that their monitor supports a wider range of hfreq?
My monitor is an original "Polo", not a "Polo/2", "Polo/3", or "PoloStar".
According to this Hantarex Polo manual, which I believe is the correct one...
http://mame.3feetunder.com/byoac/hantarex_polo.pdf (http://mame.3feetunder.com/byoac/hantarex_polo.pdf)
...it supports...
Horizontal 15,700 ± 500 Hz adjustable
Vertical 45-65 Hz adjustable
Well, the horizontal range reported by Hantarex MTC 9110 is exactly the same, so we can expect that they work in a similar way. This is what I found: the [-500 Hz, 500 Hz] adjustable interval is NOT fixed around the 15.7 figure: in other words, it doesn't mean [15.200, 16.200]. Rather than that, it means that you have a 100 Hz window that you can move up or down using the hfreq potenciometer, being its lower adjustment possible [14.700, 15.700], and [15.700, 16.700] the higher possible, which is the one I use in order to get more lines out of that chassis. Resolutions below 15.7 kHz are not a problem because the modeline generator stuffs them with extra porch lines until they reach 15.7 kHz.
By the way, I assume you are aware yours is a multisync chassis, it also allows accepts 25 kHz signals. The problem is that it's not automatic, you need to manually change a jumper in the chassis to switch 15/25Khz.
When running groovymame with a fresh mame.ini I do get games running too fast. That said I have not yet checked whether directdraw acceleration is enabled. This may take me a while as I'm using an nlited and minlogon'd install of xp and dxdiag has been stripped out :(
Those unofficial XPs are problematic when installing CRT_Emudriver, I believe that's because they usually have newer stock display drivers and silently refuse to accept ours. You usually need to reinstall it several times, after completely uninstalling the stock driver from the Device Manager.
As an alternative test, use Arcade_OSD and run the measure_vfreq test to check if the scroll is smooth, without tearing and you get a reasonable vfreq figure.
If ddraw acceleration is disabled, all the rest is worthless. GroovyMAME relies on vsync funtionallity to properly temporize emulation.
Another possibilty is that you have manually disabled the vsync from your video card control panel. You shouldn't install any control panel (CCC) but if you do, make sure the vsync option is set so that applications decide whether to use it or not, never use the other options to override application's decisions, otherwise GroovyMAME may not have access to vsync functions.
-
thx for the hard work !
-
This is a highly experimental build of GroovyMAME, please use it with care.
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0143.013c_test.rar
VMMaker 1.3b + Arcade_OSD_1.3.rar
I don't have much time today and I'm leaving tomorrow for a week, I'll try to explain all the details, hopefully will be easy to use.
I'll be updating this thread in the next hours...
New features:
- "Magic resolutions".
- Improved scaling support.
- Support for LCD monitors via Powerstrip.
Magic resolutions
----------------
This is an attempt to overcome the unfamous Hyperspin issue. We keep our mode table short by using a 16-30 "magic" resolutions instead a hundred of them. This was already suggested by bitbytebit but at the moment I hadn't figured a way to make it work. The idea is to create a list like this:
## Mame ##
1234 x 240 @ 60.000000 mame
1234 x 256 @ 60.000000 mame
1234 x 272 @ 60.000000 mame
1234 x 288 @ 60.000000 mame
1234 x 304 @ 60.000000 mame
1234 x 320 @ 60.000000 mame
1234 x 336 @ 60.000000 mame
1234 x 352 @ 60.000000 mame
1234 x 368 @ 60.000000 mame
1234 x 384 @ 60.000000 mame
1234 x 400 @ 60.000000 mame
1234 x 416 @ 60.000000 mame
1234 x 432 @ 60.000000 mame
1234 x 448 @ 60.000000 mame
1234 x 464 @ 60.000000 mame
1234 x 480 @ 60.000000 mame
1234 x 496 @ 60.000000 mame
1234 x 512 @ 60.000000 mame
1234 x 528 @ 60.000000 mame
1234 x 544 @ 60.000000 mame
1234 x 560 @ 60.000000 mame
1234 x 576 @ 60.000000 mame
1234 x 592 @ 60.000000 mame
1234 x 608 @ 60.000000 mame
1234 x 624 @ 60.000000 mame
1234 x 640 @ 60.000000 mame
1234 x 656 @ 60.000000 mame
1234 x 672 @ 60.000000 mame
1234 x 688 @ 60.000000 mame
1234 x 704 @ 60.000000 mame
1234 x 720 @ 60.000000 mame
1234 x 736 @ 60.000000 mame
1234 x 752 @ 60.000000 mame
1234 x 768 @ 60.000000 mame
1234 x 784 @ 60.000000 mame
1234 x 800 @ 60.000000 mame
...where the xres is a dummy value. Then, for instance, in order to create resolution 320x240 we use the 1234x240 resolution and recalculate it with the right values on the fly. So we can create all resolutions used by MAME out of that list.
You may be wondering why not to use dummy values for both xres and yres, so we could do with only one magic resolution. The reason is that it only works for Catalyst 9.3. If yres value doesn't match it will cause a serious crash in Catalyst 6.5. That's why, by default, I've implemented the most conservative method.
The other limitation is that the "magic" resolution must be bigger than the one we want to create, otherwise the OS won't reserve enough memory for the mode. GroovyMAME already checks this for us.
Be aware I've only tested this with this two setups (which are my current ones):
- WinXP 64 + Catalyst 6.5
- WinXP 32 + Catalyst 9.3
It would be good to test the same for the other two combinations:
- WinXP 64 + Catalyst 9.3
- WinXP 32 + Catalyst 6.5
In order to setup your system for this method, download the new VMMaker 1.3b, edit vmmaker.ini as usual with your monitor type. Make sure you use the new ReslList.txt file. Then run VMMaker to install the new resolutions and restart.
Remind to set this options to zero (vmmaker.ini) as we don't need to list roms data from MAME's xml anymore:
ListFromXML = 0
GenerateXML = 0
GenerateInis = 0
Pixel doubling & scaling
----------------------
Selection of scaled resolutions by any factor (x2, x3, ...) is performed automatically so you don't have to mess with options anymore. Just set up your monitor properly, using a monitor_specs line if necessary, both in vmmaker.ini and mame.ini so VMMaker calculates the right resolutions for your monitor and GroovyMAME knows which ones to pick up.
I've been testing with a SVGA CRT monitor which supports up to 1280x1024. In order to cover its whole range I needed to use this line:
monitor_specs_0 = "29100-70000, 50-100, 1.000, 1.000, 3.000, 0.014, 0.044, 0.524, 0, 0, 1024, 800"
The last values are important. 1024 (active lines limit) limits the vertical resolution to the one accepted by the monitor. Notice that I set the virtual lines limit value to 800, as this has the side effect to limit the vertical minimum resolution to 400 (800/2). So this produces resolutions from 400 to 1024 vertical lines.
LCD monitors & Powerstrip
-------------------------
Experimental PowerStrip support has been added. It only updates current desktop resolution by now, so it can be tweaked to any desired refresh rate on the fly. So this is ideal for using with LCD monitors which actually support variable refresh rates (not all of them do).
Notice that you don't need CRT_Emudriver for this. Actually it's better not to use it.
This should work with any card supported by PowerStrip.
In order to use this feature:
- Download and install PowerStrip. Reboot. Leave PowerStrip's default options.
- Make sure to set up your desktop resolution to the LCD's native resolution.
- Set monitor option to "lcd"
- Use a proper monitor_specs line*
- Run groovymame with this options:
groovymame 1942 -ps -monitor lcd -video d3d
-ps / powerstrip is a new option that allows you to enable PowerStrip support if it's found in the system.
monitor lcd is a new type of monitor which
-video d3d is recommended when scaling is involved, as it increases performance a lot
So for the monitor_specs line, you can just modify this one to fit your monitor:
monitor_specs0 29000.00-50000.00,50.00-70.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,800,800
...being the last values the vertical resolution of your monitor (mine is 1280x800)
Porch values are ignored here, but vertical-horizontal freq. ranges are considered internally for the modeline calculator to make decisions, so try to use the right values for those. Many LCDs just sync properly to frequencies around 60 Hz, so you can use the monitor_specs line to limit the range of vertical frequencies sent to the monitor.
You can also choose which monitor you want to use:
groovymame 1942 -ps -monitor lcd -video d3d -screen \\.\DISPLAY1
or
groovymame 1942 -ps -monitor lcd -video d3d -screen \\.\DISPLAY2
-
Very exciting. This will continue to work with a 31kHz monitor given it's defined appropriately in the vmmaker.ini?
-
Ok Cal I tested.
Good news is Hyperspin runs. Bad news is games dont display correctly.
I am running win xp 32bit with 9.3 cat drivers
Billabs multic sync monitor.
Let me tell you what I did.
Test 1
1. Backedup old mame.exe, mame.ini, Vmmaker.exe, vmmaker.ini, arcade OSD, reslist.txt
2. Used groovymame32_0143.013c_test.rar + VMMaker 1.3b + Arcade_OSD_1.3.rar
3. Config vmaker.ini to my monitor
4. renamed groovymame to mame.exe and also genereated new mame.ini via mame -cc
5. edited mame.ini to reflect my d9800 (Yes I used lowercase d in the .ini File)
5. ran vmmaker
6. reboot
7. ran pacman
Test 2
1. I looked at my vmmaker.ini file and changed those 2 lines from 0 to 1 since that how my original ones looked.
2. ran vmmaker Got a different message ( enclosed Screen shots)
3. reboot
4. Ran Pacman
Mame options.
ListFromXML = 1 ; Processes Mame XML and get video mode list from it
GenerateXML = 1 ; Extracts XML from Mame (only needed once)
I included files for your review. IF you want you can talk to me on MSN messenger. Dompernice@hotmail.com
I also noticed the nag screen removal didnt work even though its set to 1 by default.
-
bent98,
Set this options to zero:
ListFromXML = 0
GenerateXML = 0
... as we don't need to list xml data any more with this method.
AND set:
UpdateRegistry = 1
... so the registry is updated with the new modes.
cotmm68030,
Scaling for 31Khz, etc. is AUTOMATIC now, so you don't need to specify anything but possibly the yresmin value, no dotclockmin needed, etc. I'll explain it above...
-
I just tried and when I run pacman monitor goes black and i an hear game running but cant see anything
Parsing mame.ini
Parsing mame.ini
SwitchRes: Entering switchres_modeline_setup (0)
SwitchRes: Monitor: d9800 Orientation: horizontal Aspect 4:3
SwitchRes: MonitorLimits 15250.00-18000.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288.0,448
SwitchRes: Hardware limits (60.6061Hz)-> YresMin= 230p, YresMax= 271p(542i)
SwitchRes: Logical limit YresMin (448/2) = 224p
SwitchRes: Setup monitor limits min=184x224 max=0x542
SwitchRes: Starting with Horizontal freq of 19.072 and Vertical refresh of 60.61
SwitchRes: Horizontal frequency too high 19.072 vfreq 60.606
SwitchRes: Lowered horizontal frequency to 18000.000 from 19.072
SwitchRes: Vertical frequency changed to 57.508 from 60.606
SwitchRes: Original Vref 60.606061 != 57.507987
SwitchRes: # 15.250Khz -> 18.000Khz: ( | Hfreq Change | Vref Change | )
SwitchRes: # pacman [11] 400x288@57.51 18.0000Khz
SwitchRes: ModeLine "400x288x57.51" 9.647999 400 424 472 536 288 291 294 313 -HSync -VSync
SwitchRes: MonitorLimits 18001.00-19000.00,40.00-80.00,2.187,4.688,6.719,0.140,0.191,0.950,0,0,288.0,448
SwitchRes: Hardware limits (60.6061Hz)-> YresMin= 274p, YresMax= 289p(578i)
SwitchRes: Logical limit YresMin (448/2) = 224p
SwitchRes: Setup monitor limits min=184x224 max=0x578
SwitchRes: Starting with Horizontal freq of 18.924 and Vertical refresh of 60.61
SwitchRes: # 18.001Khz -> 19.000Khz: ( Perfect Resolution )
SwitchRes: # pacman
SwitchRes: ModeLine "400x288x60.61" 10.286544 400 424 472 544 288 291 295 312 -HSync -VSync
SwitchRes: MonitorLimits 20501.00-29000.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,480.0,768
SwitchRes: Hardware limits (60.6061Hz)-> YresMin= 304p, YresMax= 430p(860i)
SwitchRes: Logical limit YresMin (768/2) = 384p
SwitchRes: Setup monitor limits min=184x384 max=0x860
SwitchRes: Virtualized to 1136x848@60.61 28.6061Khz
SwitchRes: Starting with Horizontal freq of 28.577 and Vertical refresh of 60.61
SwitchRes: # 20.501Khz -> 29.000Khz: ( | Interlace | Doubleres | Virtualize | )
SwitchRes: # pacman [12] 1136x848@60.61 28.6364Khz
SwitchRes: ModeLine "1136x848x60.61" 45.589089 1136 1264 1392 1592 848 874 883 945 -HSync -VSync interlace
SwitchRes: MonitorLimits 29001.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,576.0,768
SwitchRes: Hardware limits (60.6061Hz)-> YresMin= 437p, YresMax= 481p(962i)
SwitchRes: Logical limit YresMin (768/2) = 384p
SwitchRes: Setup monitor limits min=184x384 max=0x962
SwitchRes: Starting with Horizontal freq of 38.222 and Vertical refresh of 60.61
SwitchRes: Horizontal frequency too high 38.222 vfreq 60.606
SwitchRes: Lowered horizontal frequency to 32000.000 from 38.222
SwitchRes: Vertical frequency changed to 51.447 from 60.606
SwitchRes: Original Vref 60.606061 != 51.446945
SwitchRes: # 29.001Khz -> 32.000Khz: ( | Hfreq Change | Vref Change | Doubleres | )
SwitchRes: # pacman [14] 800x576@51.45 32.0000Khz
SwitchRes: ModeLine "800x576x51.45" 31.743999 800 816 936 992 576 586 588 622 -HSync -VSync
SwitchRes: MonitorLimits 32001.00-34000.00,40.00-80.00,0.636,3.813,1.906,0.020,0.106,0.607,0,0,576.0,768
SwitchRes: Hardware limits (60.6061Hz)-> YresMin= 505p, YresMax= 535p(1070i)
SwitchRes: Logical limit YresMin (768/2) = 384p
SwitchRes: Setup monitor limits min=184x384 max=0x1070
SwitchRes: Starting with Horizontal freq of 36.532 and Vertical refresh of 60.61
SwitchRes: Horizontal frequency too high 36.532 vfreq 60.606
SwitchRes: Lowered horizontal frequency to 34000.000 from 36.532
SwitchRes: Vertical frequency changed to 56.572 from 60.606
SwitchRes: Original Vref 60.606061 != 56.572379
SwitchRes: # 32.001Khz -> 34.000Khz: ( | Hfreq Change | Vref Change | Doubleres | )
SwitchRes: # pacman [14] 800x576@56.57 34.0000Khz
SwitchRes: ModeLine "800x576x56.57" 34.271999 800 816 944 1008 576 577 581 601 -HSync -VSync
SwitchRes: MonitorLimits 34001.00-38000.00,40.00-80.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,600.0,768
SwitchRes: Hardware limits (60.6061Hz)-> YresMin= 536p, YresMax= 598p(1196i)
SwitchRes: Logical limit YresMin (768/2) = 384p
SwitchRes: Setup monitor limits min=184x384 max=0x1196
SwitchRes: Starting with Horizontal freq of 36.532 and Vertical refresh of 60.61
SwitchRes: # 34.001Khz -> 38.000Khz: ( | Doubleres | )
SwitchRes: # pacman [3] 800x576@60.61 36.5455Khz
SwitchRes: ModeLine "800x576x60.61" 37.714908 800 832 952 1032 576 577 581 603 -HSync -VSync
SwitchRes v0.013: [pacman] (1) vertical (288x224@60.61)->(400x288@60.61)->(400x288@60.61)
SwitchRes: # pacman 400x288@60.61 18.9091Khz
SwitchRes: ModeLine "400x288x60.61" 10.286544 400 424 472 544 288 291 295 312 -HSync -VSync
SwitchRes: DefaultVideo 'System\CurrentControlSet\Control\Video\{6D0C80E8-65AE-416B-94ED-9469D6966463}\0000'
SwitchRes: DALDTMCRTBCD320X448X0X60:
SwitchRes: (61853/68) Modeline 11.770000 320 328 376 400 448 457 459 490
SwitchRes: DALDTMCRTBCD320X480X0X50:
SwitchRes: (61687/68) Modeline 11.590000 320 328 376 400 480 519 521 580
SwitchRes: DALDTMCRTBCD496X384X0X60:
SwitchRes: (60796/68) Modeline 17.400000 496 544 600 680 384 396 400 427
SwitchRes: DALDTMCRTBCD512X224X0X60:
SwitchRes: (62059/68) Modeline 10.000000 512 536 584 656 224 231 234 254
SwitchRes: DALDTMCRTBCD512X239X0X60:
SwitchRes: (62000/68) Modeline 10.260000 512 536 584 656 239 242 245 261
SwitchRes: DALDTMCRTBCD512X240X0X60:
SwitchRes: (61992/68) Modeline 10.310000 512 536 584 656 240 243 246 262
SwitchRes: DALDTMCRTBCD512X384X0X60:
SwitchRes: (60668/68) Modeline 18.040000 512 568 624 704 384 396 400 427
SwitchRes: DALDTMCRTBCD512X448X0X60:
SwitchRes: (60562/68) Modeline 18.360000 512 520 592 624 448 457 459 490
SwitchRes: DALDTMCRTBCD640X224X0X60:
SwitchRes: (61385/68) Modeline 12.420000 640 672 728 816 224 231 234 254
SwitchRes: DALDTMCRTBCD640X240X0X50:
SwitchRes: (61284/68) Modeline 12.420000 640 672 728 816 240 265 268 305
SwitchRes: DALDTMCRTBCD640X480X0X60:
SwitchRes: (59314/68) Modeline 25.200000 640 656 752 800 480 490 492 525
SwitchRes: DALDTMCRTBCD1234X240X0X60:
SwitchRes: (58107/68) Modeline 24.680000 1232 1288 1400 1568 240 243 246 262
SwitchRes: DALDTMCRTBCD1234X256X0X60:
SwitchRes: (57821/68) Modeline 26.650000 1232 1288 1416 1592 256 259 262 279
SwitchRes: DALDTMCRTBCD1234X272X0X60:
SwitchRes: (57493/68) Modeline 28.940000 1232 1296 1432 1624 272 276 279 297
SwitchRes: DALDTMCRTBCD1234X288X0X60:
SwitchRes: (57223/68) Modeline 30.850000 1232 1296 1440 1648 288 291 295 312
SwitchRes: DALDTMCRTBCD1234X304X0X60:
SwitchRes: (57217/68) Modeline 31.470000 1232 1320 1416 1552 304 314 317 338
SwitchRes: DALDTMCRTBCD1234X320X0X60:
SwitchRes: (56893/68) Modeline 33.740000 1232 1328 1432 1584 320 330 333 355
SwitchRes: DALDTMCRTBCD1234X336X0X60:
SwitchRes: (56611/68) Modeline 35.810000 1232 1336 1440 1600 336 346 350 373
SwitchRes: DALDTMCRTBCD1234X352X0X60:
SwitchRes: (56291/68) Modeline 38.100000 1232 1344 1456 1624 352 363 367 391
SwitchRes: DALDTMCRTBCD1234X368X0X60:
SwitchRes: (55966/68) Modeline 40.440000 1232 1352 1472 1648 368 380 384 409
SwitchRes: DALDTMCRTBCD1234X384X0X60:
SwitchRes: (55608/68) Modeline 43.040000 1232 1360 1488 1680 384 396 400 427
SwitchRes: DALDTMCRTBCD1234X400X0X60:
SwitchRes: (55678/68) Modeline 43.680000 1232 1256 1424 1504 400 431 433 484
SwitchRes: DALDTMCRTBCD1234X416X0X60:
SwitchRes: (55654/68) Modeline 43.680000 1232 1256 1424 1504 416 439 441 484
SwitchRes: DALDTMCRTBCD1234X432X0X60:
SwitchRes: (55630/68) Modeline 43.680000 1232 1256 1424 1504 432 447 449 484
SwitchRes: DALDTMCRTBCD1234X448X0X60:
SwitchRes: (55473/68) Modeline 44.690000 1232 1264 1432 1520 448 457 459 490
SwitchRes: DALDTMCRTBCD1234X464X0X60:
SwitchRes: (55218/68) Modeline 46.570000 1232 1264 1440 1528 464 474 476 508
SwitchRes: DALDTMCRTBCD1234X480X0X60:
SwitchRes: (54938/68) Modeline 48.640000 1232 1264 1448 1544 480 490 492 525
SwitchRes: DALDTMCRTBCD1234X496X0X60:
SwitchRes: (54773/68) Modeline 49.730000 1232 1264 1456 1552 496 504 507 534
SwitchRes: DALDTMCRTBCD1234X512X0X60:
SwitchRes: (54728/68) Modeline 49.910000 1232 1264 1456 1552 512 513 516 536
SwitchRes: DALDTMCRTBCD1234X528X0X60:
SwitchRes: (54530/68) Modeline 51.400000 1232 1264 1456 1552 528 529 533 552
SwitchRes: DALDTMCRTBCD1234X544X0X60:
SwitchRes: (54173/68) Modeline 54.080000 1232 1288 1464 1584 544 545 549 569
SwitchRes: DALDTMCRTBCD1234X560X0X60:
SwitchRes: (53963/68) Modeline 55.690000 1232 1288 1464 1584 560 561 565 586
SwitchRes: DALDTMCRTBCD1234X576X0X60:
SwitchRes: (53681/68) Modeline 57.790000 1232 1288 1472 1600 576 577 581 602
SwitchRes: DALDTMCRTBCD1234X592X0X60:
SwitchRes: (53423/68) Modeline 59.720000 1232 1288 1480 1608 592 593 597 619
SwitchRes: DALDTMCRTBCD1234X608X0X60:
SwitchRes: (56250/68) Modeline 31.520000 1232 1320 1416 1552 608 627 634 677 interlace
SwitchRes: DALDTMCRTBCD1234X624X0X60:
SwitchRes: (56058/68) Modeline 32.690000 1232 1328 1424 1568 624 644 651 695 interlace
SwitchRes: DALDTMCRTBCD1234X640X0X60:
SwitchRes: (55877/68) Modeline 33.790000 1232 1328 1432 1584 640 659 666 711 interlace
SwitchRes: DALDTMCRTBCD1234X656X0X60:
SwitchRes: (55707/68) Modeline 34.820000 1232 1336 1440 1592 656 676 683 729 interlace
SwitchRes: DALDTMCRTBCD1234X672X0X60:
SwitchRes: (55545/68) Modeline 35.860000 1232 1336 1440 1600 672 692 699 747 interlace
SwitchRes: DALDTMCRTBCD1234X688X0X60:
SwitchRes: (55373/68) Modeline 36.900000 1232 1336 1448 1608 688 709 717 765 interlace
SwitchRes: DALDTMCRTBCD1234X704X0X60:
SwitchRes: (55174/68) Modeline 38.150000 1232 1344 1456 1624 704 725 733 783 interlace
SwitchRes: DALDTMCRTBCD1234X720X0X60:
SwitchRes: (54972/68) Modeline 39.410000 1232 1344 1464 1640 720 743 751 801 interlace
SwitchRes: DALDTMCRTBCD1234X736X0X60:
SwitchRes: (54798/68) Modeline 40.490000 1232 1352 1472 1648 736 759 767 819 interlace
SwitchRes: DALDTMCRTBCD1234X752X0X60:
SwitchRes: (54594/68) Modeline 41.780000 1232 1352 1480 1664 752 776 784 837 interlace
SwitchRes: DALDTMCRTBCD1234X768X0X60:
SwitchRes: (54389/68) Modeline 43.090000 1232 1360 1488 1680 768 792 800 855 interlace
SwitchRes: DALDTMCRTBCD1234X784X0X60:
SwitchRes: (54259/68) Modeline 43.900000 1232 1360 1488 1680 784 808 817 871 interlace
SwitchRes: DALDTMCRTBCD1234X800X0X60:
SwitchRes: (54052/68) Modeline 45.230000 1232 1360 1496 1696 800 824 833 889 interlace
SwitchRes: Found 44 custom of 83 active modelines
- SwitchRes: 320 x 200 @ 60p-> 0.00 System Modeline
[1]SwitchRes: 320 x 200 @ 75p-> 0.00 System Modeline
[2]SwitchRes: 320 x 240 @ 60p-> 0.00 System Modeline
[3]SwitchRes: 320 x 240 @ 75p-> 0.00 System Modeline
[4]SwitchRes: 320 x 448 @ 60p-> 0.00 Custom Modeline
[5]SwitchRes: 400 x 300 @ 60p-> 94.00 System Modeline
[6]SwitchRes: 400 x 300 @ 75p-> 94.00 System Modeline
[7]SwitchRes: 496 x 384 @ 60p-> 53.65 Custom Modeline
[8]SwitchRes: 512 x 224 @ 60p-> 0.00 Custom Modeline
[9]SwitchRes: 512 x 239 @ 60p-> 0.00 Custom Modeline
[10]SwitchRes: 512 x 240 @ 60p-> 0.00 Custom Modeline
[11]SwitchRes: 512 x 384 @ 60p-> 51.13 Custom Modeline
[12]SwitchRes: 512 x 384 @ 75p-> 51.13 System Modeline
[13]SwitchRes: 512 x 448 @ 60p-> 40.41 Custom Modeline
[14]SwitchRes: 640 x 224 @ 60p-> 0.00 Custom Modeline
[15]SwitchRes: 640 x 400 @ 60p-> 32.50 System Modeline
[16]SwitchRes: 640 x 400 @ 75p-> 32.50 System Modeline
[17]SwitchRes: 640 x 480 @ 60p-> 20.50 Custom Modeline
[18]SwitchRes: 640 x 480 @ 72p-> 20.50 System Modeline
[19]SwitchRes: 640 x 480 @ 75p-> 20.50 System Modeline
[20]SwitchRes: 640 x 480 @ 85p-> 20.50 System Modeline
[21]SwitchRes: 720 x 480 @ 60p-> 13.56 System Modeline
[22]SwitchRes: 800 x 600 @ 56p-> 92.00 System Modeline
[23]SwitchRes: 800 x 600 @ 60p-> 92.00 System Modeline
[24]SwitchRes: 800 x 600 @ 70p-> 92.00 System Modeline
[25]SwitchRes: 800 x 600 @ 72p-> 92.00 System Modeline
[26]SwitchRes: 800 x 600 @ 75p-> 92.00 System Modeline
[27]SwitchRes: 800 x 600 @ 85p-> 92.00 System Modeline
[28]SwitchRes: 1024 x 768 @ 60p-> 49.13 System Modeline
[29]SwitchRes: 1024 x 768 @ 70p-> 49.13 System Modeline
[30]SwitchRes: 1024 x 768 @ 72p-> 49.13 System Modeline
[31]SwitchRes: 1024 x 768 @ 75p-> 49.13 System Modeline
[32]SwitchRes: 1024 x 768 @ 85p-> 49.13 System Modeline
[33]SwitchRes: 1152 x 864 @ 60p-> 64.44 System Modeline
[34]SwitchRes: 1152 x 864 @ 70p-> 64.44 System Modeline
[35]SwitchRes: 1152 x 864 @ 75p-> 64.44 System Modeline
[36]SwitchRes: 1152 x 864 @ 85p-> 64.44 System Modeline
[37]SwitchRes: 1234 x 240 @ 60p-> 0.00 Custom Modeline
[38]SwitchRes: 1234 x 256 @ 60p-> 0.00 Custom Modeline
[39]SwitchRes: 1234 x 272 @ 60p-> 0.00 Custom Modeline
[40]SwitchRes: 1234 x 288 @ 60p-> 100.00 Custom Modeline
[41]SwitchRes: 1234 x 304 @ 60p-> 87.98 Custom Modeline
[42]SwitchRes: 1234 x 320 @ 60p-> 83.24 Custom Modeline
[43]SwitchRes: 1234 x 336 @ 60p-> 78.96 Custom Modeline
[44]SwitchRes: 1234 x 352 @ 60p-> 75.06 Custom Modeline
[45]SwitchRes: 1234 x 368 @ 60p-> 71.51 Custom Modeline
[46]SwitchRes: 1234 x 384 @ 60p-> 68.24 Custom Modeline
[47]SwitchRes: 1234 x 400 @ 60p-> 65.24 Custom Modeline
[48]SwitchRes: 1234 x 416 @ 60p-> 62.48 Custom Modeline
[49]SwitchRes: 1234 x 432 @ 60p-> 59.91 Custom Modeline
[50]SwitchRes: 1234 x 448 @ 60p-> 57.53 Custom Modeline
[51]SwitchRes: 1234 x 464 @ 60p-> 55.31 Custom Modeline
[52]SwitchRes: 1234 x 480 @ 60p-> 53.24 Custom Modeline
[53]SwitchRes: 1234 x 496 @ 60p-> 51.31 Custom Modeline
[54]SwitchRes: 1234 x 512 @ 60p-> 49.49 Custom Modeline
[55]SwitchRes: 1234 x 528 @ 60p-> 47.79 Custom Modeline
[56]SwitchRes: 1234 x 544 @ 60p-> 46.19 Custom Modeline
[57]SwitchRes: 1234 x 560 @ 60p-> 44.67 Custom Modeline
[58]SwitchRes: 1234 x 576 @ 60p-> 92.24 Custom Modeline
[59]SwitchRes: 1234 x 592 @ 60p-> 89.54 Custom Modeline
[60]SwitchRes: 1234 x 608 @ 60i-> 66.98 Custom Modeline
[61]SwitchRes: 1234 x 624 @ 60i-> 64.55 Custom Modeline
[62]SwitchRes: 1234 x 640 @ 60i-> 62.24 Custom Modeline
[63]SwitchRes: 1234 x 656 @ 60i-> 60.05 Custom Modeline
[64]SwitchRes: 1234 x 672 @ 60i-> 57.96 Custom Modeline
[65]SwitchRes: 1234 x 688 @ 60i-> 55.97 Custom Modeline
[66]SwitchRes: 1234 x 704 @ 60i-> 54.06 Custom Modeline
[67]SwitchRes: 1234 x 720 @ 60i-> 52.24 Custom Modeline
[68]SwitchRes: 1234 x 736 @ 60i-> 50.51 Custom Modeline
[69]SwitchRes: 1234 x 752 @ 60i-> 48.84 Custom Modeline
[70]SwitchRes: 1234 x 768 @ 60i-> 47.24 Custom Modeline
[71]SwitchRes: 1234 x 784 @ 60i-> 45.71 Custom Modeline
[72]SwitchRes: 1234 x 800 @ 60i-> 44.24 Custom Modeline
[73]SwitchRes: 1280 x 720 @ 60p-> 68.75 System Modeline
[74]SwitchRes: 1280 x 1024 @ 60p-> 72.13 System Modeline
[75]SwitchRes: 1280 x 1024 @ 70p-> 72.13 System Modeline
[76]SwitchRes: 1280 x 1024 @ 75p-> 72.13 System Modeline
[77]SwitchRes: 1600 x 1200 @ 60p-> 88.00 System Modeline
[78]SwitchRes: 1792 x 1344 @ 60p-> 67.00 System Modeline
[79]SwitchRes: 1800 x 1440 @ 60p-> 79.89 System Modeline
[80]SwitchRes: 1920 x 1080 @ 60p-> 56.33 System Modeline
[81]SwitchRes: 1920 x 1200 @ 60p-> 71.33 System Modeline
[82]SwitchRes: 1920 x 1440 @ 60p-> 74.33 System Modeline
SwitchRes: Index 40/83 modeline DALDTMCRTBCD1234X288X0X60 score 100.00 matches
SwitchRes: Got Custom modeline 1232x288@59.998911 - DALDTMCRTBCD1234X288X0X60:
"1234x288@60" 30.850000 1232 1296 1440 1648 288 291 295 312 -HSync -VSync
SwitchRes: Setting modeline registry entry for DALDTMCRTBCD1234X288X0X60
SwitchRes: Set Registry mode DALDTMCRTBCD1234X288X0X60 with:
SwitchRes: (62184/57223/62184) Modeline 10.280000 400 424 472 544 288 291 295 312
SwitchRes: Setting Option -keepaspect
SwitchRes: Setting Option -redraw 0
SwitchRes: Setting Option -rotate
SwitchRes: Setting Option -nosoundsync
SwitchRes: Enabling VSYNC
SwitchRes: Setting Option -nothrottle
SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 1234x288@60
Video: Monitor 00010001 = "\\.\DISPLAY1" (primary)
DirectDraw: Using DirectDraw 7
Blitting thread created
winwindow_video_window_create: blit_lock = TRUE
Blitting thread started
window_proc: WM_NCACTIVATE
window_proc: blit_lock = TRUE
DirectDraw: Configuring device Radeon X1950 Series
DirectDraw: primary surface created: 1234x288x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 224x288
DirectDraw: blit surface created: 224x288x32 (R=00FF0000 G=0000FF00 B=000000FF)
complete_create: blit_lock = FALSE
window_proc: WM_PAINT
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels
RawInput: APIs detected
Input: Adding Mouse #0: Microsoft USB IntelliMouse Optical
Input: Adding Gun #0: Microsoft USB IntelliMouse Optical
Input: Adding Mouse #1: HID-compliant mouse
Input: Adding Gun #1: HID-compliant mouse
Input: Adding Mouse #2: HID-compliant mouse
Input: Adding Gun #2: HID-compliant mouse
Input: Adding Kbd #0: HID Keyboard Device
Input: Adding Kbd #1: HID Keyboard Device
Input: Adding Kbd #2: HID Keyboard Device
DirectInput: Using DirectInput 7
Input: Changing default joystick map = s8.4s8.44s8.4445
s8888888s
4s88888s6
44s888s66
444555666
444555666
444555666
44s222s66
4s22222s6
s2222222s
Input: Changing default joystick map = s8.4s8.44s8.4445
s8888888s
4s88888s6
44s888s66
444555666
444555666
444555666
44s222s66
4s22222s6
s2222222s
Starting Driver Device 'root'
(missing dependencies; rescheduling)
Starting Z80 'maincpu'
Starting Video Screen 'screen'
Starting Speaker 'mono'
(missing dependencies; rescheduling)
Starting Namco 'namco'
Starting Driver Device 'root'
(missing dependencies; rescheduling)
Starting Speaker 'mono'
Starting Driver Device 'root'
window_proc: WM_NCACTIVATE
window_proc: blit_lock = TRUE
window_proc: WM_DESTROY
window_proc: blit_lock = TRUE
Blitting thread ended
Blitting thread destroyed
SwitchRes: Resetting modeline registry entry for DALDTMCRTBCD1234X288X0X60
SwitchRes: Set Registry mode DALDTMCRTBCD1234X288X0X60 with:
SwitchRes: (57223/57223/57223) Modeline 30.850000 1232 1296 1440 1648 288 291 295 312
-
BTW
Monitor is capable of 1024x768 max. Not sure why it shows resolutions all the way up to 1920x1440.
-
I just tried and when I run pacman monitor goes black and i an hear game running but cant see anything
Great... ???
Your logs look right, but that sounds too bad. Its a relief that it didn't crash. Funny thing is that I have the same setup (XP 32 + 9.3) but testing on a SVGA CRT with a Radeon X300 and it works fine here. On my cab (XP 64 6.5) Radeon 9250 its working great too... Maybe it's a problem with newer cards... don't know. I'll need to do more testing when I'm back. Thanks for testing anyway.
-
BTW
Monitor is capable of 1024x768 max. Not sure why it shows resolutions all the way up to 1920x1440.
Just something to try: go to screen / properties / advanced / monitor and uncheck the box "Hide modes this monitor can't show...
Maybe the 1234 figure is fooling Win.
-
I have a X1900XT. THats not that new
-
Just tried that. It didnt work. Same thing. Black screen
-
Just tried that. It didnt work. Same thing. Black screen
Can you see these 1234 resolutions in Arcade_OSD? Do they work?
-
Yes,
I tried about 10 of them and they all work
-
Sniff Sniff. I cant wait another week. :hissy:
-
Yes,
I tried about 10 of them and they all work
I won't be able to do any testing until I'm back but the "magic" resolutions thing might be a big FAIL after all. Which really sucks as it as it seemed too good to be true, as it allowed doing all the MAME resolutions out of a bunch of them. The fact is that it's working in my systems but there can be hundreds of reasons why it could be failing as it is such a big hack of things, so I'll probably drop that functionality.
However there's still that other option to test in VMMaker that might help with the HS issue. It's the Only32BPPModes option. If you enable that, only 32 bits per pixel modes will be enabled, so that will reduce the total list of modes quite a bit. In order to use that option, set up VMMaker as before (with options to list from XML enabled), and use the old ReslList.txt without the new 1234 modes.
-
Well, if your back from Vacation and stilling willing to attempt work on the magic resolutions I'd love to test further.
-
Well, if your back from Vacation and stilling willing to attempt work on the magic resolutions I'd love to test further.
Thanks a lot. I'd really like to try a little more with that method before I decide to trash it, it was a lot of work and patches to Mame to achieve that but after all it's just an experiment.
If you still have the same setup as you had last week, you could try some ideas:
- Use -video d3d instead of ddraw to see if it makes any difference.
- Enter a fixed magic resolution by command line, like this (only valid for Cat 9.3):
groovymame toki -magic_resolution 640x480@60
NOTE: make sure to choose rom a which resolution is smaller than 640x480
- Press the print screen key while the picture is black and paste the result in the Paint app to see if its rendering the game.
- Check your monitor OSD while the picture is black to see if your getting a 15kHz signal.
-
I will try frogger and dkong. how to i select d3d instead of dd?
-
I will try frogger and dkong. how to i select d3d instead of dd?
Thanks!
Also try some horizontal game. To select d3d use a command line like this:
groovymame toki -video d3d -magic_resolution 640x480@60
-
Ok
I always use the same resolution and refresh in the command lines correct?
-
Ok
I always use the same resolution and refresh in the command lines correct?
Yep, I picked that one (640x480@60) because it's shown as avaliable and "custom" in your logs. If it works as intended, GroovyMAME should create any resolution needed using that one as (the resolution must fit inside 640x480, that's the only condition for Cat 9.3).
-
When I used that command line it works great! Displays pefectly.
I tried Asteriods, simpsons, donkey kong, pacman, mr do, dig dug and frogger!
-
is it the d3d thats making it work?
-
When I used that command line it works great! Displays pefectly.
I tried Asteriods, simpsons, donkey kong, pacman, mr do, dig dug and frogger!
Great news man!
Make sure they are run in their native refresh (press F11 -> 100%?). Try games like mk, robocop, ddragon, etc. which don't run at 60 Hz.
To know if it was because of direct3d try running games with the -video ddraw param instead.
You can permanently set that magic resolution in mame.ini by adding this option:
magic_resolution 640x480@60
-
Ok
ddraw displays game but its shifted all the way up and to the left off the screen. I took a screenshot of donkey kong. D3d works flawless. DDragon, robocopy mk fine all 100% when f11 is pressed.
Why is ddraw not working?
-
Ok
ddraw displays game but its shifted all the way up and to the left off the screen. I took a screenshot of donkey kong. D3d works flawless. DDragon, robocopy mk fine all 100% when f11 is pressed.
Why is ddraw not working?
So with d3d you can actually see how the resolution switches to match the game's one, I mean dkong, mk, ddragon, etc. use a real progressive resolution, not a stretched picture on a 640x480 interlaced resolution, don't they?
I don't know why ddraw doesn't work, it should work the same than d3d, at least it does here, so I hope it's not an illusion and d3d is not doing a stretched display.
Actually that screen capture you made must be the same for ddraw and d3d, as that's the real framebuffer MAME uses internally, it's only that we're hacking the modeline so the only visible part on the screen is a smaller left-top rectangle with the correct size contained inside the framebuffer.
If you are positive the resolutions are genuine try launching games from HS, that after all was the motivation of all this :D
-
Yes it runs fine from Hyperspin. How do I tell if D3d is running same as Ddraw? I mean the OSD shows it running at 15Khz. I have enxlose a screenshot of it running d3d mode.
-
The monitor does make a clicking sound and switch to that resolution. I also compared the OSD for both d3d and ddraw and they are both 16.5Khz at 60.5hz refresh. Except for the fact ddraw is off the screen.
-
Yes it runs fine from Hyperspin. How do I tell if D3d is running same as Ddraw? I mean the OSD shows it running at 15Khz. I have enxlose a screenshot of it running d3d mode.
Perfect! That means it's working, I want to believe. So with ddraw you can see the whole framebuffer with the game on the left-top corner (as the screeshot shows)? Weird. But with d3d the size is correct and the picture is just as good as when you used normal modelines is it? Anyway if d3d works just stick with it.
It would be good to see if it works with the 1234x resolutions now with -video d3d. That would be good so we can use the same method with Cat 6.5/9.3. To test that just run the same command line with -video d3d without the -magic_resolution param.
-
I just tested command line without the magic_resolution param and it worked just fine
-
Still love to know why ddraw image shifts up. CAn you check you code? Do you want me to run debug?
-
great, i will try this new magic resolution :)
One stupide question, about my new cab (mj25), i've a platinium hantarx 9100 and videocolors screen.
in vmmaker, i can use d9100? (don't know if it's screen or platinum who involved in modeline:))
but i try too this magic resolution soon !
-
I just tested command line without the magic_resolution param and it worked just fine
Great, so we can keep the same method for both versions of the driver.
So this should finally be the workaround we needed for HS. As we can make all Mame resolutions using a much lower amount of them then HS will start without problems.
Still love to know why ddraw image shifts up. CAn you check you code? Do you want me to run debug?
I'm afraid I need to reproduce that issue here. What happens is that for the 9.3 version I'm checking here with a CRT SVGA monitor, and the issue doesn't happen. But I think I know what you're seeing as it's the same I saw here at the beginning before I made the patches. So I need to set up one of my cabinets with Cat 9.3 and a newer card (both have a 9250 at the moment) to try to find the problem.
Fortunately it's working for d3d, and after all that's the setting I intended to recommend when using "magic" resolutions, because with ddraw I was seeing another issue sometimes, as if it wasn't fast enough to deal with the artificially big frame buffers we're using with this patch.
-
great, i will try this new magic resolution :)
One stupide question, about my new cab (mj25), i've a platinium hantarx 9100 and videocolors screen.
in vmmaker, i can use d9100? (don't know if it's screen or platinum who involved in modeline:))
but i try too this magic resolution soon !
I haven't heard of that "platinum" model... However it's likely you can use the H9110 setting just fine with your Hantarex.
-
I need to upgrade my video card. Whats the fastest 3d card you recommend that still works best with groovymame?
-
I need to upgrade my video card. Whats the fastest 3d card you recommend that still works best with groovymame?
The most powerful fully supportd card is the HD 4890, however for arcade use you may be interested in a lower consume or silent card (no fan), krick provided some links here:
http://forum.arcadecontrols.com/index.php?topic=113885.0 (http://forum.arcadecontrols.com/index.php?topic=113885.0)
-
Any chance this method will work with 7 64 bit?
-
Any chance this method will work with 7 64 bit?
I'm afraid not, we can't use dynamic modelines with Win7.
-
Do you think there will ever be a way in win 7 or maybe window 8 when it comes out? What about Powerstrip?
-
Do you think there will ever be a way in win 7 or maybe window 8 when it comes out? What about Powerstrip?
Old Catalyst (WinXP) based custom modes, like the ones we use in GroovyMAME with the ATI modified drivers, are, by far, the most versatile method that I know in Windows, and it's more stable than PowerStrip.
New AMD drivers have a different API to create custom modes on the fly, that could be a possibility, but it's limited to "normal" resolutions.
Powerstrip may eventually be the preferred way to deal with these things, but it's limited to the resolutions supported by the driver/windows. I've been testing last build of GroovyMAME in Win7 + Powerstrip and a LCD screen and it works great for me, but it's a fixed resolution.
So yes, there are chances to achieve something in Win7, but I seriously doubt it will match what we have in WinXP when it comes to CRT support.
-
Hello,
I try your magic resolution:
making new folder test MAme
put GM inside with fresh ini
autororL =1
Monitor orientation auto.
Create new crtemu folder with fresh zip inside.
followa your instruction for xml to 0
update registry = 1
reboot:
magic resolution inside arcade OSD + 256*224 and some ?
test pacman, dk: Perfect 100% !
double dragon hit f11 (100% + update 40 lines ^^) full screen :)
robocop toki tmnt
work perfect :)
tested into hyperspin, perfect :)
Just one question d3d or ddraw works the same on gr'oovymame?
the second in double dragon update 40 lines for ? with old groovymame, i was able to going perfect with the same modeline with clone of ddragon.zip (perhaps ddragon (world) but not with US)??
excellent work, i keep that and try some games :)
i will make tutorial for french people :)
-
Hi caskad,
Are you using the versions I posted here?
http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299 (http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299)
These are the ones you need to use in order to test the "magic" resolution stuff (I highly doubt it'll work in Win7).
magic resolution inside arcade OSD + 256*224 and some ?
magic resolutions are the ones that start with 1234x (so probably you've just been using normal resolutions).
When you do the test, make sure to enable -syncrefresh so if F11 still shows 100% that means dynamic modelines are working.
Just one question d3d or ddraw works the same on gr'oovymame?
Mainly yes, though d3d is much faster when scaling is involved. If you're using magic resolutions, choose d3d.
the second in double dragon update 40 lines for ? with old groovymame, i was able to going perfect with the same modeline with clone of ddragon.zip (perhaps ddragon (world) but not with US)??
Just ignore the "partial updates" stuff, it's some info MAME is giving us but not related to fps.
-
Are you using the versions I posted here?
http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299 (http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299)
These are the ones you need to use in order to test the "magic" resolution stuff (I highly doubt it'll work in Win7).
Yes, but for now trying XP :)
magic resolutions are the ones that start with 1234x (so probably you've just been using normal resolutions).
i ve 1234x... resolution + others (256*224, 320*224.. 792*592(50i) about 20 modelines).
with normal resolution (old VMMAKER.exe), ddragon was not fullscreen
When you do the test, make sure to enable -syncrefresh so if F11 still shows 100% that means dynamic modelines are working.
i test !
-
Here modeline text:
Modeline "256x224_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 224 234 237 261 -hsync -vsync
Modeline "256x239_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 239 241 244 261 -hsync -vsync
Modeline "256x240_60 15.66KHz 60.00Hz" 5.510 256 272 304 352 240 242 245 261 -hsync -vsync
Modeline "320x224_60 15.65KHz 59.98Hz" 6.630 320 336 368 424 224 234 237 261 -hsync -vsync
Modeline "320x240_50 15.65KHz 50.01Hz" 6.630 320 336 368 424 240 268 271 313 -hsync -vsync
Modeline "320x448_60 15.61KHz 59.94Hz" 6.620 320 336 368 424 448 466 471 521 interlace -hsync -vsync
Modeline "320x480_50 15.61KHz 49.96Hz" 6.620 320 336 368 424 480 535 540 625 interlace -hsync -vsync
Modeline "512x448_60 15.62KHz 59.98Hz" 10.510 512 536 584 672 448 466 471 521 interlace -hsync -vsync
Modeline "640x480_60 15.62KHz 59.95Hz" 12.980 640 664 728 832 480 482 487 521 interlace -hsync -vsync
Modeline "664x496_60 16.18KHz 60.06Hz" 14.090 664 696 760 872 496 499 504 539 interlace -hsync -vsync
Modeline "792x592_50 15.88KHz 50.03Hz" 16.360 792 824 904 1032 592 595 600 635 interlace -hsync -vsync
Modeline "1234x240_60 15.67KHz 60.04Hz" 25.090 1232 1280 1400 1600 240 242 245 261 -hsync -vsync
Modeline "1234x256_58 16.20KHz 58.49Hz" 26.180 1232 1288 1408 1616 256 258 261 277 -hsync -vsync
Modeline "1234x272_55 16.20KHz 55.29Hz" 26.180 1232 1288 1408 1616 272 274 277 293 -hsync -vsync
Modeline "1234x288_52 16.20KHz 52.43Hz" 26.180 1232 1288 1408 1616 288 290 293 309 -hsync -vsync
Modeline "1234x448_60 15.64KHz 60.05Hz" 25.030 1232 1280 1400 1600 448 466 471 521 interlace -hsync -vsync
Modeline "1234x464_60 15.64KHz 60.05Hz" 25.030 1232 1280 1400 1600 464 474 479 521 interlace -hsync -vsync
Modeline "1234x480_60 15.64KHz 60.05Hz" 25.030 1232 1280 1400 1600 480 482 487 521 interlace -hsync -vsync
Modeline "1234x496_60 16.17KHz 60.00Hz" 26.130 1232 1288 1408 1616 496 499 504 539 interlace -hsync -vsync
Modeline "1234x512_58 16.23KHz 58.49Hz" 26.230 1232 1288 1408 1616 512 515 520 555 interlace -hsync -vsync
Modeline "1234x528_57 16.23KHz 56.85Hz" 26.230 1232 1288 1408 1616 528 531 536 571 interlace -hsync -vsync
Modeline "1234x544_55 16.23KHz 55.28Hz" 26.220 1232 1288 1408 1616 544 547 552 587 interlace -hsync -vsync
Modeline "1234x560_54 16.23KHz 53.82Hz" 26.220 1232 1288 1408 1616 560 563 568 603 interlace -hsync -vsync
Modeline "1234x576_52 16.23KHz 52.42Hz" 26.220 1232 1288 1408 1616 576 579 584 619 interlace -hsync -vsync
Modeline "1234x592_51 16.23KHz 51.10Hz" 26.220 1232 1288 1408 1616 592 595 600 635 interlace -hsync -vsync
Modeline "1234x608_50 16.23KHz 49.85Hz" 26.220 1232 1288 1408 1616 608 611 616 651 interlace -hsync -vsync
for syncrefresh, it was enable in the mame.ini, i test with -syncrefresh, ok but for ddragon... 256*224 ...
i don't know why i 've so manay modeline ?
-
Oh, I see, that's fine! I thought you were testing with Win7.
Yes, those 1234x are the "magic" modelines. The other ones (256x224, etc.) are added there into ReslList.txt for compatibility with Megadrive and SNES emulators.
You can test with -v -md 4 in other to get the logs and see if they're actually being used (they should).
So you tested with ddraw or d3d?
Thanks!
-
ddraw give black image but sound
D3d perfect :)
-
ddraw give black image but sound
D3d perfect :)
Great. So same problem with ddraw reported by bent98.
Just something more, are you using Cat 6.5 or 9.3?
-
Winxp, hd4350 cat 9.3 :)
ive try demule, kof 2011, and big bug :)
seems to have lost the sync, it's not groovymame, but ati catalyst 9.3 who have give up?
split image like 30 khz, vertical sync goes out, CTRL ALT sup -> solve the problem.
one more thing, ive hantarex chassi (MTC 9000 (châssis in french) :)), and a screen made by Videocolor.
the h9110 doesn't work in VMmaker.exe, it tells me monitor specs ignore or something else, only Custom works, why vmmaker ignore the H9110?
2. MONITOR
; ----------
; Monitor Type. Valid types: D9800, D9400, D9200, EGA, VGA, MULTI, H9110, PAL, NTSC, GENERIC, CUSTOM
MonitorType = "H9110"
; Monitor CUSTOM. These values will be used if MonitorType = "CUSTOM"
;
; monitor_specs_0-6 = "HfreqMin-HfreqMax, VfreqMin,VfreqMax, HFrontPorch, HSyncPulse, HBackPorch, VfrontPorch, VSyncPulse, VBackPorch, HSyncPol, VSyncPol, ActiveLinesLimit, VirtualLinesLimit"
;
; * HfreqMin-HfreqMax: Minimum and maximum horizontal frequency, in Hz. Defines the range of horizontal frequencies the monitor is capable to sync.
; The higher the horizontal frequency, the higher the vertical resolution available for the same vertical refresh.
; The higher the horizontal frequency, the higher the vertical refresh available for the same vertical resolution.
; The higher the horizontal frequency, the lower the horizontal amplitude of active video (narrower picture).
;
; * VFreqMin-VfreqMax: Minimum and maximum vertical frequency, in Hz, Defines the range of vertical frequencies the monitor is capable to sync.
;
; * HFrontPorch, HSyncPulse, HBackPorch: Horizontal timing and geometry, values in µs
;
; * VfrontPorch, VSyncPulse, VBackPorch: Vertical timing and geometry, values in ms
;
; * HSyncPol,VSyncPol: polarities, not in use! defaults to negative.
;
; * ActiveLinesLimit: Vertical resolutions until ActiveLinesLimit value included, are generated as progressive, regardless the possibility
; of obtaining the required vertical refresh value.
;
; * VirtualLinesLimit: Vertical resolutions above ActiveLinesLimit and below VirtualLinesLimit are virtualized, that is, an interlaced resolution
; bigger that the native one is generated, with the right refresh, and "hardware stretch" is applied.
; Vertical resolutions above VirtulaLinesLimit are generated as interlaced, without any stretching.
monitor_specs_0 = "15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.160, 1.056, 0, 0, 288, 448"
; monitor_specs_0 = "29100-70000, 50-160, 1.000, 1.000, 3.000, 0.014, 0.044, 0.524, 0, 0, 1024, 800"
; Tolerance for horizontal frequency, in kHz, enables extending the range defined by [ HfreqMin, HfreqMax ]
; The resulting allowed frequency range will be [ HfreqMin - HfreqTolerance, HfreqMax + HfreqTolerance ]
HfreqTolerance = 0.010
ANd one more question :)
Modeline are based on screen (Videocolor)? or chassi (in case MTC hantarex9100??)
..by defaut with "CUSTOM" it work great but can i expected better ?
very low resolution on AracdeOSd are fine, but .. in OSd menu, 192*224, the words are cut on the left.
like:
de number -> mode number
rizontal geometry -> horizontal geometry
etc etc...
doesn't matter or can be adjust?
thx :)
PS: Making acronis image and test 6.3 if you want !
-
Winxp, hd4350 cat 9.3 :)
Good to know.
ive try demule, kof 2011, and big bug :)
seems to have lost the sync, it's not groovymame, but ati catalyst 9.3 who have give up?
But that's not MAME. You need to find which resolutions those programs are trying to set, and then add them to ReslList.txt so they are calculated as custom modes with the right frequencies. "Magic" resolutions are only a GroovyMAME feature, don't work for other programs.
the h9110 doesn't work in VMmaker.exe, it tells me monitor specs ignore or something else, only Custom works, why vmmaker ignore the H9110?
Yes H9110 works, it's only telling you that the monitor_specs line is being ignored. Just comment (add an ";") that line and that message won't happen. In VMMaker, monitor_specs lines only are read if you specify monitor type as CUSTOM. This is slightly different in GroovyMAME, where monitor_specs always override the values of the selected monitor.
Modeline are based on screen (Videocolor)? or chassi (in case MTC hantarex9100??)
..by defaut with "CUSTOM" it work great but can i expected better ?
The chassis is what matters.
H9110 allows a somewhat higher hfreq than the default monitor_specs in VMMaker.ini (the one used when you select CUSTOM), that allows games with 256 lines run at 60Hz, otherwise they would run at 58Hz or so. It also allows higher virtualized resolutions: better detail for stretched vertical games.
very low resolution on AracdeOSd are fine, but .. in OSd menu, 192*224, the words are cut on the left.
Yes that's normal ;D
I didn't find smaller fonts in Windows that looked fine, anyway you can press P2 to disable full screen edit and then enter to test changes.
-
so:
Yes H9110 works, it's only telling you that the monitor_specs line is being ignored. Just comment (add an ";") that line and that message won't happen. In VMMaker, monitor_specs lines only are read if you specify monitor type as CUSTOM. This is slightly different in GroovyMAME, where monitor_specs always override the values of the selected monitor.
i 've read that mtc 9100 have the same value of mtc9110.. if i want to have the "best" result, i must add comment in the monitor_specs AND edit mame.ini to avoid groovymame override it?
so far, thx for the explaination, chassis is what matter :)
for demul, it's just 640/480@60khz? other game runs fine, i must dig it :)
and ok for the fonts :) but need to find smaller ! ;)
edit added ";" and perfect with h9110 !) but no 192*224 ^^
-
Calamity, I just tried your experimental version with the magic resolutions and it's rock solid. Is there any chance you could compile us a 64-bit version? I'm dying for that extra little bit of juice it gives me to run blitz at full speed.
-
Calamity, I just tried your experimental version with the magic resolutions and it's rock solid. Is there any chance you could compile us a 64-bit version? I'm dying for that extra little bit of juice it gives me to run blitz at full speed.
Sounds great! I'm leaving for the weekend now, anyway I don't have the system here set up for 64 bits so I can't build it, hopefully we'll update the mainline groovyMAME soon with both builds.
-
Enjoy your weekend. If you have a quick minute before you leave. I just realized that the only way the new version runs at 100% (as opposed to 104 or 110 or whatever) is if sync refresh is set to 0. Is that normal?
[Edit: Nevermind, after playing around with the new build for a few hours, I've got everything straightened out, though I think I'm gonna hold off on making it my primary emulator until it's out of beta. This version doesn't play nice with hyperspin at all (in xp x64). Maybe the 64 bit version will be different? Anyway, cheers for making an amazing product, Calamity.]
-
Enjoy your weekend. If you have a quick minute before you leave. I just realized that the only way the new version runs at 100% (as opposed to 104 or 110 or whatever) is if sync refresh is set to 0. Is that normal?
[Edit: Nevermind, after playing around with the new build for a few hours, I've got everything straightened out, though I think I'm gonna hold off on making it my primary emulator until it's out of beta. This version doesn't play nice with hyperspin at all (in xp x64). Maybe the 64 bit version will be different? Anyway, cheers for making an amazing product, Calamity.]
So what was the issue with HS? Did it even run at all or was something wrong with games themselves?
I can't build 64 bit binaries at the moment as my only 64 bit machine is in the cab and I don't seem to be able to compile 64 bit mame from my Win32 systems, hopefully I'll have another x64 system soon, by now I will post diff files in case someone can build the 64 bit binaries.
-
So what was the issue with HS? Did it even run at all or was something wrong with games themselves?
I can't build 64 bit binaries at the moment as my only 64 bit machine is in the cab and I don't seem to be able to compile 64 bit mame from my Win32 systems, hopefully I'll have another x64 system soon, by now I will post diff files in case someone can build the 64 bit binaries.
HS would run, but when it opened groovymame, it would pick completely different resolutions than if you just opened groovymame by itself and ran the games. For instance, it would choose a very low resolution for rampage: world, and nfl blitz (it seemed to mostly be affecting higher resolution games). I tried pretty much everything and it just kept doing it. Ran with hyperlaunch as well as without and both did the same thing. Pretty bizarre stuff. Also, I noticed that the beta versions seem to like having ini files to, I don't know, guide them a bit? For instance, with an ini, pacman would run at 100% at a progressive resolution, which was just great. Without it, it ran at an odd interlaced resolution.
I also noticed a difference if you used the old mame.ini (non-beta) with the new (beta) groovymame. It seemed to choose cleaner looking resolutions than with the new mame.ini or the old groovymame with the old ini. Kind of interesting.
-
On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?
Andy
-
sounds like a pretty must-have feature to me.
-
On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?
Andy
Hi Andy,
That would be awesome. Just provide us with a way to interface with your card and we'll support it, that's sure.
So would it accept any dotclock we request (assuming there's always some granularity)? I mean, is your software already dealing with pll dividers and stuff so we won't need to care?
-
HS would run, but when it opened groovymame, it would pick completely different resolutions than if you just opened groovymame by itself and ran the games. For instance, it would choose a very low resolution for rampage: world, and nfl blitz (it seemed to mostly be affecting higher resolution games). I tried pretty much everything and it just kept doing it. Ran with hyperlaunch as well as without and both did the same thing. Pretty bizarre stuff. Also, I noticed that the beta versions seem to like having ini files to, I don't know, guide them a bit? For instance, with an ini, pacman would run at 100% at a progressive resolution, which was just great. Without it, it ran at an odd interlaced resolution.
I also noticed a difference if you used the old mame.ini (non-beta) with the new (beta) groovymame. It seemed to choose cleaner looking resolutions than with the new mame.ini or the old groovymame with the old ini. Kind of interesting.
Sounds weird. There's probably something wrong with your setup there. Get me some logs and I'll be able to diagnose what's the issue. It must be possible to add the -v -md 4 >romname.txt somehow into the HS command-line for launching GroovyMAME so we can see what it's doing.
-
Andy, If you could just come out with wirless Aimtrak guns so I wouldnt have to buy TopGun III's Id be a happy man.
-
On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?
Andy
Hi Andy,
That would be awesome. Just provide us with a way to interface with your card and we'll support it, that's sure.
So would it accept any dotclock we request (assuming there's always some granularity)? I mean, is your software already dealing with pll dividers and stuff so we won't need to care?
Yes the software deals with that, just would require the modeline including dot clock. In its current form the software does not need a dotclock specified as it accepts a vertical and horizontal refresh rate so it calculates the required clock but I could change that to make it closer to a standard modeline.
But how would a pre-defined modeline be able to deal with the feature which ArcadePerfect has, which allows the picture to be moved and resized with the arrow keys? Or is that implemented already?
-
Yes the software deals with that, just would require the modeline including dot clock. In its current form the software does not need a dotclock specified as it accepts a vertical and horizontal refresh rate so it calculates the required clock but I could change that to make it closer to a standard modeline.
But how would a pre-defined modeline be able to deal with the feature which ArcadePerfect has, which allows the picture to be moved and resized with the arrow keys? Or is that implemented already?
What we do is to is to first figure out the porch values that a given monitor needs in order to show a perfectly centered picture, and build one or more "monitor_specs" lines like this:
monitor_specs_0 15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.160, 1.056, 0, 0, 288, 448
As new modelines are calculated on the fly using those values, all resolutions should automatically fit the screen without further re-adjustment.
-
On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?
Hi Andy,
Would something like that work in Linux too?
Since Linux does not use DLLs, is this possible already?
Cheers,
Quinny
-
On the subject of the ArcadeVGA card:
The ArcadePerfect utility for this card creates resolutions on the fly by writing directly to the card. It will work even without any drivers installed. It works in all Windows versions.
I could create a DLL based on this, which would accept a modeline timing as an input, and the card would display the mode. This would allow infinite modes to be displayed.
Just wondering if that would be of any interest to be used in conjunction with Groovymame?
Hi Andy,
Would something like that work in Linux too?
Since Linux does not use DLLs, is this possible already?
Cheers,
Quinny
Hi Quinny,
Yes, GroovyArcade for Linux already supports AVGA 3000.
-
A new GroovyMAME binary is available here:
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0143u7.013d.rar
0143u7_groovymame_013d.diff
Features
--------
- Core updated to v0.143 u7.
- All features from GroovyMAME_013c_test version included: magic resolutions, auto-scaling and support for LCD monitors via Powerstrip*. Refer to this thread for details: http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299 (http://forum.arcadecontrols.com/index.php?topic=110905.msg1209299#msg1209299)
- Now video settings are properly applied even when launching games from Mame's internal frontend.
* Although GroovyMAME's default video option is "video ddraw", we recommend to use "video d3d" instead if any of the newer options is used (actually magic resolutions don't work with ddraw in some systems).
Compiling notes:
---------------
Apply patches in this order:
1) 0143u1.diff -> 0143u2.diff -> 0143u3.diff -> 0143u4.diff -> 0143u5.diff -> 0143u6.diff -> 0143u7.diff
2) hi_143u5.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
3) 0143_hilinux.diff (http://mario.groovy.org/GroovyMame/0143/ (http://mario.groovy.org/GroovyMame/0143/))
4) 0143u7_groovymame_013d.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
I've done basic testing of this build and it seems to work, anyway take care. Specially, don't use the powerstrip settings until you're sure this binary doesn't crash in your system (in case of crash during game or on exit GroovyMAME won't be able to revert Powerstrip settings to your desktop defaults and you may end up with a garbled display).
One of the aims of this build was to get rid of some HLSL stability problems they claim to have solved in u7 revision. Well, I'm afraid there're still some problems with HLSL in this build, at least in my machine (WinXP32, DirectX 9.0c, HD4350) it shows this exception on exit:
-----------------------------------------------------
Exception at EIP=01E056E7 (not found): ACCESS VIOLATION
While attempting to read memory at 40C90FDB
-----------------------------------------------------
EAX=40C90FDB EBX=06F9A8E0 ECX=7FFDC000 EDX=00034C50
ESI=0031BE58 EDI=003201F6 EBP=00000000 ESP=06C7F8B4
-----------------------------------------------------
Stack crawl:
00000000: 01E056E7 (not found)
I've downloaded and tested another MAME 0.143u7 binary just to double check and it's the same story, so I guess it's not GroovyMAME related. It's interesting that if I rename the 'artwork' folder the crash doesn't happen... I need to test this build in W7 too.
However that problem only happens if you enable HLSL, that's not the case if you're using an arcade monitor.
-
THx !
Ive just test this release, but some strange issue with the mame's game selection. Aniway, work's perfect with command line !
-
THx !
Ive just test this release, but some strange issue with the mame's game selection. Aniway, work's perfect with command line !
Yep, I've seen that in some systems too. Even plain u7 binary (not GroovyMAME related) will crash if the internal frontend is used with d3d selected. It happens even without hlsl enabled. I guess the whole d3d interface has become buggy since the integration of hlsl. I'd love they would add a new video interface for hlsl experimental stuff instead of messing with the existing d3d one, so we could use a clean d3d interface as it was right before they added the hlsl thing. Considering the current binary size it wouldn't mean such a difference.
-
Asking about one thing:
Cave games are fine on mame 143u8, when groovymame diff or compile ;D
-
Asking about one thing:
Cave games are fine on mame 143u8, when groovymame diff or compile ;D
Wicked!!!! Have you complied a GroovyMAME 143u8 64bit yourself???, if so please share! :applaud:
-
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0143u8.013d.rar
groovymame64_0143u8.013d.rar
0143u8_groovymame_013d.diff
Compiling notes:
---------------
Apply patches in this order:
1) 0143u1.diff -> 0143u2.diff -> 0143u3.diff -> 0143u4.diff -> 0143u5.diff -> 0143u6.diff -> 0143u7.diff -> 0143u8.diff
2) hi_143u5.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
3) 0143_hilinux.diff (http://mario.groovy.org/GroovyMame/0143/ (http://mario.groovy.org/GroovyMame/0143/))
4) 0143u8_groovymame_013d.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
-
Thanks Calamity!!! Quick question how do i get the High Scores to save in groovyMAME, they dont seem to save themselves?
-
Thx calamity :)
-
Any news on the 64bit release?
-
Any news on the 64bit release?
Hi lettuce, today's been a terrible day, hopefully I can have it tomorrow.
-
Like me terrible day since 30 Days :s
anyway, if time to considered how to speed up perhaps this CAVE GAMES?
Any suggest? (not to slow but not 100%)
Have a GOOD hallowen day !
-
Apparently the Cave game run better on the 64bit version of mame, so hopefully Calamity will release the 64 bit version soon
-
Thanks Calamity!!! Quick question how do i get the High Scores to save in groovyMAME, they dont seem to save themselves?
Grab the unofficial hiscore.dat file from highscore.mameworld.info, and put it in the /hi/ directory in groovymame (create the directory if it doesn't exist). Then edit mame.ini in the groovymame root and make sure the line about disabling the hiscore patch isn't set (I forget the exact line - it's close to the bottom).
-
groovymame32_0143u8.013d.rar now uploading...
Sorry guys for the delay, even u9 has been released so this one is a bit outdated already :)
Anyway I'll definitely wait for v0.144 to see if it's more stable on the hlsl part.
-
Calamity, are you still going to be implementing Wiimote support in GroovyMAME??...i would love to play some lightgun games in mame but cant seem to get it to work with MAME :(
-
Calamity, are you still going to be implementing Wiimote support in GroovyMAME??...i would love to play some lightgun games in mame but cant seem to get it to work with MAME :(
It was VeS the one who implemented it for the Linux side actually, I'll write to him to see if it's easy to add.
-
Cool, thanks
-
Version 0.144 is uploaded:
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0144.013d.rar
groovymame64_0144.013d.rar
0144_groovymame_013d.diff
Compiling notes:
---------------
Apply patches in this order:
1) hi_144.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
2) 0144_groovymame_013d.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
I've merged the hi_linux and groovymame patches into one single diff so the process of applying patches is somewhat simpler.
-
Hello, if you include the hiscore patch in the patches of groovy is a problem, normal hiscore is not supported linux,patches can not be applied, anyway I tried to apply your patch groovyarcade to suck from linux and there are problems, the patch is only for windows?
Since gentoo patches can be applied without problems, so the error is in ubuntu patch, anyone know why ubuntu does not work and if done with gentoo? that the difference between gentoo and ubuntu patch?
I compiled the same version that uses gentoo patch 2.5.9 and can now apply patches without problems, someone knows why the version of ubuntu patch 2.6.1 does not work?
Here you have the wiimote144mame patch is only for linux.
http://www.megaupload.com/?d=OI1TZEXF (http://www.megaupload.com/?d=OI1TZEXF)
http://www.retrovicio.org/foro/showthread.php?16228-Pistola-Wiimote-Linux (http://www.retrovicio.org/foro/showthread.php?16228-Pistola-Wiimote-Linux)
For windows you have to use BlueSoleil and Wiinremote, and also patch mame in:
/src/osd/windows/INPUT.C
#define FORCE_DIRECTIPUT 0
change
#define FORCE_DIRECTIPUT 1
http://www.retrovicio.org/foro/showthread.php?12209-Pistola-MAME-con-WiiMote!! (http://www.retrovicio.org/foro/showthread.php?12209-Pistola-MAME-con-WiiMote!!)
Thank you.
-
Hi Ves,
Thanks a lot for the patches, I'll check if it's easy to port it to the Windows side.
Hello, if you include the hiscore patch in the patches of groovy is a problem, normal hiscore is not supported linux,patches can not be applied, anyway I tried to apply your patch groovyarcade to suck from linux and there are problems, the patch is only for windows?
Try by applying the hi_144.txt patch over MAME source code using MAME Compiler for Windows, it works for me that way, then build your Linux binary as usual.
Thanks again!
-
Here you have the wiimote144mame patch is only for linux.
http://www.megaupload.com/?d=OI1TZEXF (http://www.megaupload.com/?d=OI1TZEXF)
http://www.retrovicio.org/foro/showthread.php?16228-Pistola-Wiimote-Linux (http://www.retrovicio.org/foro/showthread.php?16228-Pistola-Wiimote-Linux)
For windows you have to use BlueSoleil and Wiinremote, and also patch mame in:
/src/osd/windows/INPUT.C
#define FORCE_DIRECTIPUT 0
change
#define FORCE_DIRECTIPUT 1
http://www.retrovicio.org/foro/showthread.php?12209-Pistola-MAME-con-WiiMote!! (http://www.retrovicio.org/foro/showthread.php?12209-Pistola-MAME-con-WiiMote!!)
Thank you.
So you do have to use BlueSoleil and Wiinremote with MAME theres no other way around it??. I can just use a prog like Pinnacle Game Profiler which has Wii support. I have tried setting up my Wiimote to act as a lightgun in Mame but have never got it to work :(. Calamity if you could get this working with the Windows version of Groovymame it would be great!! :cheers:
-
Calamity, i know im being a pain but can you please compile a 64-Bit version of GroovyMame 0.143u9 please????
-
GroovyMame x32 Linux and Wiimote support gentoo.
http://www.megaupload.com/?d=4Y5TPGUX (http://www.megaupload.com/?d=4Y5TPGUX)
Update GroovyArcade,replace groovymame.
/usr/games/bin/groovymame
Thanks.
-
So will there be a windows release of GroovyMAME with Wiimote support that doesnt require other software to get it to work?
-
Yeah this would defo be a really nice addition to GroovyMame Calamity, having Wiimote support build into the windows version! Would this be possible?
-
Yeah this would defo be a really nice addition to GroovyMame Calamity, having Wiimote support build into the windows version! Would this be possible?
I made some research the other day and, as Ves pointed, under Windows the Wiimote support is all performed through third party software Bluesoleil and Wiinremote. So the only mod that MAME needs is the FORCE_DIRECTINPUT thing. That's definitely something I won't do for GroovyMAME's binary as I've read here and there that it adds some degree of input lag compared to usual raw input. However, I may add it as an option that the user can enable/disable through mame.ini, probably in next release.
-
Ah ok, thats a shame that a 3rd party software is needed, i cant get Bluesoleil and Wiinremote to work correctly together at all on my system, must of spent a good few hours trying to get it to work. Either Bluesoleil doesnt detect and pair with my wiimote, or if it does pair up ok then Wiinremote wont detect my wiimote and on the odd occasion i do get them both to connect to my wiimote anything i press on the wiimote isnt detected :(. Its a right royal pain in the arse there has to be an easier way
-
You probably have seen this thread: http://forum.arcadecontrols.com/index.php?topic=89378.0 (http://forum.arcadecontrols.com/index.php?topic=89378.0)
They recommend GlovePie instead of Wiinremote. However they say not every bluetooth device is compatible with Wiimote, so that could be your case.
-
Hello,
For having test wiiremote with bluesoleil and glovepie script, definitively not working fine :s
problem with aiming but good accuracy with crosshair, no digging so far!
But pretty strange, having setup lightgun config with wingun: thougt Mame was using directinput !
EG: Nuvve plugin psx2 does work with direct input no raw, and model 2 too (raw enable -> diseable).
off topic sorry :)
-
Version 0.144u1 is uploaded:
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0144u1.013d.rar
groovymame64_0144u1.013d.rar
0144u1_groovymame_013d.diff
Compiling notes:
---------------
Apply patches in this order:
1) 0144u1_diff (http://mamedev.org/updates.html (http://mamedev.org/updates.html))
2) hi_144.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
3) 0144u1_groovymame_013d.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
Stability notes:
---------------
Hopefully stability issues caused by HLSL integration have been finally fixed with this update:
Fixed HLSL memory leak and crash on exit on 32-bit targets.
[Ryan Holtz, Bat Country Entertainment]
However, I'm seeing a new crash on exit but this only happens with GroovyMAME build. I'll work to fix it as soon as possible, until then, remind to use it with care.
The crash was in official MAME too. I think I've fixed it, need more testing. I've submitted it to mamedevs.
New binaries uploaded.
-
Now that's what I call service!
Thanks Calamity very much appreciated here, these Namco Classics are the main reason I mamed this cocktail cab - my dream is almost complete ;)
I will donate again this weekend when I get paid :cheers:
-
Version 0.144u2 is uploaded:
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0144u2.013d.rar
groovymame64_0144u2.013d.rar
0144u2_groovymame_013d.diff
Compiling notes:
---------------
Apply patches in this order:
1) 0144u1_diff -> 0144u2_diff (http://mamedev.org/updates.html (http://mamedev.org/updates.html))
2) hi_144.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
3) 0144u2_groovymame_013d.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
Stability notes:
---------------
They've included my fix :)
- 04538: [Crash/Freeze] Many sets: Crash on exit on 32-bit Windows XP
(-video d3d) (Antonio Giner)
No more crashes on exit for now. As a side effect, this makes possible to lauch games from the internal menu again.
-
Nice!, thanks for this Calamity!!!! :applaud:
-
They've included my fix :)
Good job! And, thanks! :)
-
I tried groovymame 0.144, but I'm facing some serious issues: some games (such as NBA Hangtime, Metal Slug 1/2/3/X, Aero Fighters 2/3) aren't show well.
I played these games with previous version of groovymame without problems, but now there is a lot of flickering (it seems the display is out of frequency).
Now I'm asking: is a problem with groovymame patch, mame itself or with my config?
If you need some tests to be done, just tell me.
Some info:
OS: slackware 13.37 64bit
Kernel: 3.2.1 with 15KHz patch
Videocard: ATI HD5450
Display: PAL TV (without freq trimmer)
Frontend: advancemenu-2.5.0
Emulator: mame-0144u6 with hiscore-0144u5 and groovymame-0144u2 patches
Thanks for help.
-
Emulator: mame-0144u6 with hiscore-0144u5 and groovymame-0144u2 patches
So you've compiled your own binary?
Have you tried this binary: GroovyMame32x144u2Wiimote.tar.bz2 here: http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
-
Yes, I compiled the binary by myself.
I don't have tried that precompiled tarball, because I was thinking that the "32" means "for 32 bit" (and my system is 64 bit).
Eventually I will try to install multilib and try the precompiled binary (or compile it myself starting from mame-0144u2).
-
The precompiled binary is for 32 bit systems and requires some specific libraries which I haven't; so I compiled mame-0144u2 with hiscore-0144 and groovymame-0144u2 patches (as specified here (http://forum.arcadecontrols.com/index.php?topic=110905.msg1233554#msg1233554)), but the problems persist :( .
-
Eventually I will try to install multilib and try the precompiled binary (or compile it myself starting from mame-0144u2).
Can't 64-bit Linux run 32-bit applications natively? Win-64 certainly can.
-
The precompiled binary is for 32 bit systems and requires some specific libraries which I haven't; so I compiled mame-0144u2 with hiscore-0144 and groovymame-0144u2 patches (as specified here (http://forum.arcadecontrols.com/index.php?topic=110905.msg1233554#msg1233554)), but the problems persist :( .
Well, that's strange as I've tested the binary included in the new Live-CD (144u2) and it worked perfectly for me.
Please guys provide some logs when reporting issues (-v -md 4) :)
-
BTW make sure you create a fresh mame.ini (run groovymame with the -cc param).
-
BTW make sure you create a fresh mame.ini (run groovymame with the -cc param).
I'm sure I've NOT created a fresh mame.ini.
Is there a way to automatically merge the new mame.ini with the old one?
Please guys provide some logs when reporting issues (-v -md 4) :)
Is there a way to do this from advmenu?
-
Ok, I tried to create a new mame.ini, but no luck.
Here is an error (probably generated by xrandr) when I try to launch NBA Hangtime:
SwitchRes v0.013: [nbahangt] (1) horizontal (399x253@54.82)->(400x256@54.82)->(400x256@29.37)
-syncrefresh specified without -waitsync. Reverting to -nosyncrefresh
SwitchRes v0.013: [nbahangt] (1) horizontal (400x254@54.82)->(400x256@54.82)->(400x256@29.37)
X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 149 (RANDR)
Minor opcode of failed request: 16 (RRCreateMode)
Serial number of failed request: 33
Current serial number in output stream: 33
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 149 (RANDR)
Minor opcode of failed request: 19 (RRDeleteOutputMode)
Serial number of failed request: 33
Current serial number in output stream: 34
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 149 (RANDR)
Minor opcode of failed request: 17 (RRDestroyMode)
Serial number of failed request: 33
Current serial number in output stream: 34
Average speed: 100.00% (8 seconds)So initially I blamed xrandr, but then I started Metal Slug 3, the display started flickering and I switched to tty1 to see the xrandr error...
SwitchRes v0.013: [mslug3] (1) horizontal (320x224@59.19)->(320x224@59.19)->(320x224@33.39)
-syncrefresh specified without -waitsync. Reverting to -nosyncrefresh
Average speed: 100.00% (10 seconds)No errors at all and the screen continuing flickering :angry: .
Now what?
-
I'll check that game today and report.
-
Hi Ansa89, nbahangt is working great here with the new live-cd (144u2). So I don't know what can be happening with your system. Please attach a complete log so I can see something, you can't do it from AdvMenu, you need to go to command line for that.
-
SwitchRes v0.013: [nbahangt] (1) horizontal (399x253@54.82)->(400x256@54.82)->(400x256@29.37)
Something is wrong here: the 29.37 value. What monitor type have you selected?
-
you can't do it from AdvMenu, you need to go to command line for that.
So I start X with a terminal and then "groovymame64 -v -md 4 nbahangt &> file.log", right?
Something is wrong here: the 29.37 value. What monitor type have you selected?
I selected "pal" since my diplay is a pal tv (as posted before).
I should better regenerate the switchres.conf and xorg.conf?
-
So I start X with a terminal and then "groovymame64 -v -md 4 nbahangt &> file.log", right?
Yes, but I like to type it in this order:
groovymame romname -v -md 4 >romname.txt
I selected "pal" since my diplay is a pal tv (as posted before).
I should better regenerate the switchres.conf and xorg.conf?
Well, that's something...
Just edit mame.ini and change the monitor_specs0 value for this one:
monitor_specs0 15625-16200,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,448
-
Yes, but I like to type it in this order:
groovymame romname -v -md 4 >romname.txt
Ok :) .
Just edit mame.ini and change the monitor_specs0 value for this one:
monitor_specs0 15625-16200,49.50-65.00,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,448
It looks like a modeline...How you get it?
Do you think the problem is the tv?
-
It's not a modeline, it's a monitor_specs line :) It tells groovymame how your modelines need to be calculated.
Your TV should be fine, it's just that I probably broke the PAL monitor type with my patches.
-
Ok, tomorrow I will try this out :) .
-
Ok, now it seems to work.
From your patch I can see (file "src/emu/switchres/monitor.c"):
...
} else if (!strcmp(type, "pal")) {
monitor[0].HfreqMin = 15625;
monitor[0].HfreqMax = 15625;
monitor[0].VfreqMin = 50;
monitor[0].VfreqMax = 50;
monitor[0].HfrontPorch = 1.650;
monitor[0].HsyncPulse = 4.700;
monitor[0].HbackPorch = 5.000;
monitor[0].VfrontPorch = 0.064;
monitor[0].VsyncPulse = 0.192;
monitor[0].VbackPorch = 1.024;
monitor[0].HsyncPolarity = 0;
monitor[0].VsyncPolarity = 0;
monitor[0].ActiveLinesLimit = 312.5;
monitor[0].VirtualLinesLimit = 576;
return 1;
...This is a little different from the monitor_spec you give me.
Next question: should I better leave the "monitor_spec0 blahblah" into mame.ini (for next releases) or I can safely remove it when upgrade groovymame?
-
One more thing: after setting the monitor_spec0, some vertical games (galaga, galaga88, galaxian) were displayed out of frequency.
Looking your monitor_spec0, I changed it this way:
15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,448
As you can see, the previous vfreq and hfreq were too high, so I searched for pal specification and adjusted the values to something more comfortable.
Now everyone seem happy (me too) :) .
-
One more thing: after setting the monitor_spec0, some vertical games (galaga, galaga88, galaxian) were displayed out of frequency.
Looking your monitor_spec0, I changed it this way:
15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,448
That's fine. That was a generic setting for arcade monitors. It's reasonable that a TV has a narrower range for hfreq. Vfreq should be fine a bit higher than 60 (think that many games use the 60.606060 Hz frequency), but that's not too important.
As you can see, the previous vfreq and hfreq were too high, so I searched for pal specification and adjusted the values to something more comfortable.
Now everyone seem happy (me too) :) .
The problem with the PAL/NTSC presets in GroovyMAME is that they only accept a fixed value for vfreq when that's not how real devices work. So my advice is to always use custom ones based on the line I passed above. Apart from that it seems that I broke those fixed frequency settings when changing some stuff in the modeline generator, I'll need to fix it.
-
Ok, thanks for all your work ;D .
-
Are you using the waitvsync option????
NOTE the Typo bug: http://mamedev.org/source/src/osd/sdl/video.c.html (http://mamedev.org/source/src/osd/sdl/video.c.html)
When is says "-waitsync" it's referring to "-waitvsync"
SwitchRes v0.013: [mslug3] (1) horizontal (320x224@59.19)->(320x224@59.19)->(320x224@33.39)
-syncrefresh specified without -waitsync. Reverting to -nosyncrefresh
Average speed: 100.00% (10 seconds)No errors at all and the screen continuing flickering :angry: .
Now what?
[/quote]
-
The problem was an incorrect monitor_spec0 line.
I launch the games from advancemenu without passing any arguments (at least that's what I think).
-
With update 7 (mame 0.144u7) groovymame patch needs a little change:
--- 0144u2_groovymame_013d.diff 2012-01-31 12:35:52.075364846 +0100
+++ 0144u7_groovymame_013d.diff 2012-01-31 13:57:31.780794671 +0100
@@ -1234,7 +1234,7 @@
diff -Nru src/emu/switchres/switchres.c src/emu/switchres/switchres.c
--- src/emu/switchres/switchres.c 1970-01-01 01:00:00.000000000 +0100
+++ src/emu/switchres/switchres.c 2011-12-05 19:25:14.000000000 +0100
-@@ -0,0 +1,390 @@
+@@ -0,0 +1,391 @@
+#include "emu.h"
+#include "emuopts.h"
+
@@ -1327,7 +1327,8 @@
+ r = ATTOSECONDS_TO_HZ(devconfig->refresh_attoseconds());
+
+ gameInfo->screens = 0;
-+ for (devconfig = config.first_screen(); devconfig != NULL; devconfig = devconfig->next_screen())
++ screen_device_iterator iter(config.root_device());
++ for (devconfig = iter.first(); devconfig != NULL; devconfig = iter.next())
+ gameInfo->screens++;
+
+ if (resolution->width != 0 && resolution->height != 0) {I don't know if it needs some other workarounds due to mame upgrade, but at least it compiles ;D .
-
I don't know if it needs some other workarounds due to mame upgrade, but at least it compiles ;D .
Thanks Ansa, hopefully in the next days (weeks) I find some time to update GM and try this.
-
Note that we are near to mame 0.145, so a reworked patch should be fine within the new official release.
-
Note that we are near to mame 0.145, so a reworked patch should be fine within the new official release.
Sure, I've rewritten the soundsync patch in a way that may eventually work in Linux too. I intended to launch it together with the 0.145 version. I can't build the Linux part however ;)
-
When you release it, I will try to build and test under linux.
-
Version 0.145 is uploaded:
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0145.013e.rar
groovymame64_0145.013e.rar
groovymame32_0145.013e_wiimote_linux.tar.bz2
0145_groovymame_013e.diff
Thanks go to:
- VeS for building the Linux binary including Wiimote support.
- Ansa89 for his patch update.
Compiling notes
Apply patches in this order:
1) hi_145.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
2) 0145_groovymame_013e.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
Important notes about the new groovy-013e patch
Some default options have been changed in the version. Make sure to create a fresh mame.ini file.
The 'soundsync' patch has been completely rewritten in an attempt to port its functionality to the Linux side. Now there's no 'soundsync' option anymore. The emulator core has been subtly modified in a way that allows the sound to be always synchronized with the game's speed. Thus, this patch is not OS-dependent and works in Linux too.
In order to achieve this, MAME's 'syncrefresh' option has been moved from the OS layer right into the emulator core. In our humble opinion, from a design point of view, this is where it should always have been, as the 'syncrefresh' option shouldn't belong to the layer where the final wait-for-vsync implementation is performed, but be part of the emulator's throttling mechanism.
Another important implication is that the 'throttle' option now needs to be enabled in order for 'syncrefresh' to be considered. A modification of the throttling mechanism makes it possible to have 'throttle' and 'syncrefresh' enabled and still enjoy smooth scrolling. When in the game, by pressing F10, the game can be throttled/unthrotted even with 'syncrefresh' enabled.
As usual, the 'triplebuffer' option (ony Windows) can be enabled to achieve truly asynchronous tearing-less rendering, improving performance in some situations, at the cost of scroll stuttering. Notice that 'triplebuffer' has preference over 'syncrefresh', so if both are enabled, only 'triplebuffer' will be considered.
Finally, remind that the 'waitvsync' option is managed internally by GroovyMAME, so whatever value you use will be overridden. Use syncrefresh/triplebuffer instead.
Linux notes
You'll need to manually enable the 'cleanstretch' option in mame.ini in order to get the right aspect for vertical games.
Bugs fixed
- Windows: Many crashes due to the 3-threaded rendering mechanism, when running games that switch resolutions, or using ALT+ENTER, ALT+TAB, maximizing, minimizing, etc. This should be the most stable GroovyMAME version on that regard (update: still found a crash in XP-64 build, I'm afraid)
- Windows: Crash when the -nomodeline option was used.
-
Sounds fantastic! Thanks! Will try tonight! ;D
-
I will try it ASAP.
-
Again, thank you. It's working great here! No problems at all with the games I tried. Smooth as always! :)
-
With groovymame 0.145 the sound is scratchy (tried with galaga, tekken 3, nba hangtime) :( .
Are there some options I can set/unset?
-
With groovymame 0.145 the sound is scratchy (tried with galaga, tekken 3, nba hangtime) :( .
Are there some options I can set/unset?
Did you create a fresh mame.ini?
-
Yep, but (just to be sure) I will recreate it (tomorrow, because now my mom doesn't let me play with the cab... :'( ).
Any other suggestion?
-
Just make sure that the throttle and syncrefresh options are enabled. Possibly try disabling waitvsync.
I wanted to test it today too but for some reason the UpdateGroovyMame command failed, I guess Linux doesn't like the name I gave to the .tar file??
-
I wanted to test it today too but for some reason the UpdateGroovyMame command failed, I guess Linux doesn't like the name I gave to the .tar file??
I never used that script: to compile groovymame I download all patches and sources by hand and then use a slackbuild which build a slackware package.
If you post the script, I will give a look at this.
-
Just make sure that the throttle and syncrefresh options are enabled. Possibly try disabling waitvsync.
I wanted to test it today too but for some reason the UpdateGroovyMame command failed, I guess Linux doesn't like the name I gave to the .tar file??
Hello Calamity, forgets of putting the name of the compressed file of this form Groovy ****** the first letter it is with capital letter.
-
Hello Calamity, forgets of putting the name of the compressed file of this form Groovy ****** the first letter it is with capital letter.
Thanks, I've edited the file name, figured it had to be something like that, I'll never get used to Linux's case sensitivity. I'll try it later.
-
With groovymame 0.145 the sound is scratchy (tried with galaga, tekken 3, nba hangtime) :( .
Are there some options I can set/unset?
Finally I could try the Linux version. Everything works fine here with the right options, the sound is smooth and get's adjusted to the action when syncrefresh is used and speed doesn't reach 100% (dkong, dspirit, etc.)
-
Just make sure that the throttle and syncrefresh options are enabled. Possibly try disabling waitvsync.
With throttle, sycrefresh and waitvsync all enabled, the sound is a bit delayed (with Tekken 3 if I hit the opponent, I hear the hit-sound a bit after I should hear it; same with galaga).
Now I will try disabling waitvsync.
-
With throttle, sycrefresh and waitvsync all enabled, the sound is a bit delayed (with Tekken 3 if I hit the opponent, I hear the hit-sound a bit after I should hear it; same with galaga).
Now I will try disabling waitvsync.
I didn't notice that exactly (tested tekken3 and galaga too among others). Please check the speed these games are running. With -syncrefresh enabled, galaga runs at 89% in my system, tekken3 can't remember but it certainly looks like slow motion. So what I noticed is a delay proportional to the speed decrease, and the difference in pitch one would expect. But the sound is not choppy anymore.
-
On my system tekken3 runs at 99% - 100%, galaga at 100% and everything is ok, but sound (for tekken3) is delayed.
-
Anyone fancy to compile a 64-bit binary for the new groovymame? I have a 64-bit hard-drive install and I tried to use the updated 32-bit binary but it was unsuccessful...lots of flickering on my d9200. I've compiled windows binaries before but I'm about useless under linux. I use the live-cd because it "just works" out of the box. :cheers:
My rom set is from .143u9...will the .145 binary cause the cave games to dissapear??
-
I upgraded groovymame patch, so it can be applied to mame 0.145u1.
Compiling notes
Apply patches in this order:
1) 0145u1.diff (http://mamedev.org/updates.html (http://mamedev.org/updates.html))
2) hi_145u1.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
3) 0145u1_groovymame_013e.diff
PS: I also found a bug (in mame core) about ldresample. If you need that binary, don't upgrade.
-
That's great! Thanks :)
-
Anyone fancy to compile a 64-bit binary for the new groovymame?
Why can't you compile it yourself?
It gives you some errors?
My rom set is from .143u9...will the .145 binary cause the cave games to dissapear??
Probably yes.
-
Why can't you compile it yourself?
It gives you some errors?
Well, I understand dmarcum99 here, compiling Mame is not an easy task for everybody.
For instance, I'm compiling the Windows binaries now routinely, but don't have a clue of how to set my system up for Linux compiling. I'd like to, but have read I need Cygwin and stuff...
My rom set is from .143u9...will the .145 binary cause the cave games to dissapear??
That is a fact.
-
Hi Calamity,
I was trying to compile the x64 version of GroovyMAME tonight, and I think I found a small bug that would only affect the Windows x64 version, and only at compile time. In osd\windows\window.c, you're patching in the following snippet:
@@ -1431,6 +1543,8 @@
// syscommands: catch win_start_maximized
case WM_SYSCOMMAND:
{
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", wparam);
+
// prevent screensaver or monitor power events
if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
return 1;
The problem is, in the x64 compiler, the wparam variable (a WPARAM type) is a 64-bit integer, and doesn't like being printf'd as a %d. Casting it to a 32-bit integer lets it compile fine. More info here (http://cboard.cprogramming.com/windows-programming/61677-conversion-wparam-int.html).
This should fix it (it compiles at least, will let you know if I run into any bugs when I get a chance to use it):
@@ -1431,6 +1543,8 @@
// syscommands: catch win_start_maximized
case WM_SYSCOMMAND:
{
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", (UINT32)wparam);
+
// prevent screensaver or monitor power events
if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
return 1;
Cheers - I really appreciate all you're doing for the community!
-
PS: I also found a bug (in mame core) about ldresample. If you need that binary, don't upgrade.
Someone else find it out: bug 4697 (http://www.mametesters.org/view.php?id=4697), bug 4698 (http://www.mametesters.org/view.php?id=4698).
These issues will be fixed in update2.
-
I was trying to compile the x64 version of GroovyMAME tonight, and I think I found a small bug that would only affect the Windows x64 version, and only at compile time. In osd\windows\window.c, you're patching in the following snippet:
Thanks senorchris for pointing this and your explanation, that's true. I had to fix it when building the 64-bit binary but forgot to include it in the diff.
-
I think it's time for official 0.145u1 groovymame patch to be uploded ;D .
-
Any reason why I lose my control settings when updating to this version?
-
does the binary 'groovymame64_0145.013e.rar' have working high score support?
-
Every groovymame binary should have high score support (it's a prerequisite in order to apply groovymame patch).
-
Is it working for you?
-
does the binary 'groovymame64_0145.013e.rar' have working high score support?
Yes it has, but make sure to place the hiscore.dat inside the \hi folder, contrary to other builds where you just place it in MAME's main folder. This was done like this for compatibility with Linux.
-
I don't use the prebuilt binary, I compile groovymame by myself.
Moreover I use it under linux, so I can't test it.
My previous post was only a thought (since I know how the groovymame patch works), for a correct answer we must wait Calamity.
EDIT: @Calamity: posted at the same time...
-
does the binary 'groovymame64_0145.013e.rar' have working high score support?
Yes it has, but make sure to place the hiscore.dat inside the \hi folder, contrary to other builds where you just place it in MAME's main folder. This was done like this for compatibility with Linux.
that did it, cheers!
-
Any chance of a 0.145u4 build? Usually I'm not that fussed about waiting for the next release but in this case I'm keen to try out the new CPS1 clones, especially the so-called "Street Fighter II Champion Final Japanese Version".
-
Version 0.145u4 is uploaded:
http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)
groovymame32_0145u4.013f.rar
groovymame64_0145u4.013f.rar
groovymame32_0145.013e_wiimote_linux.tar.bz2
groovymame64_0145.013e_wiimote_linux.tar.bz2
0145u4_groovymame_013f.diff
Thanks go to:
- VeS for building the Linux binaries including Wiimote support.
Compiling notes
Apply patches in this order:
1) 0145u1.diff -> 0145u2.diff -> 0145u3.diff -> 0145u4.diff
2) hi_145u1.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
3) 0145u4_groovymame_013f.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
Notes about the 013f groovymame patch
The syncrefresh option has been slightly modified since it was moved back to the core in patch 013e, now it works smoother when pausing/resuming, etc. Basically I have reconstructed the implementation that once existed in MAME v0.113, when the throttle function still checked for syncrefresh. Since MAME v0.114, the throttle mechanism and the syncrefresh option were separated, as the throttle function was moved into the core but the syncrefresh was kept -inexplicably- in the OSD part. For the first time, I'm considering submiting this as a patch for main line MAME.
For some reason, the OS independent 'soundsync' patch introduced in 013e can break the sound in Linux, this happens when pausing/resuming, but also can produce some lag issues it seems. Until we figure out the reason, it's possible to disable it by commenting these lines in src\emu\video.c:
void video_manager::recompute_speed(attotime emutime)
[...]
//if (m_syncrefresh && m_throttle)
// m_speed = m_speed_percent * 1000;
Patch 013f also fixes a problem with -changeres that still remained, and caused games to lock under some circumstances. Hopefully this is finally fixed.
-
Quick question about the filename, does the '013f' indicate the version of the groovymame patches?
-
Quick question about the filename, does the '013f' indicate the version of the groovymame patches?
That's it.
013f fixes some problems with the -changeres option, will add extended info later...
-
Cool, would like to know whats new so I can test it out..
off to try a few of my problem games from 0.145 build see if there is any difference
-
Thanks for the v0.145u4 build and upload Calamity! Much appreciated. I'm halfway through installing the external controls on my Blaupunkt television. Once that's done this new build will be a nice way to celebrate! :) Cheers!
-
Didn't want to make a new thread for this, but congrats and good luck to Calamity!
http://forum.arcadecontrols.com/index.php?topic=118940.0 (http://forum.arcadecontrols.com/index.php?topic=118940.0)
-
Yes it's been a nice surprise :)
Thanks!!!
-
Congrats on the nomination! After all the help you've given me over the last 6 months, well, I had to vote for you! ;D
-
This is really useful....
I am having one issue. I used the "hack" to get Groovymame and HyperSping to get along. The first time I did something wrong because I got alot of black screens with sound until I changed to D3D. That problem is now solved, EXCEPT that Tempest is still having that issue.
I a using an ATI HD4650 and the log is attached. Can anyone help me troubleshoot this?
Thanks.
-
Hi all,
i've got some troubles getting Mame + groovy patches and SH3 drivers for Gentoo 64bits.
Does someone have a working src archive or a 64bit linux build with Groovy patches and sh3 (even an old version) ?
Thanks in advance ;)
-
Here's my Simpsons log for Calamity to take a look at. Music way out of sync, running between 95% and 103% Cheers!
-
This is really useful....
I am having one issue. I used the "hack" to get Groovymame and HyperSping to get along. The first time I did something wrong because I got alot of black screens with sound until I changed to D3D. That problem is now solved, EXCEPT that Tempest is still having that issue.
I a using an ATI HD4650 and the log is attached. Can anyone help me troubleshoot this?
Thanks.
Hi milhouse,
Thanks for posting this and sorry for the late answer. This tempest game is interesting, it's reporting a resolution of 640x480 vertical but for some reason it's treated as horizontal by the GroovyMAME patch, so when MAME tries to render the screen rotated it doesn't fit and that's why you see a blank screen.
SwitchRes v0.013e: [tempest] (1) vertical (640x480@60.00)->(640x480@60.00)->(640x480@60.00)
I don't have a clue why this is happening. I don't have a valid tempest rom to try either. Anyway I'll need to have a look at this game.
-
Here's my Simpsons log for Calamity to take a look at. Music way out of sync, running between 95% and 103% Cheers!
Everything looks fine in your log. Please check if your computer is capable of running this games at a constant 100% with regular MAME, or with GroovyMAME and the -nomodeline option.
-
Little update for groovymame patch (to compile against 0.145u6):
--- 0145u4_groovymame_013f.diff 2012-04-12 15:36:38.049538976 +0200
+++ 0145u6_groovymame_013f.diff 2012-04-12 15:36:38.055538820 +0200
@@ -22,7 +22,7 @@
+
// the running machine
#include "machine.h"
- #include "mame.h"
+ #include "driver.h"
diff -Nru src/emu/emu.mak src/emu/emu.mak
--- src/emu/emu.mak 2012-03-17 15:46:18.000000000 +0100
+++ src/emu/emu.mak 2012-03-17 16:45:04.000000000 +0100
@@ -42,7 +42,7 @@
OSDSRC = $(SRC)/osd
OSDOBJ = $(OBJ)/osd
-@@ -317,8 +319,13 @@
+@@ -318,8 +320,13 @@
$(EMUIMAGEDEV)/serial.o \
$(EMUIMAGEDEV)/snapquik.o \
@@ -60,7 +60,7 @@
diff -Nru src/emu/emuopts.c src/emu/emuopts.c
--- src/emu/emuopts.c 2012-03-17 15:46:18.000000000 +0100
+++ src/emu/emuopts.c 2012-03-17 18:19:08.000000000 +0100
-@@ -106,6 +106,7 @@
+@@ -107,6 +107,7 @@
{ OPTION_FRAMESKIP ";fs(0-10)", "0", OPTION_INTEGER, "set frameskip to fixed value, 0-10 (autoframeskip must be disabled)" },
{ OPTION_SECONDS_TO_RUN ";str", "0", OPTION_INTEGER, "number of emulated seconds to run before automatically exiting" },
{ OPTION_THROTTLE, "1", OPTION_BOOLEAN, "enable throttling to keep game running in sync with real time" },
@@ -68,7 +68,7 @@
{ OPTION_SLEEP, "1", OPTION_BOOLEAN, "enable sleeping, which gives time back to other applications when idle" },
{ OPTION_SPEED "(0.01-100)", "1.0", OPTION_FLOAT, "controls the speed of gameplay, relative to realtime; smaller numbers are slower" },
{ OPTION_REFRESHSPEED ";rs", "0", OPTION_BOOLEAN, "automatically adjusts the speed of gameplay to keep the refresh rate lower than the screen" },
-@@ -122,12 +123,12 @@
+@@ -123,12 +124,12 @@
// artwork options
{ NULL, NULL, OPTION_HEADER, "CORE ARTWORK OPTIONS" },
@@ -87,7 +87,7 @@
// screen options
{ NULL, NULL, OPTION_HEADER, "CORE SCREEN OPTIONS" },
-@@ -197,11 +198,37 @@
+@@ -198,11 +199,37 @@
{ OPTION_RAMSIZE ";ram", NULL, OPTION_STRING, "size of RAM (if supported by driver)" },
{ OPTION_CONFIRM_QUIT, "0", OPTION_BOOLEAN, "display confirm quit screen on exit" },
// MKChamp Hiscore Diff options
@@ -235,15 +235,15 @@
diff -Nru src/emu/machine.c src/emu/machine.c
--- src/emu/machine.c 2012-03-17 15:46:18.000000000 +0100
+++ src/emu/machine.c 2012-03-17 16:45:04.000000000 +0100
-@@ -189,6 +189,7 @@
+@@ -188,6 +188,7 @@
+ {
memset(gfx, 0, sizeof(gfx));
- memset(&generic, 0, sizeof(generic));
memset(&m_base_time, 0, sizeof(m_base_time));
+ memset(&switchRes, 0, sizeof(switchRes));
// set the machine on all devices
device_iterator iter(root_device());
-@@ -264,6 +265,9 @@
+@@ -263,6 +264,9 @@
// allocate a soft_reset timer
m_soft_reset_timer = m_scheduler.timer_alloc(timer_expired_delegate(FUNC(running_machine::soft_reset), this));
@@ -256,20 +256,20 @@
diff -Nru src/emu/machine.h src/emu/machine.h
--- src/emu/machine.h 2012-03-17 15:46:18.000000000 +0100
+++ src/emu/machine.h 2012-03-17 16:45:04.000000000 +0100
-@@ -418,6 +418,9 @@
+@@ -407,6 +407,9 @@
// debugger-related information
UINT32 debug_flags; // the current debug flags
+ // SwitchRes patch
-+ SwitchRes switchRes; // SwitchRes data
++ SwitchRes switchRes; // SwitchRes data
+
- // generic pointers
- generic_pointers generic; // generic pointers
-
+ // internal core information
+ palette_private * palette_data; // internal data from palette.c
+ romload_private * romload_data; // internal data from romload.c
diff -Nru src/emu/render.c src/emu/render.c
--- src/emu/render.c 2012-01-24 15:18:56.000000000 +0100
+++ src/emu/render.c 2012-03-17 16:45:04.000000000 +0100
-@@ -1203,10 +1203,54 @@
+@@ -1204,10 +1204,54 @@
void render_target::compute_visible_area(INT32 target_width, INT32 target_height, float target_pixel_aspect, int target_orientation, INT32 &visible_width, INT32 &visible_height)
{
float width, height;
@@ -326,7 +326,7 @@
{
// start with the aspect ratio of the square pixel layout
width = m_curview->effective_aspect(m_layerconfig);
-@@ -1221,9 +1265,9 @@
+@@ -1222,9 +1266,9 @@
// based on the height/width ratio of the source and target, compute the scale factor
if (width / height > (float)target_width / (float)target_height)
@@ -338,7 +338,7 @@
}
// stretch-to-fit case
-@@ -1231,12 +1275,12 @@
+@@ -1232,12 +1276,12 @@
{
width = (float)target_width;
height = (float)target_height;
@@ -354,7 +354,7 @@
}
-@@ -1343,7 +1387,7 @@
+@@ -1344,7 +1388,7 @@
root_xform.yscale = (float)visheight;
root_xform.color.r = root_xform.color.g = root_xform.color.b = root_xform.color.a = 1.0f;
root_xform.orientation = m_orientation;
@@ -363,7 +363,7 @@
// iterate over layers back-to-front, but only if we're running
if (m_manager.machine().phase() >= MACHINE_PHASE_RESET)
-@@ -1372,7 +1416,7 @@
+@@ -1373,7 +1417,7 @@
item_xform.color.b = curitem->color().b * root_xform.color.b;
item_xform.color.a = curitem->color().a * root_xform.color.a;
item_xform.orientation = orientation_add(curitem->orientation(), root_xform.orientation);
@@ -1932,7 +1932,7 @@
diff -Nru src/mame/drivers/galaxian.c src/mame/drivers/galaxian.c
--- src/mame/drivers/galaxian.c 2012-03-17 15:45:37.000000000 +0100
+++ src/mame/drivers/galaxian.c 2012-03-17 16:45:05.000000000 +0100
-@@ -2016,7 +2016,7 @@
+@@ -2113,7 +2113,7 @@
static MACHINE_CONFIG_START( galaxian_base, galaxian_state )
/* basic machine hardware */
@@ -1941,7 +1941,7 @@
MCFG_CPU_PROGRAM_MAP(galaxian_map)
MCFG_CPU_VBLANK_INT("screen", interrupt_gen)
-@@ -2119,7 +2119,7 @@
+@@ -2216,7 +2126,7 @@
MCFG_CPU_VBLANK_INT("screen", fakechange_interrupt_gen)
/* basic machine hardware */
@@ -1950,7 +1950,7 @@
MCFG_CPU_PROGRAM_MAP(tenspot_select_map)
//MCFG_CPU_VBLANK_INT("screen", nmi_line_pulse)
-@@ -2235,7 +2235,7 @@
+@@ -2328,7 +2328,7 @@
MCFG_CPU_IO_MAP(mshuttle_portmap)
/* sound hardware */
-
That's great Ansa89, thanks a lot!
-
I'm having the same problem...Mame .145 and Tempest audits good...boots to a black screen.
-
I'm having the same problem...Mame .145 and Tempest audits good...boots to a black screen.
I have galaga that boots to a blank screen but audio continues. If I disable hlsl it works.
-
Compiling notes
Apply patches in this order:
1) hi_145.txt (http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
2) 0145_groovymame_013e.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/))
This is consistently failing to compile for me at the same place:
Compiling src/mame/drivers/taitopjc.c...
src/mame/video/taitojc.c: In function 'UINT32 screen_update_taitojc(device_t*, s
creen_device&, bitmap_ind16&, const rectangle&)':
src/mame/video/taitojc.c:318: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [obj/windows64/mame/video/taitojc.o] Error 1
make: *** Waiting for unfinished jobs....
F:\mamesrc>
I am using MAME 145 (no 'u') source with the above two diffs applied in the correct order under WinXP x64 with 64-bit MinGW (no compiler front end, just Mr. Do's instructions).
Anyone else seeing this? Any suggestions?
-
Could be related to this (http://forum.arcadecontrols.com/index.php?topic=110905.msg1252812#msg1252812)?
Moreover, remember there is a precompiled executable for windows.
-
Could be related to this (http://forum.arcadecontrols.com/index.php?topic=110905.msg1252812#msg1252812)?
Moreover, remember there is a precompiled executable for windows.
I applied the fix in the post you linked to the groovymame diff and did a clean compile but it still failed with the same error.
I'm still getting nag screens with the precompiled groovymame executable. Am I doing something wrong?
-
Hi Megaweapon,
The error you are reporting is a segmentation fault of the compiler itself, not an error in the source code. Try using MAME Compiler, it's what I use to make the Windows builds.
The nag screens are enabled by default so we don't violate MAME's license. You need to manually disable it through the option you'll find inside mame.ini (generated by groovymame).
-
Hi Calamity,
I was trying to compile the x64 version of GroovyMAME tonight, and I think I found a small bug that would only affect the Windows x64 version, and only at compile time. In osd\windows\window.c, you're patching in the following snippet:
@@ -1431,6 +1543,8 @@
// syscommands: catch win_start_maximized
case WM_SYSCOMMAND:
{
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", wparam);
+
// prevent screensaver or monitor power events
if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
return 1;
The problem is, in the x64 compiler, the wparam variable (a WPARAM type) is a 64-bit integer, and doesn't like being printf'd as a %d. Casting it to a 32-bit integer lets it compile fine. More info here (http://cboard.cprogramming.com/windows-programming/61677-conversion-wparam-int.html).
This should fix it (it compiles at least, will let you know if I run into any bugs when I get a chance to use it):
@@ -1431,6 +1543,8 @@
// syscommands: catch win_start_maximized
case WM_SYSCOMMAND:
{
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", (UINT32)wparam);
+
// prevent screensaver or monitor power events
if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
return 1;
Cheers - I really appreciate all you're doing for the community!
I don't have a system that I can compile this on at the moment to test, but I think that a better solution than casting the WPARAM is to use %p as the format instead of %d. WPARAM is a pointer. %p should print the pointer in hexadecimal regardless of size without truncating.
-
Hi guys,
Chris Kennedy (bitbytebit), the GroovyMAME/GroovyArcade creator as you know, is not going to be actively involved with the project for a while, hopefully we have him back here at some point. He proposed Ves and I to open a new site to host the project files. By now, we've started a project in Google Code:
http://code.google.com/p/groovyarcade/ (http://code.google.com/p/groovyarcade/)
This site will contain GroovyMAME binaries, diff files and other related stuff. We still need to set up the git so you can browse the source code etc., otherwise I don't believe we'll be allowed to nest in there for too long. We'll probably need to open a separate ftp at some point to host the GroovyArcade iso files.
My intention is to keep GroovyMAME updated to mainline MAME, it's a big challenge considering I'm not a C++ programmer. VeS for his part will keep GroovyArcade updated to the Linux kernel. I like to think of this project as a collective task, so don't hesitate to get involved.
An interesting battlefront could be updating the Switchres code. Since Chris integrated Switchres into MAME, so GroovyMAME was born, the Switchres project has been somewhat frozen. All the attention and development went into GroovyMAME, so the Switchres standalone program now lacks many of the features that were added to GroovyMAME recently.
On the other hand, the GroovyMAME patch needs a partial rewrite. Though it has worked quite well for most situations, your intensive tests have revealed many issues here and there that need to get targeted at some point. Most of these issues point to the project's real Achilles heel, the routine that's resposible for picking the best mode from the ones available in the system. But also the way the monitor_specs are defined needs to be slightly changed so the user can finally get full control on the modeline generator's output.
As for the CRT_Emudriver, well I don't think those can fit in Google Code, mainly because of their hacky nature, but also because the Google Code is only supposed to host binaries from the project's open source code. So by now they'll be available from download sites like this:
http://hotfile.com/dl/153631406/c6c491e/crt_emudriver_6.5_1.2_x64_multisync.rar.html (http://hotfile.com/dl/153631406/c6c491e/crt_emudriver_6.5_1.2_x64_multisync.rar.html)
http://hotfile.com/dl/153629728/4e81a27/crt_emudriver_6.5_1.2_xp32_multisync.rar.html (http://hotfile.com/dl/153629728/4e81a27/crt_emudriver_6.5_1.2_xp32_multisync.rar.html)
http://hotfile.com/dl/153633303/6af9a89/crt_emudriver_9.3_1.2a_x64_multisync.rar.html (http://hotfile.com/dl/153633303/6af9a89/crt_emudriver_9.3_1.2a_x64_multisync.rar.html)
http://hotfile.com/dl/153632251/22a3edd/crt_emudriver_9.3_1.2a_xp32_multisync.rar.html (http://hotfile.com/dl/153632251/22a3edd/crt_emudriver_9.3_1.2a_xp32_multisync.rar.html)
Someone suggested the possibility to provide diffs or a patcher for the Catalyst stuff instead of the full binary download in order to keep safe. Well, that would be possible but unfortunately there's more than patching the files. In order to get Windows to accept the drivers you need to obtain new hashes with a specific tool that's only available from Microsoft SDK. After my experience solving people's plain drivers installation related issues, trust me when I say that this route is not viable.
-
Shame about Chris leaving the project, i sure hope he is in good health and so will be onboard aagin soon?
But im glad that this project is being kept alive as it is a godsend for us anal MAME'ers, keep up the sterling work Calamity and Ves!!. Hopefully the little bugs GrooyMAME has get squashed at soon
-
My intention is to keep GroovyMAME updated to mainline MAME, it's a big challenge considering I'm not a C++ programmer.
A lofty ambition! Sounds like some exciting things are on the way, time permitting...
Thanks again for all the work you guys have put in! :) You've re-defined just how perfect "arcade perfect" emulation can be. ;)
-
I hope you'll manage to keep up the good work guys!
I'm not a C++ programmer, but I have a lot of space on my FTP server. If you need a place to store your files or just a mirror, send me a message :)
Good luck and thanks for your amazing version of mame!
-
On the other hand, the GroovyMAME patch needs a partial rewrite. Though it has worked quite well for most situations, your intensive tests have revealed many issues here and there that need to get targeted at some point. Most of these issues point to the project's real Achilles heel, the routine that's resposible for picking the best mode from the ones available in the system. But also the way the monitor_specs are defined needs to be slightly changed so the user can finally get full control on the modeline generator's output.
I'm excited about the Google Code site. I think the project can really benefit from some proper bug tracking and wiki documentation.
I think one thing that's really needed is a list of specific problem games and edge cases so that each build can be properly regression tested.
-
A little typo in the main description: "It uses AdvanceMAME or" should be "It uses AdvanceMenu or".
-
Is there a new version of VMmaker out?, as i noticed in Calamity's Monitor Present thread that one of the default modeline spec is 'CGA' but in the version of VMMaker i have there is no 'CGA'?
-
Is there a new version of VMmaker out?, as i noticed in Calamity's Monitor Present thread that one of the default modeline spec is 'CGA' but in the version of VMMaker i have there is no 'CGA'?
I've attached the latest beta (I already did it in some other thread).
This one has native support for magic resolutions (you only need to use the right option in the ini), uses the same format for monitor_specs as GroovyMAME, and should work more eficiently when creating mode list for multisync setups.
The CGA setup is not in VMMaker, I just added it to that post because it's the values GM picks by default (and labels as 'cga' in the logs).
-
A little typo in the main description: "It uses AdvanceMAME or" should be "It uses AdvanceMenu or".
Well spotted, thanks.
-
I'm excited about the Google Code site. I think the project can really benefit from some proper bug tracking and wiki documentation.
I think one thing that's really needed is a list of specific problem games and edge cases so that each build can be properly regression tested.
The Google Code thing is quite a new one to me, hopefully we figure it out and can benefit from its features.
I get your point on the test list of games, it's something that I really want to get done soon.
-
I hope you'll manage to keep up the good work guys!
I'm not a C++ programmer, but I have a lot of space on my FTP server. If you need a place to store your files or just a mirror, send me a message :)
Good luck and thanks for your amazing version of mame!
Thanks a lot for your offering, this could be a nice solution actually. Well I don't know how much bandwidth this can actually consume, probably the isos are the most problematic thing to host, I don't think these are downloaded by thousands anyway...
-
I hope you'll manage to keep up the good work guys!
I'm not a C++ programmer, but I have a lot of space on my FTP server. If you need a place to store your files or just a mirror, send me a message :)
Good luck and thanks for your amazing version of mame!
Thanks a lot for your offering, this could be a nice solution actually. Well I don't know how much bandwidth this can actually consume, probably the isos are the most problematic thing to host, I don't think these are downloaded by thousands anyway...
I have sent you a private message.
Best regards.
-
Is there a new version of VMmaker out?, as i noticed in Calamity's Monitor Present thread that one of the default modeline spec is 'CGA' but in the version of VMMaker i have there is no 'CGA'?
I've attached the latest beta (I already did it in some other thread).
This one has native support for magic resolutions (you only need to use the right option in the ini), uses the same format for monitor_specs as GroovyMAME, and should work more eficiently when creating mode list for multisync setups.
The CGA setup is not in VMMaker, I just added it to that post because it's the values GM picks by default (and labels as 'cga' in the logs).
Ok cool, just that ive got hold a, HANTAREX CT 28 EQ MONITOR the type thats in a TV case. As its a CGA monitor just wanted to know if i use that as monitor type or edit the monitor_spec line?
-
Thanks A LOT to Abubu for providing us with a ftp for hosting the GroovyArcade iso files.
Now the download links can be found in the main page at http://code.google.com/p/groovyarcade/ (http://code.google.com/p/groovyarcade/)
-
Update groovymame 145u8
Calamity please review the updated
Groovymame145u8 windows
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
I will try to make the linux version this afternoon.
Thank you very much Abubu!!!!
-
Very nice, any chance of a 64 bit build please?
Thanks for all the effort guys, really appreciate it
-
GroovyMAME 0.145u8 64 bit build uploaded...
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
Thank you for continued support for this amazing project. I used to have Groovy Arcade Linux installed on my cab. It was a version before Groovy used Linux kernel version >= 3. Yesterday, I tried to update my installation. Unfortunately I didn't remember all the tweaks I made last time to get it running. My problems were following:
1) I couldn't get the wlan adapter to work. With the old setup it didn't work either before I manually edited the wpa_supplicant.conf file. I only had to edit the proto (protocol) to get it work last time, but now it doesn't help. If I run wpa_supplicant -B -Dwext -c/etc/wpa_supplicant.conf -iwlan0 and after that dhcpcd wlan0 the machine is now connected. It just that those things are not happening when the system boot automatically, or am I missing something essential (probably)?
2) Even bigger problem is that I cannot start Advmenu Frontend or Groovymame. Some text is displayed and after that Groovy Arcade Linux setup screen is displayed. If I select "Exit to shell" and try to start Advmenu by typing advmenu, I get an error just saying "Illegal command(or instruction [I don't remember now which])". If I try to start Groovymame by typing groovymame I get error message saying "Can't open display". I kind of remember that I changed the mame.ini video to soft instead of opengl previously, but that can be a false memory. I tried it now with the new version as well, but it didn't make a difference.
My setup is fairly antique. Pentium IV and Radeon 7000 (AGP), but it used to work previously. Of course if it is not anymore supported, I have to upgrade it or get the old version back. The new version I tried was this: http://www.aburamushi.net/calamity/GroovyArcade-Arch2012.03.25-i686.iso (http://www.aburamushi.net/calamity/GroovyArcade-Arch2012.03.25-i686.iso)
-
In attach the updated patch for wiimote support.
-
Thanks ansa89, but the patch worked, had you got any problem? it may be option -p1, right?
-
Hello ufoufo512 ,
Configure wifi on startup, edit /etc/rc.conf and change ethX for wlanX.
If you have problems with video editing grub in the boot and delete splash.
If you have problems advmenu, kills processes pkill advmenu and pkill X , configures the video and try again.
I have the same hardware configuration and it works fine.
Reports log xorg.log etc..
-
had you got any problem?
I succesfully compiled groovymame64-0.145u8 and mame64-0.145u8, but I didn't try it yet.
it may be option -p1, right?
$ mkdir mame
$ cd mame
$ unzip /path/to/mame.zip
/* now apply patches from 0145u1 to 0145u8, then */
$ patch -p1 -i /path/to/WiimoteGroovy145u8.diff
$ make
-
Hello, new versions groovymame 146.
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
Can't wait for the windows versions of 146!
-
Can anyone possibly post Calaimity's CRT Emudrivers for Windows7 x64? (is there such version available that is, or is it just for WinXP?)
Thanks.
-
Can anyone possibly post Calaimity's CRT Emudrivers for Windows7 x64? (is there such version available that is, or is it just for WinXP?)
Hi c0dehunter,
There's no Win7 version available I'm afraid. According to users' experience, the Win7 OS has some severe problems when dealing with low-resolution CRT monitors, compared to WinXP. That's why I recommend WinXP for accurate video emulation on CRT devices. This might change in the future as new developments happen, but my own priorities are more on the direction of supporting newer AMD chipsets than newer Windows generations.
-
GroovyMAME 0.146 for Windows 32bit/64bit:
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
Enjoy!
-
Your the man! installed 146 this morning using switchers and its just not quite the same. :notworthy: :notworthy:
-
Wow! Thanks! I really appreciate it!
-
Talking about this switchres (http://groovyarcade.googlecode.com/files/SwitchResLinux-1.443-ced8096.tbz) it's a bit outdated:
--- a/monitor.c 2011-01-20 22:50:20.000000000 +0100
+++ b/monitor.c 2011-05-14 23:03:23.873489220 +0200
@@ -44,7 +44,23 @@
}
int SetMonitorMode(char *type, MonitorMode monitor[MAX_MODES]) {
- if (!strcmp(type, "d9800") || !strcmp(type, "d9400")) {
+ if (!strcmp(type, "m2929")) {
+ monitor[0].HfreqMin = 30000;
+ monitor[0].HfreqMax = 40000;
+ monitor[0].VfreqMin = 47;
+ monitor[0].VfreqMax = 90;
+ monitor[4].HfrontPorch = 0.636;
+ monitor[4].HsyncPulse = 3.813;
+ monitor[4].HbackPorch = 1.906;
+ monitor[4].VfrontPorch = 0.020;
+ monitor[4].VsyncPulse = 0.106;
+ monitor[4].VbackPorch = 0.607;
+ monitor[4].HsyncPolarity = 1;
+ monitor[4].VsyncPolarity = 1;
+ monitor[4].ActiveLinesLimit = 576;
+ monitor[4].VirtualLinesLimit = 768;
+ return 1;
+ } else if (!strcmp(type, "d9800") || !strcmp(type, "d9400")) {
/* CGA */
monitor[0].HfreqMin = 15250;
monitor[0].HfreqMax = 18000;
@@ -136,7 +152,7 @@
monitor[5].ActiveLinesLimit = 600;
monitor[5].VirtualLinesLimit = 768;
return 6;
- } else if (!strcmp(type, "d9200")) {
+ } else if (!strcmp(type, "d9200") || !strcmp(type, "m3192")) {
/* CGA */
monitor[0].HfreqMin = 15250;
monitor[0].HfreqMax = 16500;
@@ -148,8 +164,13 @@
monitor[0].VfrontPorch = 0.190;
monitor[0].VsyncPulse = 0.191;
monitor[0].VbackPorch = 1.018;
- monitor[0].HsyncPolarity = 0;
- monitor[0].VsyncPolarity = 0;
+ if (!strcmp(type, "d9200")) {
+ monitor[0].HsyncPolarity = 0;
+ monitor[0].VsyncPolarity = 0;
+ } else {
+ monitor[0].HsyncPolarity = 1;
+ monitor[0].VsyncPolarity = 1;
+ }
monitor[0].ActiveLinesLimit = 288;
monitor[0].VirtualLinesLimit = 448;
/* EGA */
@@ -163,8 +184,13 @@
monitor[1].VfrontPorch = 0.451;
monitor[1].VsyncPulse = 0.164;
monitor[1].VbackPorch = 1.048;
- monitor[1].HsyncPolarity = 0;
- monitor[1].VsyncPolarity = 0;
+ if (!strcmp(type, "d9200")) {
+ monitor[1].HsyncPolarity = 0;
+ monitor[1].VsyncPolarity = 0;
+ } else {
+ monitor[1].HsyncPolarity = 1;
+ monitor[1].VsyncPolarity = 1;
+ }
monitor[1].ActiveLinesLimit = 384;
monitor[1].VirtualLinesLimit = 768;
/* VGA */
@@ -178,26 +204,34 @@
monitor[2].VfrontPorch = 0.318;
monitor[2].VsyncPulse = 0.064;
monitor[2].VbackPorch = 1.048;
- monitor[2].HsyncPolarity = 0;
- monitor[2].VsyncPolarity = 0;
+ if (!strcmp(type, "d9200")) {
+ monitor[2].HsyncPolarity = 0;
+ monitor[2].VsyncPolarity = 0;
+ } else {
+ monitor[2].HsyncPolarity = 1;
+ monitor[2].VsyncPolarity = 1;
+ }
monitor[2].ActiveLinesLimit = 576;
monitor[2].VirtualLinesLimit = 768;
- /* SVGA */
- monitor[3].HfreqMin = 37000;
- monitor[3].HfreqMax = 38000;
- monitor[3].VfreqMin = 40;
- monitor[3].VfreqMax = 80;
- monitor[3].HfrontPorch = 1.000;
- monitor[3].HsyncPulse = 3.200;
- monitor[3].HbackPorch = 2.200;
- monitor[3].VfrontPorch = 0.020;
- monitor[3].VsyncPulse = 0.106;
- monitor[3].VbackPorch = 0.607;
- monitor[3].HsyncPolarity = 0;
- monitor[3].VsyncPolarity = 0;
- monitor[3].ActiveLinesLimit = 600;
- monitor[3].VirtualLinesLimit = 768;
- return 4;
+ if (!strcmp(type, "d9200")) {
+ /* SVGA */
+ monitor[3].HfreqMin = 37000;
+ monitor[3].HfreqMax = 38000;
+ monitor[3].VfreqMin = 40;
+ monitor[3].VfreqMax = 80;
+ monitor[3].HfrontPorch = 1.000;
+ monitor[3].HsyncPulse = 3.200;
+ monitor[3].HbackPorch = 2.200;
+ monitor[3].VfrontPorch = 0.020;
+ monitor[3].VsyncPulse = 0.106;
+ monitor[3].VbackPorch = 0.607;
+ monitor[3].HsyncPolarity = 0;
+ monitor[3].VsyncPolarity = 0;
+ monitor[3].ActiveLinesLimit = 600;
+ monitor[3].VirtualLinesLimit = 768;
+ return 4;
+ } else
+ return 3;
} else if (!strcmp(type, "ega")) {
monitor[0].HfreqMin = 24960;
monitor[0].HfreqMax = 24960;
@@ -231,10 +265,10 @@
monitor[0].VirtualLinesLimit = 768;
return 1;
} else if (!strcmp(type, "multi")) {
- monitor[0].HfreqMin = 31500;
- monitor[0].HfreqMax = 60000;
- monitor[0].VfreqMin = 50;
- monitor[0].VfreqMax = 80;
+ monitor[0].HfreqMin = 54200;
+ monitor[0].HfreqMax = 83800;
+ monitor[0].VfreqMin = 49;
+ monitor[0].VfreqMax = 75;
monitor[0].HfrontPorch = 1.000;
monitor[0].HsyncPulse = 3.200;
monitor[0].HbackPorch = 2.200;
--- a/switchres.h 2011-02-08 19:36:48.000000000 +0100
+++ b/switchres.h 2011-05-14 23:03:23.874489195 +0200
@@ -27,7 +27,7 @@
#define MAX_MODES 10
#define MAX_MODELINES 512
-#define MONITOR_TYPES "[cga ega vga multi ntsc pal h9110 d9200 d9800]"
+#define MONITOR_TYPES "[cga ega vga multi ntsc pal h9110 d9200 d9800 m3192 m2929]"
#define RESULT_RES_INC 0x00000001
#define RESULT_RES_DEC 0x00000002
--- a/version.h 2011-02-10 00:12:21.000000000 +0100
+++ b/version.h 2011-05-14 09:38:11.113242300 +0200
@@ -1,6 +1,6 @@
-#define VERSION "1.443-ced8096"
-#define NUMBER_VERSION "1.443-ced8096"
+#define VERSION "1.565M-774c0a9"
+#define NUMBER_VERSION "1.565M-774c0a9"
#define SYSTEM_VERSION "Linux mcp 2.6.38-rc3+ #1 SMP Thu Feb 3 19:23:12 CST 2011 x86_64 Intel(R) Xeon(TM) CPU 3.40GHz GenuineIntel GNU/Linux"
#define BUILD_DATE "Wed Feb 9 17:12:21 CST 2011"
#define MACHINE "x86_64"
#define OS "Linux"
-
Hi Ansa, so you mean there was a newer version of Switchres than the one we have in the site? Did you obtain this diff out of it?
Thanks!
-
Yes, I got the diff from my local cloned branch of (deprecated) groovyarcade git repo.
-
Hey Calamity,
The link to the ATI Drivers file in the first post is still to mame.groovy.org -- is that file available elsewhere?
Thanks.
-
The link to the ATI Drivers file in the first post is still to mame.groovy.org -- is that file available elsewhere?
I've got a mirror here...
http://mame.3feetunder.com/windows-ati-crt-emudriver/ (http://mame.3feetunder.com/windows-ati-crt-emudriver/)
-
Thanks, sir! May be worth updating the original post if possible with that link.
-
Thanks, sir! May be worth updating the original post if possible with that link.
Done!
-
GroovyMAME 0.146u1 32/64-bit binaries:
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
Diff Changes to Makefile?
When I apply the Groovy MAME diffs from here:
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
Only the 0142_groovymame.diff modifies the Makefile and produces the groovymame64.exe binary.
The others make no mention of the makefile and thus only generate regular mame64.exe binaries.
Tried:
0145_groovymame_013e.diff
0145u8_groovymame_013f.diff
0146_groovymame_013f.diff
0146u1_groovymame_013f.diff
None of these change the makefile or build groovymame64.exe.
How are these supposed to work?
Do they work for everyone else?
Thanks!
-
Hi dgame,
Don't worry about the exe being created as "mame", it's actually GroovyMAME, I just rename it manually. I don't include the makefile change in my diffs any more because it's outside of the src folder and I just use this folder to create the diffs.
-
Thanks! The name and the game info screens being on by default threw me off.
I'm using the 146 diffs.
Has anyone experienced slowdowns in things like sfa2 intro?
Run sfa2 and hit F11.
Before I get to the warning screen, and during the intro, the speed with quickly drop to 94% and then jump back to 100%.
This produces a warble in the sound. I don't get speed drop this with stock MAME (v146) or CabMAME (v145.)
I was testing using the AVGA3000 and an LCD screen on the DVI port so that may be affecting the timing.
Any ideas? Settings I should try?
The fan died on my AVGA so I didn't get a chance to hook it to the 15k monitor. Will test later.
Thanks again!
-
It works! I had some CPU / Temperature monitor programs running in the background.
Turned them off and now the game speed is steady after the initial quick slowdown.
Will start a new thread if I have further issues.
THANKS!!!
-
Good to hear that, dgame.
-
Calamity, have noticed with the 64bit version that the games run way too fast i have to press the F10 key to get them to run at normal speeds and enable throttle in the mame.ini file, is this how it should be??
For my setup, LCD 1080p display, Nvidia card and powerstrip is everything set correctly for this type of configuration in the attached mame.ini (txt file)??
-
Hi lettuce,
Do you mean GroovyUME or GroovyMAME?
Anyway, by default -syncrefresh should be enabled. If enabling -syncrefresh results in games running too fast, it means DirectX is not properly reporting the vertical syncs. This can be a problem with the drivers, hardware acceleration, etc. You shouldn't need to press F10 or anything.
GroovyUME/GroovyMAME absolutely need proper vsync support, running it with plain cpu based throttle just results in the usual video artifacts we're trying to avoid.
However, recent versions of the patch require -throttle to be enabled, otherwise -syncrefresh is not considered, probably this was your case if you were using an old mame.ini file.
-
Yeah im the Groovymame build you kindly sent me last week, i dont think that has MESS implemented??
I was using the ini file that was created for 0.144 so it is fairly old. Do i need to have both throttle and -syncrefresh enabled then or just syncrefresh?
I think i had to have disable syncrefresh and enable throttle in version 0.144 of GroovyMAME to lock the game speed as it was going too fast on games like MK (106%) so i believe you suggested me to enable throttling to lock the game at 100% and disable syncrefresh, does that wring any bells??
So now it will be ok to have both enabled?
-
I just moved this topic here to leave the other thread for GroovyUME related topics only.
I was using the ini file that was created for 0.144 so it is fairly old. Do i need to have both throttle and -syncrefresh enabled then or just syncrefresh?
I think i had to have disable syncrefresh and enable throttle in version 0.144 of GroovyMAME to lock the game speed as it was going too fast on games like MK (106%) so i believe you suggested me to enable throttling to lock the game at 100% and disable syncrefresh, does that wring any bells??
So now it will be ok to have both enabled?
Normal setup for newer versions should be:
throttle 1
syncrefresh 1
triplebuffer 0
Now in your case I recommended disabling syncrefresh because your TV was not capable of running at 54 Hz, thus mk got accelerated. The best setup for your case would be:
throttle 1
syncrefresh 0
triplebuffer 1
-
Ok thanks will do. Shame due to make having to select these options the scrolling on MK title screen is not smooth anymore :hissy:. Will there ever be a fix/work around for smooth scrolling with my kind of setup (LCD screen, Nvidia card)??
-
Ok thanks will do. Shame due to make having to select these options the scrolling on MK title screen is not smooth anymore :hissy:. Will there ever be a fix/work around for smooth scrolling with my kind of setup (LCD screen, Nvidia card)??
I told you once that it's as impossible as squaring the circle :)
Unless your screen accepted 54 Hz, which is not the case, you're stuck to either accelerate the game to 60 Hz to get smooth scrolling, or running it at the original 54 Hz with 6 repeated frames so you have 60 in total, which results in crappy scrolling.
That's why me and kalars and some others have been trying to raise awareness in the community on the importance of finding flat screens that allow arbitrary refresh rates.
-
Is there actually LCD display that can accept 54hz then?
-
Just wanna pointing out that groovymame 0.146u1 patch also applies to mame 0.146u2 OOTB.
-
GroovyMAME 0.146u2 32/64-bit binaries:
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
I tried to compile my own GroovyMAME following the instructions in the first post in this thread and the patching failed.
Are the compile instructions still valid?
Are there newer files I should be using than "hi_142.txt" and "0142_hilinux.diff"?
What about the patch instructions? This is what I'm doing...
patch -p0 -E <hi_142.txt
patch -p0 -E <0142_hilinux.diff
patch -p0 -E <0146u2_groovymame_013f.diff
...and I'm using the windows patch utility downloaded from this page on the MAMEDev site...
http://mamedev.org/updates.html (http://mamedev.org/updates.html)
-
These (http://forum.arcadecontrols.com/index.php?topic=110905.msg1259666#msg1259666) are the latest valid instructions.
-
What about the patch instructions? This is what I'm doing...
Hi Krick, I've updated the first post in the thread with the compiling instructions. The hilinux diff is no longer necessary. Sorry for your time. I apply the patches using MAME Compiler 64.
-
Notice that Gyruss is only running at 99% speed and dips sometimes i think the sound sometimes skips ever so slightly aswell, even with these settings:
throttle 1
syncrefresh 0
triplebuffer 1
Any ideas why its not 100%, i though having throttle locks it at 100% speed?
-
Any ideas why its not 100%, i though having throttle locks it at 100% speed?
That game runs at 60.61 Hz, if you use -triplebuffer you need to enable -multithreading too, otherwise the game's speed will be locked the videocard's refresh. Only disable -multithreading for games that use -redraw, like spyhunt.
-
Ok thanks!. Is there a large list of games that use redraw?
-
Ok thanks!. Is there a large list of games that use redraw?
Most are the ones that originaly run at 30 Hz, not many.
-
Information taken from MAME 0.146 (also see attached csv file).
Horizontal Games @ 30Hz:
archrivl
archrivl2
bigrun
blasted
cischeat
crater
dairesya
demoderb
demoderm
domino
dotron
dotrona
dotrone
f1gpstar
f1gpstr2
farwest
intlaser
ironhors
jwildb52
jwildb52a
jwildb52h
kothello
kroozr
maxrpm
nflfoot
pigskin
pigskina
powerdrv
rampage
rampage2
rbtapper
sarge
shangha2
shanghai
spyhunt2
spyhunt2a
stargrds
sutapper
tapper
tappera
timber
twotiger
twotigerc
wacko
wildplt
xenophob
zwackery
Vertical Games @ 30Hz:
armchmp2
armchmp2o
journey
kick
kickc
kickman
scudhamm
shollow
shollow2
solarfox
spyhunt
spyhuntp
trisport
tron
tron2
tron3
tron4
turbotag
-
Thanks for the list Krick!
The problem with the current implementation of the -redraw patch seems to appear only in some machines and just if -multithreading is enabled. I do have an idea of what is happening. I just need to figure out a way of solving it that doesn't involve a specific per OSD implementation.
-
The problem with the current implementation of the -redraw patch seems to appear only in some machines and just if -multithreading is enabled.
Is it related to the issues some people have with spyhunter? That seems to be triggered by multithreading too.
We should try to nail down exactly what cpu/gpu/drivers/operating sytem people have when they see either problem.
-
Is it related to the issues some people have with spyhunter? That seems to be triggered by multithreading too.
We should try to nail down exactly what cpu/gpu/drivers/operating sytem people have when they see either problem.
Yeah I'm talking of the exact same issue with spyhunter that lettuce reported. It's the same bug that makes GM hang on some systems when you launch it without a rom name.
I don't think it's too relevant to know which systems or cpu types are affected. As long as I have one here which always shows the crash (my laptop) I'll be able to catch the bug.
The problem comes from the implementation of the -redraw patch (which we originally took from CabMAME). In our scope it would be cleaner to just schedule two (or more as required) wait for vertical retrace calls instead of calling the whole draw operation more than once, that is causing the crash when in multitasking mode, I believe. The problem is that the wait for vertical retrace is performed in the OSD layer and therefore it has different ddraw/d3d/sdl implementations so that would involve having several instances of the same patch, which I'd hate.
-
any news on a 146u4 update? really wanna play mkII revision 2.0
-
The latest patch can be applied to mame 0.146u4 without big issues, so you can compile, install and play :) .
-
I'll try it tonight, though I'm rubbish at compiling.
-
Hi guys, if nothing fails my holidays start at 14:00 today, I'm eager to have plenty of time for coding.
-
Sweet! Have an awesome vacation!
-
has anyone compiled a 146u4 64 version yet?
-
has anyone compiled a 146u4 64 version yet?
My arcade cab is my only 64-bit machine, and it's down at the moment. So I'm trying to compile groovymame inside VirtualBox running XP x64 on my XP 32-bit machine.
So far the compile hasn't completed successfully. The first few times were from running out of memory in the virtual machine, but the most recent errors seem to be legitimate compile problems. It's possible that the last GroovyMAME patch (0146u2_groovymame_013f.diff) needs tweaking to work with MAME 0.146u4.
-
Hi guys, it won't be possible for me to create new GM builds until next week or so, I don't have my x64 machine around at the moment.
-
If the patch works with latest source, that tool http://headsoft.com.au/index.php?category=mame&page=mc64 (http://headsoft.com.au/index.php?category=mame&page=mc64) is your best hope. I dont have the time now, but will try compiling some u4 versions for everyone interested.
-
GroovyMAME 0.146u4 32/64-bit binaries:
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
Huzzah!!!
Thank you so much
-
Hi guys!
I have a little question about *.cfg/mame.ini in GroovyMame.
Whit the cheat option enabled in mame.ini, is possible the save the sliders positions in the cpu emulated overclock. (For games Metal Slug, Double Dragon, and others...)
I move the sliders to overclock but when i restart the same game in mame, the config is not saved.
Someone know how do that?
Thanks in advance(mame) :D
-
I'm pretty sure this was discussed recently on the MAMEWorld forum. I think that the consensus was that the values for overclocking don't get saved but I don't recall what, if any, solutions were proposed. I've seen people on BYOAC mention overclocking a game using a cheat file, but I don't know how it's done. Maybe you can find that with some googling.
-
Thanks Krick!
Goooooogle is God ;)
-
I'm having trouble installing the 9.3 driver on my x64 install. The installer reports that no compatible hardware has been found, even though I have an HD 4250 (onboard). I tried adding the device id (PCI\VEN_1002&DEV_9715&SUBSYS_97151849) to the CA_76826.inf but apparently that's not enough to fool the installer :-\
Any hints or tips? I'm going to try soft15khz now, but I read that the 60 modelines it is limited to will not suffice for a broad range of games, so I'd rather have the 120 of Calamity's driver :-)
*edit*
I updated CA_768286.INI, INSTALL.INI and Driver.dat as well now and the driver installed. However, after installation it says "fail to set the install registry key" and after a reboot, quickres only shows met 1024x768 as available resolution. I removed all the old driver and catalyst stuff as far as I know (uninstall, cat-uninstall, remove ATI from registry) but it didn't work ??? Any suggestions?
-
Hi boerbiet,
You also need to edit the CA_76826.inf file, inside the XP64_INF folder.
Edit: sorry, I didn't notice you had already done this.
-
The GroovyMAME diff file for u4 on the GroovyArcade site doesn't work with the latest patch tools from the MAME Dev site.
0146u4_groovymame_013f.diff
The problem is that the file paths have a slash in front of them. For example, this...
diff -Nru /src/emu/clifront.c /src/emu/clifront.c
--- /src/emu/clifront.c 2012-08-18 17:31:47.000000000 +0200
+++ /src/emu/clifront.c 2012-08-18 17:37:07.000000000 +0200
...needs to look like this...
diff -Nru src/emu/clifront.c src/emu/clifront.c
--- src/emu/clifront.c 2012-08-18 17:31:47.000000000 +0200
+++ src/emu/clifront.c 2012-08-18 17:37:07.000000000 +0200
The u2 patch didn't have the extra slashes, so it must have been something new about the way the patch was generated.
I've attached a copy of the patch with the extra slashes removed. Note that I had to add a ".txt" to get the forum software to allow me to attach it. Just remove the ".txt" at the end after downloading it.
-
The extra slash is an error and the patch shouldn't work with any patch-program (not only with the latest patch tools from the MAME Dev site).
-
Sorry, that's my error. I usually edit the diff obtained to remove the part of the path before "src", this time I left the slash by mistake. I'll update the diff in the google code site.
-
For people at home who are compiling their own for each MAME "u" release, I've attached an updated GroovyMAME patch for 0.146u5.
The GroovyMAME u4 patch wouldn't apply properly to the MAME u5 code because of some changes to emuopts.h.
Note that this patch doesn't include any changes to GroovyMAME. This is the exact same code as the u4 patch.
Again, I had to add a ".txt" extension to the file so that the forum would allow me to attach the file. Remove the .txt after downloading.
-
Thanks for the update krick!!
I'm busy right now working on a new version of the patch that will be released as 014. I'm afraid I won't be releasing intermediate updated binaries until I finish this, if any one is building his own binaries please feel free to release them. Hopefully I'll have it ready before MAME v0.147 is out.
BTW the SDL sound patch was accepted:
http://git.redump.net/mame/commit/?id=9087f6196e4f53efb9013575ab200eb1fa13f065 (http://git.redump.net/mame/commit/?id=9087f6196e4f53efb9013575ab200eb1fa13f065)
It should be ready for u6, no more soundsync issues for the Linux side ;)
-
Speaking of moving stuff into mainline MAME, I doesn't appear that anything ever became of the issue with integer stretching in Direct3D mentioned here...
http://www.mameworld.info/ubbthreads/showflat.php?Number=291204 (http://www.mameworld.info/ubbthreads/showflat.php?Number=291204)
To summarize, SDL MAME has -nounevenstretch, which, at least at the time of that thread, didn't work properly, and mainline MAME didn't have a method at all.
It would be cool if integer stretching could be implemented in the MAME core but I suspect that it's closely tied to the rendering code for each platform.
-
I'm having some trouble compiling and want to make sure I'm applying the diff's correctly.
I've downloaded the Mame 146 source. I assume this is the latest update as they have moved to 147.
I've applied hi_146u5.txt successfully.
When I try to apply the GroovyMAME patch for 0.146u5 patch posted by Krick I get an error that 1 out of 5 hunks FAILED. Hunk #2 failed at 307 is the specific error.
Any guidance would be appreciated. Thanks.
-
You need to apply all the mame updates in order as described in the first post of this thread...
1) patch 0146u1.diff
2) patch 0146u2.diff
3) patch 0146u3.diff
4) patch 0146u4.diff
5) patch 0146u5.diff
6) patch hi_146u5.txt (get it from http://mamestuff.lowtrucks.net/MKChamp/ (http://mamestuff.lowtrucks.net/MKChamp/))
7) patch 0146u5_groovymame_013f.diff
-
Thanks for the reply Krick. That is what I thought initially but I couldn't find any .diff files posted on the mamedev.org site. I am assuming that once a new version comes they post the previous version with all the updates. If that is not the case can you point me to where I can download all the files you listed?
-
They don't make older updates easy to find. You can download them here...
http://mamedev.org/updates/ (http://mamedev.org/updates/)
Calamity should probably put this link on the first page.
-
Thanks! I will try again tonight after work. :cheers:
They don't make older updates easy to find. You can download them here...
http://mamedev.org/updates/ (http://mamedev.org/updates/)
Calamity should probably put this link on the first page.
-
That did the trick. Thanks again krick.
They don't make older updates easy to find. You can download them here...
http://mamedev.org/updates/ (http://mamedev.org/updates/)
Calamity should probably put this link on the first page.
-
Hello , new update GroovyMame/GroovyUme 147
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
Just a heads-up about MAME 0.147.
All sets in midtunit.c, midwunit.c, midxunit.c: Corrupted graphics, quickly crashes when starting
http://www.mametesters.org/view.php?id=5007 (http://www.mametesters.org/view.php?id=5007)
The affects all Mortal Kombat games, as well as a bunch of other titles.
The fix will be in 0.147u1, or you can grab the fix from the SVN and fix it in 0.147 yourself before building GroovyMAME...
http://git.redump.net/mame/commit/?id=f0dc4a3ce797c41f0a9e94f0277a0247b92b99d0 (http://git.redump.net/mame/commit/?id=f0dc4a3ce797c41f0a9e94f0277a0247b92b99d0)
-
Hello , new update GroovyMame/GroovyUme 147
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
That's great Ves!
All sets in midtunit.c, midwunit.c, midxunit.c: Corrupted graphics, quickly crashes when starting
Well, this gives me a little more time to complete the new patch, I didn't expect the 0.147 version to come out so soon!
-
Thank krick , I have a new updated GroovyMame/Ume with fixed midtunit.c crashes
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
hi ves - i have the lastest edition of your 64-bit groovymame linux cd installed in my cab.
the 0.147 update isn't yet up in the repo for automatic downloading via the cab, and i can see it's up there for manual download.
could you help me on how to update the cabinet manually to 0.147?
thanks
-
I try to help you MonkeyJug:
Donwload 64 bits 0.147 GM from here: http://code.google.com/p/groovyarcade/downloads/detail?name=groovymame64_0147.013f_wiimote_linuxFix.tar.bz2&can=2&q= (http://code.google.com/p/groovyarcade/downloads/detail?name=groovymame64_0147.013f_wiimote_linuxFix.tar.bz2&can=2&q=)
From Groovyarcade Setup Menu, open MC (File Manager)
First, save a backup copy of the actual GA executable from "/usr/games/bin/groovymame" to a safe folder.
Then, replace the file with the new one.
No need to do anything else.
:cheers:
-
hi ves - i have the lastest edition of your 64-bit groovymame linux cd installed in my cab.
the 0.147 update isn't yet up in the repo for automatic downloading via the cab, and i can see it's up there for manual download.
could you help me on how to update the cabinet manually to 0.147?
thanks
Hi MonkeyJug,
I've just updated the 'update' file, the new versions should appear now as available in your cab, please let me know if it worked.
-
hi calamity, it's not working. the latest update is showing as 146u1.013f
:(
-
Try refreshing the list, rebooting, or whatever, the file 'update' has not been downloaded yet by anybody (check download count):
http://code.google.com/p/groovyarcade/downloads/list (http://code.google.com/p/groovyarcade/downloads/list)
-
worked. many thanks!
do i need to do anything else, with regards to mame.ini or similar?
-
Reworked patch for mame 0.147.
Please, when releasing patches, make it standard compliant.
-
Thanks Ansa89, I'll upload it to the google site in a while.
-
Ansa89, two questions:
- When you say standard compliant, you mean the diff paths only, or the DOS/UNIX line endings too? I'm saying this because we always release the diffs with DOS-like line endings and I don't know if that's an issue when patching under Linux.
- Do you know of a way to create the diffs with the proper path format, so that we don't need to edit those manually in a second step?
-
- When you say standard compliant, you mean the diff paths only, or the DOS/UNIX line endings too? I'm saying this because we always release the diffs with DOS-like line endings and I don't know if that's an issue when patching under Linux.
I mean the diff paths only.
The unix line-ending code is my bad, it should be in dos format (since mame uses that code style).
- Do you know of a way to create the diffs with the proper path format, so that we don't need to edit those manually in a second step?
The only way is to have both "src" directories (original and patched) into the current directory, but this is impossible (having two directories with the same name).
You can use this work around: name the original directory as "src_orig" and the patched directory as "src_new", then modify all what you need into "src_new", then run "diff -ruN src_orig src_new > patch.diff", then fix the paths with "sed -i 's:src_orig:src:g' patch.diff" and "sed -i 's:src_new:src:g' patch.diff".
This should do the trick.
-
This time it should be ok.
-
In case anyone cares, there's a tool called srcclean that's shipped with MAME that cleans the source standardizes the line endings.
http://mamedev.org/source/src/tools/srcclean.c.html (http://mamedev.org/source/src/tools/srcclean.c.html)
You may need to build it yourself by doing a "make all".
However, even if we bring the GroovyMAME code up to MAME cleanliness standards using this tool, the high score patch will mess it up because it doesn't follow the standards.
If anyone knows the guy who does the high score patch, tell him to run srcclean on his source before generating his high score patch diff.
-
Hi krick,
That's very interesting indeed, I had no idea it existed. I'll give it a try.
-
I use the well known "dos2unix" (which bring also the opposite tool "unix2dos").
-
The mame tool does other things like indents and braces and comments, I think too.
-
Hi ...
looks like i cannot get 0147 grovvymame to compile on my rig.
Basic 0.147 compile OK, i'm compiling now 0.147 build with HIGH 0.147 and it seems ok ..
I will post the error message with 0.147groovy patch (i've tried the googlecode patch and the two you provided on this thread)
Windows seven 64bits, compilation with mingw64 for a 64bits target from mame dev.
Patch method = patch -p0 < patch.diff
;D
EDIT =
don't worry about make -j12 .. same thing with monothread ^^, i didn't make clean before making this output.
http://pastebin.com/b16JWMtt (http://pastebin.com/b16JWMtt)
-
Give the attached diff a try and let me know if it works. (remove the .txt extension)
Here's the changes I had to make (from the 147 diff posted on the Google Code site)...
1) switchres.c - commented out initialized, but unused variables: lpDeviceName and DesktopBPP
2) window.c - moved misplaced curly brace before (instead of after): else if ((wparam & 0xfff0) == SC_MINIMIZE) ...
3) winmain.c - added two missing lines: extern bool switchres_modeline_ ...
-
Yeahh .. compilation just finished ;D
Thanks :applaud:
now it's time to find a S :censored: 3 patch ^^
-
Thanks a lot for the update Krick. I'm uploading it to the google's code site.
-
I just wanted to let you guys know that I have fully reworked the GroovyMAME's patch, hopefully in a way that will or should fix most of the problems that have been reported during this time, as well as adding some interesting new features. I still need to sort out the Powerstrip integration part. I also need to port the new patch to the Linux side, something I didn't mean to do until everything was rock solid so I'm not overwhelmed by the Linux particularities. There's some work in progress yet so please be patient. I steel need to test this thoroughly before it's released.
-
It sounds very good.
-
Waiting for new version of groovymame, I updated the current version for mame 0.147u1.
-
Thanks for the update Ansa89!
-
I just wanted to let you guys know that I have fully reworked the GroovyMAME's patch, hopefully in a way that will or should fix most of the problems that have been reported during this time, as well as adding some interesting new features.
Sounds really exciting! Can't wait! :)
-
A friend of mine has problems running groovymame on windows:
Trying groovymame 0.147/0.147u1, the emulation is too fast and without 'throttle' (even if this is enabled into mame.ini).
Disabling the multithreading, the emulation speed decrease to 50%, so the result is that every game runs at half of its speed.
Here is the mame configuration:
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
rompath roms
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 0
seconds_to_run 0
throttle 1
syncrefresh 1
sleep 1
speed 1.0
refreshspeed 0
#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
#
# CORE ARTWORK OPTIONS
#
artwork_crop 1
use_backdrops 0
use_overlays 0
use_bezels 0
use_cpanels 0
use_marquees 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
ui_active 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.3
joystick_saturation 0.85
natural 0
joystick_contradictory 0
coin_impulse 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 1
uifont default
ramsize
confirm_quit 0
ui_mouse 0
#
# 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 0
monitor_dotclock 0
monitor_ymin 0
cleanstretch 0
changeres 1
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
magic_resolution auto
powerstrip 0
#
# WINDOWS DEBUGGING OPTIONS
#
oslog 0
watchdog 0
debugger_font "Lucida Console"
debugger_font_size 9
#
# WINDOWS PERFORMANCE OPTIONS
#
priority 0
multithreading 0
numprocessors auto
profile 0
bench 0
#
# WINDOWS VIDEO OPTIONS
#
video ddraw
numscreens 1
window 0
maximize 1
keepaspect 0
prescale 1
waitvsync 1
menu 0
#
# DIRECTDRAW-SPECIFIC OPTIONS
#
hwstretch 0
#
# DIRECT3D-SPECIFIC OPTIONS
#
d3dversion 9
filter 0
#
# DIRECT3D POST-PROCESSING OPTIONS
#
hlsl_enable 0
hlslpath hlsl
hlsl_ini_read 0
hlsl_ini_write 0
hlslini %g
hlsl_prescale_x 0
hlsl_prescale_y 0
hlsl_preset -1
hlsl_write
hlsl_snap_width 2048
hlsl_snap_height 1536
shadow_mask_alpha 0.0
shadow_mask_texture aperture.png
shadow_mask_x_count 320
shadow_mask_y_count 240
shadow_mask_usize 0.09375
shadow_mask_vsize 0.109375
curvature 0.0
pincushion 0.0
scanline_alpha 0.0
scanline_size 1.0
scanline_height 0.7
scanline_bright_scale 1.0
scanline_bright_offset 0.0
scanline_jitter 0.0
defocus 0.0,0.0
converge_x 0.0,0.0,0.0
converge_y 0.0,0.0,0.0
radial_converge_x 0.0,0.0,0.0
radial_converge_y 0.0,0.0,0.0
red_ratio 1.0,0.0,0.0
grn_ratio 0.0,1.0,0.0
blu_ratio 0.0,0.0,1.0
saturation 1.0
offset 0.0,0.0,0.0
scale 1.0,1.0,1.0
power 1.0,1.0,1.0
floor 0.0,0.0,0.0
phosphor_life 0.0,0.0,0.0
yiq_enable 0
yiq_cc 3.59754545
yiq_a 0.5
yiq_b 0.5
yiq_o 0.0
yiq_p 1.0
yiq_n 1.0
yiq_y 6.0
yiq_i 1.2
yiq_q 0.6
yiq_scan_time 52.6
yiq_phase_count 2
#
# 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 1
full_screen_brightness 1.0
full_screen_contrast 1.0
full_screen_gamma 1.0
#
# WINDOWS SOUND OPTIONS
#
audio_latency 2
#
# INPUT DEVICE OPTIONS
#
dual_lightgun 0
Moreover using groovymame 0.146u4 found here (https://code.google.com/p/groovyarcade/downloads/list), the nag-screen aren't disabled.
Is there anything I can suggest him?
-
Hi Ansa89,
Please ask your friend to try GroovyMame version 0.146u4_013f, which is the most recent currently supported version for Windows. In case he still has issues, let me know.
I have marked the v0.147 patch on the google's code site as "LINUX ONLY" to avoid more confusions.
Hopefully in some days I can move to the new compiling environment and port the patch to the newer versions.
-
Oh ok, I will do.
Thanks a lot.
-
Just another update. I already have the Linux part sorted out. There's still one minor change that needs to be done in order to make it bullet-proof, but for the most part everything is working as expected. Reworking the Linux side has been surprinsingly painless, thanks to the superb job that Chris Kennedy did. Only very little stuff needed to be changed actually to rewire it to the new modeline engine. In comparison to Windows, the Linux way of custom video timing is incredibly straight forward.
I'm really happy with the overall results I'm getting with this new patch, specially how consistent it is: either with ddraw/d3d/sdl you always get the same results with the same settings. Of course, there are still some rough edges here and there, as well as the Powerstrip thing that is the biggest task pending.
One feature that's fully working now is automatic frequency scaling, as an alternative to resolution scaling. This allows you to obtain true low resolutions (i.e. hardware scanlines) for PC CRT monitors that support 120 Hz. I've been playing with this today and it works like a charm.
More updates coming soon.
-
I'm very excited for this upcoming version! Thanks Cal!
-
It's not a modeline, it's a monitor_specs line :) It tells groovymame how your modelines need to be calculated.
Hi Calamity, one question.
I'm using last windows version of Groovymame and I have soft-15KHz + some custom resolutions.
If I enable the modeline generator I obtain all resolutions shifted to the left (or right I don't remember) and these resolutions are brighter.
Is there anything I can do to fix center issue and excessive brightness? Maybe something with monitor_specs0 option?
Thanks
-
Hi Calamity, one question.
I'm using last windows version of Groovymame and I have soft-15KHz + some custom resolutions.
If I enable the modeline generator I obtain all resolutions shifted to the left (or right I don't remember) and these resolutions are brighter.
Of course that can get fixed, specially if it's a consistent issue, that's the main point of GroovyMAME.
The problem seems to be the different relative size of the borders used by Soft-15Khz's modelines and GroovyMAME. If you want to keep the modes with the same size and centering than the Soft-15Khz modelines, set one of them full screen by means of Arcade_OSD and write down the geometry values (timing) of both horizontal porches. Then use those values for creating a monitor_specs0 line, let me know if you need some help.
Oh, as for the brightness issue, that must be due to the bad combination of horizontal porches and your current setting of h-phase pot, it should get fixed once the modes are properly centered.
-
Great news!
Sadly I can't use the (excellent and very useful) Arcade_OSD because I have issues using your CRT_Emudriver. This because I have 2 ati cadrs: an Ati HD4650 PCI-Ex and an old Ati 9250 PCI setted as primary to block 31KHz boot freq.
In windows I get conflicts with the two cards and I can't put system in hybernation. With the ati Catalyst 10.3 all works fine.
This is a resolution that is perfectly centered and covers all the screen:
Modeline "640x240_60 15,9KHz 59,7Hz" 13.220 640 672 736 832 240 243 246 266 -hsync -vsync
I got this values from winmodelines:
(http://i49.tinypic.com/2el57o8.jpg)
Can I set monitor_specs0 with these values? Can you help me because I don't know what to put in?
Thanks!!!
PS: I have a standard 15KHz Intervideo arcade monitor (VP280) with these values on the manual:
Horizontal scan frequency: 15,625KHz +/- 500Hz
Vertical scan frequency: 50Hz
-
Well ..
i've got a little problem with 0.147u1 :
Compiling src/osd/sdl/gl_shader_tool.c...
src/osd/sdl/switchres.c: In function 'bool switchres_resolution_change(running_machine&, sdl_window_info*, int, int)':
src/osd/sdl/switchres.c:223:23: error: variable 'oldheight' set but not used [-Werror=unused-but-set-variable]
cc1plus: all warnings being treated as errors
Do you have any idea ?
Thanks
-
Compile with "NOWERROR=1".
-
thanks, it works ;D
-
Just another update. I already have the Linux part sorted out. There's still one minor change that needs to be done in order to make it bullet-proof, but for the most part everything is working as expected. Reworking the Linux side has been surprinsingly painless, thanks to the superb job that Chris Kennedy did. Only very little stuff needed to be changed actually to rewire it to the new modeline engine. In comparison to Windows, the Linux way of custom video timing is incredibly straight forward.
I'm really happy with the overall results I'm getting with this new patch, specially how consistent it is: either with ddraw/d3d/sdl you always get the same results with the same settings. Of course, there are still some rough edges here and there, as well as the Powerstrip thing that is the biggest task pending.
One feature that's fully working now is automatic frequency scaling, as an alternative to resolution scaling. This allows you to obtain true low resolutions (i.e. hardware scanlines) for PC CRT monitors that support 120 Hz. I've been playing with this today and it works like a charm.
More updates coming soon.
Any news?
(I'm sorry, but the wait is killing me).
-
This is a resolution that is perfectly centered and covers all the screen:
Modeline "640x240_60 15,9KHz 59,7Hz" 13.220 640 672 736 832 240 243 246 266 -hsync -vsync
Hi Haggar,
Try this line:
monitor_specs0 15625-16200, 49.50-65.00, 2.420, 4.700, 7.260, 0.064, 0.160, 1.056, 0, 0, 288, 400
The remarked values are the ones that control horizontal borders/centering, you can play with them.
-
Any news?
(I'm sorry, but the wait is killing me).
Hi Ansa89,
Sorry for the wait, I know I said it would be two weeks. I'm currently working on it. I'm thoroughly testing every aspect of the thing before releasing it. Some of these tests require a specific hardware setup that needs both time and finding a proper moment.
For instance, a couple of days ago I could finally try the combination of NVidia card (yes) + GroovyMAME + Winmodelines + Powerstrip + Windows XP, in order to achieve dynamic modelines, and after some efforts I got it working so good that it even looked an ATI card. Not for novice users I must say, but it opens some interesting new possibilities.
This Powerstrip full integration was the last important feature that was pending, now I only need to refine the LCD support (not that it doesn't work yet, it just needs to become more 'automatic' to set up).
Appart from that, I'd like to redo most of the monitor definitions.
-
OMG! So good!
BTW, I was only interested in news, I don't want to force you to release an untested software/patch; hence keep it only for you and release the patch when you are completely satisfied of it (AKA bug-free).
Thanks for all what you are doing.
-
Thanks for the update!
-
I'm currently working on it.
Sounds really promising! Looking forward to it! :)
-
This is a resolution that is perfectly centered and covers all the screen:
Modeline "640x240_60 15,9KHz 59,7Hz" 13.220 640 672 736 832 240 243 246 266 -hsync -vsync
Hi Haggar,
Try this line:
monitor_specs0 15625-16200, 49.50-65.00, 2.420, 4.700, 7.260, 0.064, 0.160, 1.056, 0, 0, 288, 400
The remarked values are the ones that control horizontal borders/centering, you can play with them.
Thanks!!! :notworthy:
-
Any idea when the next release is coming that fixes the rotational issues?
Thanks
-
Any idea when the next release is coming that fixes the rotational issues?
Thanks
Probably for next week, dealing with final details now before moving to the new environment.
-
GREAT!
I will keep an eye out for it :applaud: