Main > Main Forum
Issue with Windows 7 and native resolutions.
bitbytebit:
--- Quote from: krick on April 15, 2011, 12:07:52 am ---
--- Quote from: bitbytebit on April 14, 2011, 11:36:05 pm ---
I'll upload a new build, 012k, and hopefully it'll fix the issue.
--- End quote ---
Very cool. I'll check it out tomorrow night after work. I also want to try some more games with strange resolutions. Any recommended "problem" games?
I have a few questions...
1) Should I be generating a groovymame.ini? After examining the log file in more detail, I see that the program is generating it's own settings. Wouldn't the settings in the ini file override that and screw stuff up?
2) How does groovymame know that I have an ArcadeVGA? Also, how does it know what resolutions the ArcadeVGA supports, is it determined dynamically from the driver, or is there some sort of hard-coded list within groovymame itself?
3) I noticed that groovymame's output said that it's using "Using DirectDraw 7". Is there a 64-bit version of DirectX 9 that I need to install on my computer? I'm new to Windows 7, so I could be screwing stuff up.
--- End quote ---
Yeah the mame.ini it generates (and it'll be called mame.ini still) should be the best settings generally, unless you have additions like controller settings or monitor type, etc.
It basically looks at the custom modelines first, well you won't have any with an ArcadeVGA3000 card, so then it looks at system resolutions which will exist because the ArcadeVGA3000 resolutions show up there. So then it'll use those, and make decisions of which fits the best. Of course they won't match the games original refresh rates, so things will default to tripplebuffer instead of vsync, you might even want to set soundsync to 1 too because of that. I'm going to have to look at an override for that possibly if the Arcade Perfect utility is used, and the refresh rate is matched, or if the less than perfect 100% running of the game is desired with smooth scrolling, else there might be some slight degradation with even tripplebuffer.
Yeah you can change it to d3d, and it'll work ok now with cleanstretch automatically to avoid the issues there. It just uses ddraw by default since that is technically the best option, unless your using Windows 7 with an ArcadeVGA or other card most likely, and then you need d3d to avoid the other issue there with interlaced resolutions.
krick:
--- Quote from: bitbytebit on April 15, 2011, 12:15:14 am ---
Yeah you can change it to d3d, and it'll work ok now with cleanstretch automatically to avoid the issues there. It just uses ddraw by default since that is technically the best option, unless your using Windows 7 with an ArcadeVGA or other card most likely, and then you need d3d to avoid the other issue there with interlaced resolutions.
--- End quote ---
I actually prefer to run using DDRAW instead of D3D.
Actually, what I meant was that DirectX 7 is old. Windows 7 ships with DirectX 10 (or is it 11). I was curious if there was a 64-bit DirectX 9 that needed to be installed.
Regarding the interlaced resolutions issue, I'm hoping to use the resolution switching workaround mentioned earlier in this thread once I set up Hyperspin (or whatever frontend I end up using).
krick:
--- Quote from: bitbytebit on April 14, 2011, 11:36:05 pm ---
I'll upload a new build, 012k, and hopefully it'll fix the issue.
--- End quote ---
I couldn't sleep. I had to get up and try it out. The verdict....... IT LOOKS FANTASTIC!!!
I think it might even look better than my old setup.
Bravo! :applaud:
Now I just need to turn on "SoundSync" to fix the sound issue and it will be perfect.
I've attached the output log from this new build in case you're interested.
The only real differences are the two switches for keepaspect and hwstretch.
krick:
For some reason, Asteroids is running really, really slow. Roughly half-speed.
I tried it with and without soundsync turned on and the logs are attached.
Also, I've hit a snag with my original plan to used Andy's resolution switching utilities before and after a game launch from the Hyperspin FE. The problem is that hyperspin only allows you to configure something to run before hyperspin itself is launched, not before each game. There's no way I can figure out that allows you to run the front end at 800x600 and switch the desktop to a low res before launching MAME and switch it back to 800x600 afterward.
However it gives me an idea. What if groovymame itself could do the switching? You've got code that figures out the target resolution for the game that it is going to run, just have it store the current desktop resolution, then switch the desktop resolution to the game resolution. When someone exits the game, switch the desktop resolution back to what was stored initially. I've seen code snippets on the Internet on switching the windows desktop resolution and it doesn't look that difficult.
Obviously, this is a VERY specific feature that only applies to people trying to run MAME on a low res arcade monitor with Windows 7 as their operating system (and possibly Vista, I'm not sure). So feel free to shoot it down. However, I imagine that as time goes on, more and more people with MAME cabinets will eventually move to Windows 7.
Calamity:
--- Quote from: krick on April 18, 2011, 12:40:29 am ---For some reason, Asteroids is running really, really slow. Roughly half-speed.
I tried it with and without soundsync turned on and the logs are attached.
--- End quote ---
Interesting, it seems Windows 7 reports interlaced resolutions refresh as half of their actual value, so it's reporting 640x480@30Hz. I wonder if vsync combined with that could be causing this problem, as if just half of the retraces were detected by ddraw... odd.
--- Quote from: krick on April 18, 2011, 12:40:29 am ---Also, I've hit a snag with my original plan to used Andy's resolution switching utilities before and after a game launch from the Hyperspin FE. The problem is that hyperspin only allows you to configure something to run before hyperspin itself is launched, not before each game. There's no way I can figure out that allows you to run the front end at 800x600 and switch the desktop to a low res before launching MAME and switch it back to 800x600 afterward.
However it gives me an idea. What if groovymame itself could do the switching? You've got code that figures out the target resolution for the game that it is going to run, just have it store the current desktop resolution, then switch the desktop resolution to the game resolution. When someone exits the game, switch the desktop resolution back to what was stored initially. I've seen code snippets on the Internet on switching the windows desktop resolution and it doesn't look that difficult.
Obviously, this is a VERY specific feature that only applies to people trying to run MAME on a low res arcade monitor with Windows 7 as their operating system (and possibly Vista, I'm not sure). So feel free to shoot it down. However, I imagine that as time goes on, more and more people with MAME cabinets will eventually move to Windows 7.
--- End quote ---
Yes, that could be possible to implement, although a bit baroque method if you ask me.
By now, I'd just go for AdvanceMenu, that's a simple frontend and will do both things for you: run in a low res mode and allow you to launch arcadeperfect before mame.
But, if you accept my advice, you guys that really want to do serious emulation, keep away of Windows 7. You already have Windows XP-64 for a complete 64-bit OS, why build your CRT cabinet system with such a bloated OS targeted to flat screens? I mean, Windows 7 is the OS you'll expect to find in your wife's laptop today, and possibly in any office computer in the near future, but I see no benefit in using it for arcade systems, rather a lot of new problems.
I remember some of the mame devs saying that ddraw support in Windows 7 is actually faulty. It will indeed perform a sort of frame skipping on its own. If that's true those are very bad news. Yes, directdraw is old. However, the directdraw 7 interface has been supported by any DirectX versions since then, even if not properly documented, as the strategy was to make developers move to Direct3D.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version