Issue with Windows 7 and native resolutions.

[AndyWarne]

I know this should really be in the monitor/video section but its quite an important issue.

There seems to be an issue with Windows 7 switching between resolutions.

Using this setup as an example:
ArcadeVGA card
15Khz standard res monitor
Desktop running at 640 x 480 interlaced.
Mame.ini set correctly to directdraw, switchres, hwstretch off

When any game which uses a non-interlaced res is started (which is pretty much any Mame game), an error resuts "Unable to initialize directdraw".
Note this only happens if the desktop is running at an interlaced res, which is the case when using a standard res monitor (not a multi-frequency monitor).

There is a workaround for this: Run the desktop at a non-interlaced res such as 640 x 288. This might mean using a front end which has a 640 x 288 mode such as Mamewah.
The resolution can be switched using the Quickres icon.

Interestingly this issue does not arise if D3D is selected. But owing to not being able to disable stretching in D3D this results in a poor quality picture.

I am not sure if there is a better fix for this issue. I will look at it some more. I will also post this information on the ArcadeVGA pages on our website.

Andy

[I/O]

Incidentally, most FEs I know of support CGA resolutions. Using Mala, I have mine set at 640x288.

[Gatt]

IIRC Andy,  DirectDraw was depricated in Win7,  and it's jobs shifted to Direct3D.  More specifically,  in DX10.  You could try regressing to DX9 to solve the issue,  alternatively,  you may need to look into DX10 and see if there's a call you can make that would duplicate the original DirectDraw functions.  Sadly,  I'm still a fairly new programmer,  so that's about as much knowledge as my head contains so far.

Looking it up,  looks like D3d has been absorbing DirectDraw since Dx8.  This would explain why D3D is working and DD isn't.  I'd guess the only possibility would be to try regressing to Dx9,  but it doesn't look like that's very easy.

Edit:  Apologies if I'm saying something you already knew,  I realize you've got alot more knowledge then I do with computers,  your products are impressive.

[tyson171]

This is exactly my problem!  Does anyone know a workaround for this issue with hyperspin?  Hyperspin doesn't like 640x288, and my biggest problem is that i can't get systems like Sega Genesis to display at their native resolutions because of this issue! (i was okay with mame using d3d)  Are there any other non interlaced windows resolutions that I can try, and how do i set them up on the latest arcadevga card, if it is even possible?  Hyperspin is becoming more and more popular these days, and it would be a shame if it is uncompatable with windows 7 and 15hz monitors .  Any help would be much appreciated!  Is there a way to force hyperspin into a different resolution other than what the desktop is working off of? I wonder if this would fix the issue?

[AndyWarne]

I have uploaded three resolution switch utilities to www.ultimarc.com/Switchres.zip. If the FE will support it, you can configure it to run the 640x288.exe before every game.

Of course the real fix for this lies in the hands of the Mame devs, enable support for D3D with stretch off.

[tyson171]

Going to see if I can get any of the guys over at the hyperspin forums to implement this into the hyperlaunch script!  Thanks Andy, fingers crossed!

[krick]

Any updates on this?  I'm running a 15KHz arcade monitor. I just purchased a new ArcadeVGA 3000 (a huge upgrade from my original AGP ArcadeVGA from 10 years ago) and  I'm getting ready to rebuild my MAME PC.  I'm trying to decide between Windows 7 64-bit and Windows XP 32-bit.

This whole situation really sucks.  *shakes fist at Microsoft*

Andy, you mention this...

Of course the real fix for this lies in the hands of the Mame devs, enable support for D3D with stretch off.

Is this something that could be implemented in an alternate build like CabMAME or GroovyMAME?

[bitbytebit]

Does d3d support non-stretched modes?  I am looking into how it works opposed to direct draw, seems like it'd not be some unsurmountable feat to do this *if* it supported it.  Oddly the methods they write with in d3d all use the word stretch in them, like it's built in as expected to always be done.  It's definitely sparked my interest, since using d3d would be nice since ddraw is going away eventually and seems less usable  in Windows 7 than it was before.  I wouldn't expect the Mame devs to want to deal with this, but we should be able to in an alternate mame patch/build, if it's possible.

What does running -video d3d with -prescale 0 do?  This at least seems to avoid supported the stretch_supported flag of d3d, if prescale is 0 it skips it and uses a different type of surface to draw.  Although I'm wondering if then there's something else to be done for removing stretching. Ah wait, that's not going to turn off what I'm manually turning off right now, but there does seem to be some reduction is usage of filtering/stretching possible, so I'm testing that and will see.

[krick]

What does running -video d3d with -prescale 0 do?  This at least seems to avoid supported the stretch_supported flag of d3d, if prescale is 0 it skips it and uses a different type of surface to draw.  Although I'm wondering if then there's something else to be done for removing stretching.

prescale only supports 1-8.  I think "-prescale 1" does what you're looking for.

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

So, I recommend starting with these initial options and then tweaking
from there. One additional option you might want to try in
combination with the above is the -prescale option. -prescale takes
an integer parameter from 1 to 8, and specifies a magnification
amount by which the screen pixels are expanded before they are drawn
to the screen. Why is this useful? And how much of a performance
impact does it have? Well, that depends on the mode you are running
in.

If you are running in Category 1 (-video d3d), then -prescale will
use your video card to scale the game graphics up before rendering
them to the screen. Depending on the video card, this is usually a
small performance hit, but not too significant. The benefit is that
each prescale factor reduces the blurriness of the pixels.
-prescale 1 is the default, which does no scaling. -prescale 2 will
double each pixel, -prescale 3 will triple each pixel, etc. For my
money, -prescale 2 is sufficient, but people with super high
resolution displays claim that larger -prescale factors work even
better.

If you are running in Category 2 (-video ddraw -hwstretch), then
-prescale will cause MAME to compose the screen graphics at the
specified scale factor. This is unfortunately done in software, but
carries the benefit that artwork, fonts, and the graphics viewer can
take advantage of the additional resolution to produce nicer results.
The end effect is that you will get less blurry pixels, just like the
Category 1 case, plus higher quality artwork, fonts, and more visible
area in the graphics viewer.

If you are running in Category 3 (-video ddraw -nohwstretch), then
-prescale will cause MAME to pick a video mode that is the prescale
factor times the raw screen resolution, and then MAME will, in
software, compose the screen graphics at the specified scale factor.
This has all the advantages of the Category 2 case, except that since
there wasn't any pixel blurring to begin with, there is no additional
crispness that comes about as a result.

[krick]

bitbytebit, this appears to be what you're looking for...

http://community.arcadeinfo.de/showthread.php?t=9555

CleanStretch

Some may remember the "CleanStretch" option from older MAME versions.

As of today, in Direct3D the Picture gets zoomed to fullscreen with floating point precision. That actually produces quite nasty artifacts in lower resolutions.

CleanStretch ist a quite small hack, changing those floating point zoom back to integer zoom, eliminating zoom artifacts completly.

cleanstretch 0/1 - can be either 0 (Floatingpoint-Zoom) or 1 (Integer-Zoom).

[bitbytebit]

Yeah so far from what I've tried, nothing alters it, always comes out looking crappy compared to ddraw.  Has broken lines and messed up looking digits on pacman for example.  That is any of the current basic settings of that prescale option and the type of rendering being done changed from POINT to NONE for filtering, and also the stretch support option being turned off and using the alternative method instead of using the StretchRect methods.

I've got cleanstretch, rewritten actually so it works with changeres better, in groovymame already.  Ah it does fix it, well then why not just use cleanstretch and d3d with the ArcadeVGA 3000 .  Oddly cleanstretch does some strange things sometimes I guess from reports, with games like gorf, but maybe with d3d it works well and that's the only place it should be used.  Probably using it on ddraw or in SDL, were not so great of places to use it, that makes more sense now.  I just had ported it into the Linux side and changed it to work with changeres and still allow scaling/stretching if desired.

[krick]

So It looks like I have two options for Windows 7 + ArcadeVGA 3000:


1) run MAME in DDRAW mode and have the frontend switch the desktop resolution to 640x288 before launching MAME and switch it back after exiting.

2) run a MAME build with CleanStretch in D3D mode.


I'll have to get everything set up and see which looks the best and/or has the least issues.

[bitbytebit]

So It looks like I have two options for Windows 7 + ArcadeVGA 3000:


1) run MAME in DDRAW mode and have the frontend switch the desktop resolution to 640x288 before launching MAME and switch it back after exiting.

2) run a MAME build with CleanStretch in D3D mode.


I'll have to get everything set up and see which looks the best and/or has the least issues.

I'm uploading a groovymame 012c which turns on cleanstretch now only when d3d is selected as the video type (usually off by default).  Seems like that makes the most sense, otherwise cleanstretch messes with ddraw and SDL stretching, but seems to always do the right thing in d3d.

Also I'm planning on having an option like -avga3000 to groovymame which will have that just basic heightXwidth@refresh list the .ini generators use to create all the little .ini files, but instead have groovymame do it all for you, check if we need throttle in some cases where the refresh rates don't match, do all the other stuff it does with registry modelines currently but instead it'll know that the fixed list of 30 or so resolutions are available to base the calculations of options upon.

[ark_ader]

Isn't that Arcade VGA just a modified ATI 7000 card?

Is the Arcade VGA WDDM 1.1 compliant?

That might explain the resolution issues.

[bitbytebit]

Isn't that Arcade VGA just a modified ATI 7000 card?

Is the Arcade VGA WDDM 1.1 compliant?

That might explain the resolution issues.

No it's a ATI HD2600 (AVGA 3000 that is, earlier ones are from the 9200 series, maybe ones inbetween using that model, seems like one used the HD2400) card that was developed by both Andy and ATI together for the special modelines that it has built in and driver access methods of using those, like with the special AVGA Drivers and Arcade Perfect utility. 

[krick]

Isn't that Arcade VGA just a modified ATI 7000 card?

No it's a ATI HD2600 (AVGA 3000 that is, earlier ones are from the 9200 series, maybe ones inbetween using that model, seems like one used the HD2400)

The original AGP ArcadeVGA was an ATI 7000 (or possibly a 7200, I'm not sure what the difference is)...
http://mame.3feetunder.com/ultimarc/

[bitbytebit]

Isn't that Arcade VGA just a modified ATI 7000 card?

No it's a ATI HD2600 (AVGA 3000 that is, earlier ones are from the 9200 series, maybe ones inbetween using that model, seems like one used the HD2400)

The original AGP ArcadeVGA was an ATI 7000 (or possibly a 7200, I'm not sure what the difference is)...
http://mame.3feetunder.com/ultimarc/

Ah, I see, yeah the AVGA3000 is a big step up from the older ones in how it works, but that probably doesn't matter here about the original issue.  I doubt it's the card, I am betting it's the fact that ddraw was depreciated and by Windows 7 it's been broken for the resolution switching between interlaced and non-interlaced modes.

[krick]

I'm uploading a groovymame 012c which turns on cleanstretch now only when d3d is selected as the video type (usually off by default).  Seems like that makes the most sense, otherwise cleanstretch messes with ddraw and SDL stretching, but seems to always do the right thing in d3d.

That makes sense.  Another option would to have 3 mutually exclusive video choices...

D3D
DDRAW
D3DCLEAN  (or some better name that makes more sense)

Also I'm planning on having an option like -avga3000 to groovymame which will have that just basic heightXwidth@refresh list the .ini generators use to create all the little .ini files, but instead have groovymame do it all for you, check if we need throttle in some cases where the refresh rates don't match, do all the other stuff it does with registry modelines currently but instead it'll know that the fixed list of 30 or so resolutions are available to base the calculations of options upon.

That would be awesome.

In addition to the individual game ini files, as of MAME 0.131u3, you can have vertical.ini and horizont.ini in addition to vector.ini (not sure which version added it).  These might make life easier for global settings.

[bitbytebit]

I'm uploading a groovymame 012c which turns on cleanstretch now only when d3d is selected as the video type (usually off by default).  Seems like that makes the most sense, otherwise cleanstretch messes with ddraw and SDL stretching, but seems to always do the right thing in d3d.

That makes sense.  Another option would to have 3 mutually exclusive video choices...

D3D
DDRAW
D3DCLEAN  (or some better name that makes more sense)

Also I'm planning on having an option like -avga3000 to groovymame which will have that just basic heightXwidth@refresh list the .ini generators use to create all the little .ini files, but instead have groovymame do it all for you, check if we need throttle in some cases where the refresh rates don't match, do all the other stuff it does with registry modelines currently but instead it'll know that the fixed list of 30 or so resolutions are available to base the calculations of options upon.

That would be awesome.

In addition to the individual game ini files, as of MAME 0.131u3, you can have vertical.ini and horizont.ini in addition to vector.ini (not sure which version added it).  These might make life easier for global settings.

Newest GroovyMame should support the ArcadeVGA3000 resolutions without .ini files, built in .ini generator and also should be able to truly see the available modelines to the system instead of just a list (and it's automatic, no need for a new option arg to groovymame).   It's experimental, needs testing with the ArcadeVGA, so any testing you can try would be great help.  Posting output of -verbose -md 4 args actually would be really interesting to see, help make sure it works as good as possible.  Basically now I'm not only reading custom registry modelines but also active system modelines so those should be possible to pick the best one from, similar to the .ini generator tools but now it's built in dynamically and will truly see the real available resolutions. 

[krick]

Newest GroovyMame should support the ArcadeVGA3000 resolutions without .ini files, built in .ini generator and also should be able to truly see the available modelines to the system instead of just a list (and it's automatic, no need for a new option arg to groovymame).   It's experimental, needs testing with the ArcadeVGA, so any testing you can try would be great help.

Awesomesauce!

I'm still setting up my computer so it's connected to my PC monitor but I'll be putting it back in my cabinet and connecting to the arcade monitor the next few days.  I'd definitely test the hell out of GroovyMAME for you.  Stay tuned.

[krick]

I finally got everything hooked up tonight and I had about an hour to play with it.

My system specs...

ASUS P5KPL-CM Motherboard
Intel Core2Duo E5200 Wolfdale running at 3.5 GHz
G.SKILL 4GB (2 x 2GB) DDR2 1066 (PC2 8500) memory
Intel X25-V 40GB SSD (boot drive)
Western Digital "Green" 500GB HD (data drive)
Windows 7 64-bit

Hantarex Polo 25 15KHz arcade monitor


I ran my windows desktop at 640x288 and I ran the latest groovymame with -cc to generate a default ini file.

Using the stock groovymame ini settings, I tried several games with varying results...


Defender - looked and sounded great.  No problems at all.

SmashTV - looked good but sound skipped a bit in places

Pacman - the sound stuttered quite a bit and the image was way too "skinny", plus it looked bad.  Pixels were missing or something.

The following are two pictures of pacman running on my cabinet.  The first is a fairly old picture from back when I was running my original ArcadeVGA AGP (Radeon 7000 based).  I was running stock command line mame with whatever the recommended ini file "tweaks" from Ultimarc were at the time.  The second is a picture from tonight.  I apologize about the quality, but think you can see the differences.

The first image is admittedly a little "squashed" vertically, but with the arcade vga, I always run with the vertical height a little squished so that vertical games don't draw off the screen at the top and bottom. (see my quote from Andy @ Ultimarc at the end of this post)

Ignore the colors on the second image.  I was rotating my cab while it was on, which always makes the colors get groovy for a while.

The main problems in the second image are the overly skinny image and whole strips of pixels from the vertical parts of the maze are actually missing.  The text on the intro screen looks pretty bad too.

Let me know if you want any specific diagnostic output from the command line.  Also, let me know if you want me to run specific games to test anything.







http://www.ultimarc.com/monfaq.html

Vertical games on a horizontal monitor.

Providing the monitor is capable of displaying the resolution (rotated) then we still have a good picture. Although the scan lines are in the wrong direction, there is still a 1 to 1 correlation with the game pixels. So we can get away with this cheat usually. If you set the resolution to be exactly that of the game, with the V and H swapped, then the game will fill the screen. Now this is not exactly what you want because it will look very strange. (great on a horizontal game though). You need to deliberately introduce side borders. Easy to do: you just run at a higher horizontal resolution. Galaga runs fine at 352x288 for example. If you calculate the aspect ratio of the original game, this is pretty much the rotated equivalent of it. Bear in mind, though, that arcade monitors are designed to display approx 240 visible lines and we are asking it to display 288 lines in this mode. This means that something has to go, and what goes are the top/bottom borders, which are normally off the screen. So the picture will be taller than a 240 line picture.

[bitbytebit]

run groovymame like this and post the output.log ...

groovymame -verbose -md 4 pacman > output.log

That might help see exactly what is going on, I suspect it's using keepaspect there from the width not being the correct for the aspect.  That often will cause the issues your seeing if the resolution is off far enough.  The first pacman picture is quite wider than normal, but most pacman resolutions are actually now days and the original is quite more skinnier than people realize.  Will be able to tell more though with the output log, thanks.

[krick]

I've attached a zip file containing 4 files...

First is the output log from groovymame 142, along with the default ini file generated from groovymame -cc

groovy_output.log
groovymame.ini

Second is the output log from standard command line mame 142 along with a default mame ini file modified as instructed by Andy at Ultimarc.

ultimarc_settings_output.log
mame.ini


The reason that I ran the standard mame build was to see if I could recreate the results from my old cabinet setup.   Pacman looked really good pixel-wise, but sadly, there were two glaring problems...  first, the image took up nearly the full width of the monitor.  Second, the bottom two inches or so were completely cut off.  Even more concerning, the cut off image wasn't just off the monitor, it wasn't being displayed at all.  No amount of monitor adjusting could get it to display because it was just gone.  In my old setup, at first the image was off the top AND bottom of the screen equally.  By adjusting the vertical height on my monitor to compress the image a little, I could see it all.  It doesn't seem to work that way anymore.

I may need to dig up an old build (mame 106?) and try the same experiment to see what I get.  I'm not sure if MAME has changed, or the ArcadeVGA is different.  Is it possible that the old ArcadeVGA supported a resolution that the new one does not?

I wish I knew where my old mame setup was.  I'd like to look at the mame.ini and pacman.ini to see what settings I was using.

[bitbytebit]

I've attached a zip file containing 4 files...

First is the output log from groovymame 142, along with the default ini file generated from groovymame -cc

groovy_output.log
groovymame.ini

Second is the output log from standard command line mame 142 along with a default mame ini file modified as instructed by Andy at Ultimarc.

ultimarc_settings_output.log
mame.ini


The reason that I ran the standard mame build was to see if I could recreate the results from my old cabinet setup.   Pacman looked really good pixel-wise, but sadly, there were two glaring problems...  first, the image took up nearly the full width of the monitor.  Second, the bottom two inches or so were completely cut off.  Even more concerning, the cut off image wasn't just off the monitor, it wasn't being displayed at all.  No amount of monitor adjusting could get it to display because it was just gone.  In my old setup, at first the image was off the top AND bottom of the screen equally.  By adjusting the vertical height on my monitor to compress the image a little, I could see it all.  It doesn't seem to work that way anymore.

I may need to dig up an old build (mame 106?) and try the same experiment to see what I get.  I'm not sure if MAME has changed, or the ArcadeVGA is different.  Is it possible that the old ArcadeVGA supported a resolution that the new one does not?

I wish I knew where my old mame setup was.  I'd like to look at the mame.ini and pacman.ini to see what settings I was using.

I'll upload a new build, 012k, and hopefully it'll fix the issue.  I think I need to only set keep aspect when the resolution width turns out wider than the original, not also when it's smaller.  This hopefully will make things so that everything is just good and works, better than what your seeing currently.  Technically the resolution is not *perfect* being 384x288, since pacman really should have 400x288, but then again this is just a fact of life for the ArcadeVGA and won't be so bad actually I'm guessing since it's just 16 pixels wider than it should be.

[krick]

I'll upload a new build, 012k, and hopefully it'll fix the issue.

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.

[bitbytebit]

I'll upload a new build, 012k, and hopefully it'll fix the issue.

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.

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]

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.

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]

I'll upload a new build, 012k, and hopefully it'll fix the issue. 

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!   

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]

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.

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.

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.

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.

[bitbytebit]

Also the newest groovymame does things now slightly different.  Basically the default is to just run with vsync, you would try that first (basically a fresh mame.ini) and might want to set soundsync to 1 also since it'll be used only if necessary.  Then if that doesn't work for a game like asteroids, you might want to make a .ini file for it with triplebuffer 1 in it.  See if that helps, any game running slow might need that set, it signals groovymame to act more like my previous version did in a sense but also turns off vsync too and throttle on (which may just be necessary for games that don't match the vertical refresh rate of the ArcadeVGA modelines).  Then of course if you alter the resolution with the ArcadePerfect utility and get the refresh correct you probably can then remove the need for triplebuffer in that game. 

Calamity has an idea of how to do this a bit better in the future where triplebuffer could be avoided if desired or used, and signal this type of change with the syncrefresh option.  So Things might change to use that method, but I'm curious how the current method works for you and others to see where to go from here.  Basically the changes I have made recently allow it now to run in vsync mode by default even if the refresh isn't perfect, since with soundsync it may be slightly slower but tear free and best scrolling.  Then from there can choose triplebuffer if you want better refresh but possibly some issues that happen with triplebuffer, it's always going to be a compromise without a modeline that perfectly matches the refresh rate.

[krick]

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've considered XP64, but there's two issues that I can think of off the top of my head...

1) A copy of XP64 costs about $250.  I got a 3-computer license for Win7 for $130.

2) I don't know if XP64 will work with SATA devices, especially an SSD boot drive.

I really didn't want to go with Windows 7, but it seemed like the easiest/cheapest path to 64-bit.  All the computers in my house are still running XP32, if that gives you any indication of my feelings for recent Microsoft OS offerings.

Persuade me to switch.   

[Calamity]

I've considered XP64, but there's two issues that I can think of off the top of my head...

1) A copy of XP64 costs about $250.  I got a 3-computer license for Win7 for $130.

2) I don't know if XP64 will work with SATA devices, especially an SSD boot drive.

I really didn't want to go with Windows 7, but it seemed like the easiest/cheapest path to 64-bit.  All the computers in my house are still running XP32, if that gives you any indication of my feelings for recent Microsoft OS offerings.

Persuade me to switch.  

Yeah I see your point. And Windows 7 is becoming ubiquitous these days, probably hardware compatibility will be the final reason for everybody to move. It's only that, imho, it's going to take years until we achieve in Windows 7 the same level perfection we've got now in XP, if it's even possible, as most of the low-res/crt/15Khz state of art is based on hacks and similar stuff over the existing things, that needed A LOT of work and research, which you can benefit from at zero cost.

And of course I'm not trying to persuade anybody, just wanted to bias people decisions a little bit As you may have a good reason for using Windows 7, but I feel that many people in the arcade scene are moving uncritically to this system without actually knowing of its flaws when it comes to advanced emulation on crt devices. In fact I'm getting tired of the Windows thing altogether, it's a never-ending battle trying to bypass the hardcoded behaviour of the system that gets in the middle of your hardware actual capabilities. Thanks God we have Linux, it's free and we have the source code  

[krick]

Well, I managed to track down a copy of XP X64 sp2.  It took me a little while to get it set up properly, and when I installed it and went to Windows updates, there were 99 (!!!!) critical updates.  LOL

Then I had two ArcadeVGA issues....

1) The fan has stopped spinning.  I fired off an email to Andy and he's sending me a new fan.  You gotta love the service!  That's why I'm a repeat customer.  In the meantime, I have an 80mm fan on an adjustable bracket directly over the ArcadeVGA, blowing downward to keep it cool.

2) I absolutely could not get the drivers from the CD to install no matter what I tried.  Eventually, I became convinced that my Ultimarc installation CD didn't have XP x64 drivers on it at all.  I just assumed that the drivers for vista/win7 were used on XP64, but it turns out that's not the case.  I googled for drivers and found this page...  http://www.ultimarc.com/avgadrivers.html
After downloading the XP x64 driver zip file, I was unable to unzip it with Windows built-in zip support, WinRAR, or 7zip.  Every time I tried, I kept getting a single file with no extension.  On a whim, I renamed the single file and added a .zip extension and tried to unzip THAT file.  Finally, success.  The original downloaded zip file must be some sort of non-standard double-zip solid archive format.  Possibly from a newer version of Winzip or something.  Man, I hate Winzip.  Anyway, once I had the actual XP x64 drivers, the install was flawless.

The first thing I tried was groovymame running Asteroids, and it ran fine.  So, that definitely implicates either Windows 7 itself, or the ArcadeVGA drivers on Windows 7 as the culprit on that 30Hz refresh rate issue.

Doing a diff between the two output logs, I noticed that the Windows 7 driver seems to have a resolution that the Windows XP x64 does not.  512x512.  I had gotten used to using that resolution sometimes when configuring windows because of the "tall" resolution.  You have less dialog boxes getting chopped off at the bottom of the screen.  I also noticed that XP x64 has a 1024x768 virtual desktop mode that pans around.  It's still interlaced though, so it's hard to read on my monitor.  I guess it might be useful sometimes.  The highest resolution available on Windows 7 is 800x600.  I think that XP x64 might also have a 320x200 resolution that Win 7 doesn't but I can't remember for sure.

[bitbytebit]

That makes sense, I think in Windows 7 they've somehow broken interlaced modelines, and these are probably some of the results of whatever Microsoft broke.

[AndyWarne]

That makes sense, I think in Windows 7 they've somehow broken interlaced modelines, and these are probably some of the results of whatever Microsoft broke.

There are no problems with interlaced modelines themselves in Windows 7. The problem is that Direct3D is unable to create a window when the required resolution involves a switch from interlaced to non-interlaced or vice-versa.

[krick]

There's definitely something weird happening with interlaced resolutions though.

When I ran Asteroids at 640x480 interlaced, it created the window fine, it was just running at 50% speed.

[bitbytebit]

That makes sense, I think in Windows 7 they've somehow broken interlaced modelines, and these are probably some of the results of whatever Microsoft broke.

There are no problems with interlaced modelines themselves in Windows 7. The problem is that Direct3D is unable to create a window when the required resolution involves a switch from interlaced to non-interlaced or vice-versa.

It sounds like the refresh rate for them might be off or something, from what krick is saying, how for some reason the games are running at 30hz on an interlaced 60hz resolution.  Not sure where that is coming from, but maybe windows 7 is reporting to mame the desktop is 30hz or something weird like that.

[Calamity]

It sounds like the refresh rate for them might be off or something, from what krick is saying, how for some reason the games are running at 30hz on an interlaced 60hz resolution.  Not sure where that is coming from, but maybe windows 7 is reporting to mame the desktop is 30hz or something weird like that.

I had heard that before, W7 users had their interlaced modes reported at half their vertical refresh. Although that's true in a sense, as with interlaced modes a complete frame is rendered in two passes, there are actually two sync pulses triggered and just one of them reported it seems.

[krick]

It sounds like the refresh rate for them might be off or something, from what krick is saying, how for some reason the games are running at 30hz on an interlaced 60hz resolution.  Not sure where that is coming from, but maybe windows 7 is reporting to mame the desktop is 30hz or something weird like that.

Is there any way we can test this?  Maybe a small DirectX app that just runs and displays the refresh rate that windows is reporting.  It would probably be useful if it could run in both DDraw and D3D so we could see if there was any difference.

The one variable here, however, is the ArcadeVGA 3000 drivers themselves.  Since the XP x64 and Windows 7 drivers are different, there's no way to be sure if the refresh rate reporting difference is due to Windows (and DirectX) or somehow related the video drivers.