first time trying to use magic resolutions

[krick]

I'm trying to use magic resolutions for the first time, but I'm not sure that I'm doing it right.

I'm using an ATI 4000 series card with Windows XP x64 and the 9.3 CRT_EmuDrivers.

I'm using the latest vmmaker.

I made the following changes to the vmmaker.ini file...

ListFromXML = 0
GenerateXML = 0
MonitorType = "H9110"

I have a Hantarex Polo 25 (not polostar) and I think I remember that we determined that it should be the same settings as the H9110...  http://forum.arcadecontrols.com/index.php?topic=110905.msg1205207#msg1205207
It's a 15KHz/25KHz switchable monitor, but I'm using 15KHz only.  If I'm wrong, please let me know.

I created a clean new mame.ini file and changed the monitor setting to "H9110" to match the vmmaker ini.

Then I ran vmmaker.  If there's anything else I need to do, let me know.

The resolutions that are being chosen don't seem to be correct.  For example, pacman looks like it's being anti-aliased poorly or something.  Normally, with my ArcadeVGA, I run it at the native resolution and adjust my monitor settings so that I don't have any overscan at the top and bottom.

Smashtv is picking a resolution that my monitor really doesn't like, so I can't get a picture.  Again, this normally works ok with my ArcadeVGA 3000.

I've attached log files for both games.

[Calamity]

Hi krick,

The new version of VMMaker (1.3c) has native support for magic resolutions. This means that you only need to change this value:

ModeTableMethod_XML = 2

... and leave the MAME related options as usual, so the XML is actually processed:

ListFromXML = 1
GenerateXML = 1

That will create the required "magic" resolutions according with your monitor specs, in the form of 1234 x yres.

There is a separated ModeTableMethod_Custom variable that you usually should leave as 0 so the modes in ReslList.txt are treated literally.

[krick]

That seems to have done the trick.  Thanks.

I've only noticed a few odd things.

1) When I ran vmmaker, it created 42 resolutions, if my memory is correct.  I notice when running ArcadeOSD, there's still a bunch of really low resolutions in the list, then a greyed out block of resolutions, followed by the 1234 x whatever "magic" resolutions.  Is this what I should be seeing?

On a related note, are there any "problem" games that you know of that I can run to really be sure that this is working as intended?

2) When I exit a game that was launched from hyperspin, pacman for example, hyperspin is smooshed up on the left side of the screen. I think that Hyperspin is trying to re-size itself to the MAME resolution or something. I recall having similar issues when I was trying to use Windows 7 (before I gave up on that), but I don't think XP ever did this.  I think there's an option to always run Hyperspin at a fixed resolution though.  I may have to try that and see if it makes any difference.

3) I can no longer use DDRAW.  It only works with D3D.  I saw you mention that some people have this issue in one of your posts.  Are there any drawbacks to using D3D these days?

Do you have any idea why it's happening and/or why it only happens to some people?
Is it tied to specific versions of windows?
64 vs 32 bit?
Certain versions of your CRT_EmuDriver?
Possibly linked to the type of video card?

I'm using an ATI Radeon HD 4550, Windows XP x64, and the CRT_EmuDriver based on Catalyst 9.3.

I also have an ATI Radeon X600XT that I could try to see if it behaves differently.  Though I'll have to scrub the old drivers off the machine first so I can install the 6.5 drivers.

This may or may not be related, but when I installed the CRT_EmuDriver, and right at the end of the installation, I'm getting that error about copying a file again...  http://forum.arcadecontrols.com/index.php?topic=110905.msg1185604#msg1185604

[Calamity]

1) When I ran vmmaker, it created 42 resolutions, if my memory is correct.  I notice when running ArcadeOSD, there's still a bunch of really low resolutions in the list, then a greyed out block of resolutions, followed by the 1234 x whatever "magic" resolutions.  Is this what I should be seeing?

This is correct. All MAME resolutions pass through the *_XML set of options, which we defined as "magic". But on the other hand the resolutions defined in ReslList.txt pass through the *_Custom set of options, and as we defined ModeTableMethod_Custom = 0 they are preserved as defined.

So we can use these resolutions for the rest of emulators that don't support "magic" resolutions.

In my cab, as I'm only using GroovyUME now, I just have the desktop resolution and a bunch of "magic" resolutions for everything.

On a related note, are there any "problem" games that you know of that I can run to really be sure that this is working as intended?

I remind Spy Hunter crashing with magic resolutions, due to its odd 480x480 size, I haven't figured this one out. Apart from that, what I do is to go testing games by height, that's the relevant value, pay special attention to vertical games:

256 - 1942
280 - contra
288 - dspirit

...make sure you see no stretching at all. Then I go for some interlaced ones: donpachi, twincobr, aerofgts (this one is useful because it allows testing resolution switching).

2) When I exit a game that was launched from hyperspin, pacman for example, hyperspin is smooshed up on the left side of the screen. I think that Hyperspin is trying to re-size itself to the MAME resolution or something. I recall having similar issues when I was trying to use Windows 7 (before I gave up on that), but I don't think XP ever did this.  I think there's an option to always run Hyperspin at a fixed resolution though.  I may have to try that and see if it makes any difference.

This is odd because in a normal situation HS should not be aware of what resolution we're using inside MAME. I wonder if HS is shutting GroovyMAME by its own means which could be catastrophic as it would prevent GroovyMAME from restoring the registry settings it has previously modified. I mean that if HS would let GroovyMAME terminate normally the resolution should always be the same: the desktop resolution.

3) I can no longer use DDRAW.  It only works with D3D.  I saw you mention that some people have this issue in one of your posts.  Are there any drawbacks to using D3D these days?

Direct3D is actually faster than DirectDraw and thus it's recommended for "magic" resolutions because the actual frame buffer is 1234 wide. D3D has only 2 drawbacks AFAIK:

- It stretches the frame if the resolution is not *exactly* the one of the frame. This is not a problem thanks to CabMAME's -cleanstretch patch (included in GroovyMAME).
- Some resolutions might become disabled if Windows determines they're not supported by the monitor. This is only a problem for monitors with a valid EDID, not the case of arcade monitors.

Do you have any idea why it's happening and/or why it only happens to some people?
Is it tied to specific versions of windows?
64 vs 32 bit?
Certain versions of your CRT_EmuDriver?
Possibly linked to the type of video card?

I wish I knew. I spent a whole week last summer doing tests and patches for MAME until I got it working here for Cat 6.5/9.3 - Windows 32/64 - ddraw/d3d. My initial tests where done using 9.3/32, and it was beautiful because I could use a single "magic" resolution for everything. But then when testing it in 6.5/32 I got constant blue screens until I found that the vertical resolution couldn't be modified. That's why I ended up using a list of resolutions by height for all systems. It's interesting that in 6.5/64 there weren't blue screens but just garbled displays. When I got everything working for each possible combination of 6.5/9.3, 32/64, ddraw/d3d I was so exited that I made a pompous release just hours before going out for holiday on a cruise. I bought an internet card on board to follow the "success" of the creature with a cup of porto just to discover that it wasn't working for anybody... Fortunately before trashing it completely we found that it does work for Direct3D even when it doesn't for DirecDraw.

So I don't have a clue why it works here with DirectDraw while it doesn't work for other people. I'm inclined to think that it has to do with the DirectX version, because the driver files are exactly the same. Only an intensive testing campaign would help to find an answer.

However we must keep in mind that after all this is a hack, we're just using a hole in ATI drivers, so it's a miracle that it even works.

I'm using an ATI Radeon HD 4550, Windows XP x64, and the CRT_EmuDriver based on Catalyst 9.3.

I also have an ATI Radeon X600XT that I could try to see if it behaves differently.  Though I'll have to scrub the old drivers off the machine first so I can install the 6.5 drivers.

The X600XT should also be supported by the 9.3 version. Any test is welcome, if you ever have the time or energy.

This may or may not be related, but when I installed the CRT_EmuDriver, and right at the end of the installation, I'm getting that error about copying a file again...  http://forum.arcadecontrols.com/index.php?topic=110905.msg1185604#msg1185604

I don't think this is related but it does worry me. Driver's installation is incredibly problematic.

[krick]

In my cab, as I'm only using GroovyUME now, I just have the desktop resolution and a bunch of "magic" resolutions for everything.

That's cool.  I'll have to check out GroovyUME at some point.

On a related note, are there any "problem" games that you know of that I can run to really be sure that this is working as intended?

I remind Spy Hunter crashing with magic resolutions, due to its odd 480x480 size, I haven't figured this one out. Apart from that, what I do is to go testing games by height, that's the relevant value, pay special attention to vertical games:

256 - 1942
280 - contra
288 - dspirit

...make sure you see no stretching at all. Then I go for some interlaced ones: donpachi, twincobr, aerofgts (this one is useful because it allows testing resolution switching).

Actually Spy Hunter was one of the games I tested and it appeared to work fine.  Does it crash immediately for you?  I can get you an output log tonight if it will help you troubleshoot the issue.

I tried Gauntlet Legends, which I recall being one of the problem resolution switching games.  It worked ok for me other than a flash of desktop when it switched resolutions.  I'll have to try some of the others.  Thanks for the suggestions.

2) When I exit a game that was launched from hyperspin, pacman for example, hyperspin is smooshed up on the left side of the screen. I think that Hyperspin is trying to re-size itself to the MAME resolution or something.

This is odd because in a normal situation HS should not be aware of what resolution we're using inside MAME. I wonder if HS is shutting GroovyMAME by its own means which could be catastrophic as it would prevent GroovyMAME from restoring the registry settings it has previously modified. I mean that if HS would let GroovyMAME terminate normally the resolution should always be the same: the desktop resolution.

Hyperspin must be forcibly exiting MAME.  I noticed that games that have to initialize nvram on first boot aren't saving the settings when launched from Hyperspin.

UPDATE:  I found this thread which seems to be related.  I'll investigate more tonight...  http://forum.arcadecontrols.com/index.php?topic=117935.0

Do you have any idea why it's happening and/or why it only happens to some people?

So I don't have a clue why it works here with DirectDraw while it doesn't work for other people. I'm inclined to think that it has to do with the DirectX version, because the driver files are exactly the same. Only an intensive testing campaign would help to find an answer.

However we must keep in mind that after all this is a hack, we're just using a hole in ATI drivers, so it's a miracle that it even works.

If it's DirectX, maybe you could run Dxdiag and save your information to a file.  Then I could diff it against mine to see if any file versions are different.

This may or may not be related, but when I installed the CRT_EmuDriver, and right at the end of the installation, I'm getting that error about copying a file again...  http://forum.arcadecontrols.com/index.php?topic=110905.msg1185604#msg1185604

I don't think this is related but it does worry me. Driver's installation is incredibly problematic.

Is there any kind of installation log from the ATI drivers that will tell us what file it's failing on?   Are your drivers supposed to install the little Galaga icon resolution picker thing to the system tray?   Because that doesn't get installed.

[Calamity]

I'll collect the DirectX information from my working systems to see if we can find something interesting.

As for the Quickres app, it's not even included with version 9.3, I just left it there for version 6.5 but probably should remove it too. There's no log created by the ATI drivers installation AFAIK.

[Calamity]

I've attached my dxdiag information log. There's also a log of GM running 1942 with magic resolutions on ddraw, working perfectly here.

[krick]

Here's my DxDiag output for both 32-bit and 64-bit.  I'm running Windows XP x64, so my DxDiag allows you to launch the 64-bit version from a button on the main screen.

It looks like some of my 32-bit directX stuff is a different version.  Additionally, it appears that you have a mixture of Spanish and English DirectX components.  I didn't know there was such a thing.

Have you ever gotten ddraw to work with magic resolutions on a machine with XP x64?

[Calamity]

Here's the output from my 64-bit machine. DDraw + magic resolutions working here.

Yeah the first log I posted is from a Dell pc, maybe the mixture of languages happened as succesive service packs got installed.

So what happens exactly with DDraw, do you get a garbled display or no picture at all?

[krick]

Here's the output from my 64-bit machine. DDraw + magic resolutions working here.

Our logs look remarkably similar in the DirectX area, so I don't think that's the issue.

However, I notice that you're using an older ATI card, which means you're using the 6.5 drivers.
Your other log showed an older ATI card as well.

I'm using an ATI Radeon HD 4550, and the CRT_EmuDriver based on Catalyst 9.3.

So maybe it's driver specific.  I'm crunching some zip files on my arcade cabinet at the moment, which will take a while, but when that finishes, I'll have to see if either my X600XT or my even older 9250 (PCI) with the 6.5 drivers works.

So what happens exactly with DDraw, do you get a garbled display or no picture at all?

It just goes black.  I've attached log files from running "tetris" in both d3d and ddraw.  Maybe you'll find something helpful.

I don't think that this is important, but I figured I'd mention it just in case.  I noticed that my desktop resolution is stuck on 16-bit color, at least according to the display properties dialog.  Is that normal?

[Calamity]

Both ddraw/d3d logs look perfect.

I don't think that this is important, but I figured I'd mention it just in case.  I noticed that my desktop resolution is stuck on 16-bit color, at least according to the display properties dialog.  Is that normal?

No, that's definitely not normal. Make sure you uncheck the box "Hide modes that this monitor cannot display" in Screen Properties/Advanced/Monitor. It's interesting because the 32-bit modes are indeed available and are being used by GroovyMAME.

I'm 99% sure that I tested this with Cat 9.3-64-bit and my HD 4350 before releasing it last summer, but my memory might fail.

[krick]

I just uninstalled the 9.3 CRT_EmuDrivers, and uninstalled my Radeon HD 4550 from device manager.
I then shut down and swapped in my ATI Radeon X600XT and installed the 6.5 CRT_EmuDrivers.
I ran vmmaker with the same settings as before.

This time there were some differences...

1) DDraw now works.  I tested a few games and they all appear to still work.

2) Interlaced 640x480 on the windows desktop looks far better.  Easier on the eyes, overall less jittery, text is more readable.

3) According to display properties settings, my desktop is running with 32-bit color instead of 16-bit, though on my old setup, switching resolutions with the QuickRes utility might have caused that as I think all the listed resolutions were 16-bit.

4) When installing the CRT_EmuDriver this time, I got two errors at the end of the install.  The first was that same "Copy File" error that I get with the other drivers.  The second one was something about thunk.exe having a missing inf file.


I've attached the log files from running the same game "tetris" with ddraw.  The 6.5 log is my X600XT, the 9.3 log is my HD 4550.
There are differences.  Do a diff with a visual tool like BeyondCompare and you'll see them.  Ignore the differences with the sound card stuff.  I was having an issue with my sound card because the HD 4550 has some kind of onboard audio thing for the HDMI port and I didn't have the driver installed.  I later installed it and ddraw still didn't work right with that card so that wasn't the issue.


Just so you know, this is a clean install of XP x64 from the CD less than a week ago.  All that I installed were drivers for my sound card and on-board LAN, along with all the pending critical windows updates, .NET 3.5, and the latest DirectX Redistributable (June 2010)...  http://www.microsoft.com/en-us/download/details.aspx?id=8109

Also, you might find this interesting.

This is the card I have...  http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=1599939&CatId=1559
It's a Radeon X600XT and it's actually made by ASUS.



Anyway, it has two outputs, one DVI, the other VGA.  In my experience, the port at the "bottom" of the card, the one closest to the card edge is usually the primary port.  However when I tried to attach my DVI-to-VGA adapter so I could connect my monitor, I discovered that the DVI port is a DVI-D only port.  There are no holes for the analog pins in the adapter so you can't physically plug it in.   So I ended up connecting my monitor to the VGA port, which I assumed was secondary.  However it worked perfectly with CRT_EmuDriver and GroovyMAME, so it must actually be the primary port.

[Calamity]

Hi Krick, thanks a lot for your detailed post.

Nice tool this BeyondCompare, I didn't know it. Well, your 32/64-bit logs are identical for the relevant bits. Something interesting is that some of your magic resolutions in the 32-bit log were already modified with previous modeline data, that's the proof that HS was just killing the process before it could restore the registry data. But that doesn't explain ddraw not working. Actually both logs show that the ddraw surfaces are succesfully created.

The ultimate test would be installing the 9.3 CRT_Emudriver now with the X600XT, as this one should be supported by both. If ddraw works, it would mean the problem is video card related. If ddraw doesn't work, then we should conclude it's driver dependent.

Now I'm thinking that possibly it was the X300 the card that I used when testing this last summer, not the HD 4350, because it allowed me testing with both versions of the driver without removing the card (accessing the mother board is a nightmare with my current cab). As it just worked I assumed that any supported card should work just the same.

As for the driver installation problem, I found this post: http://www.hardwareheaven.com/windows-xp-radeon-display-drivers/69335-common-problems-fixes.html
Find quote #19, there's a fix for this issue. However I don't believe it's a critical issue, at least for the use of the drivers that we do.

About the interlace quality, that' also interesting. You know that we can't actually control the interlace timing by means of modelines. This is a limitation indeed. We just specify that this specific modeline must be interlaced. Then the videocard is responsible for providing the relative shift of exactly 0.5 lines for each of the fields. I guess that some chipsets do better than others.

The VGA being the primary port in your X600XT was probably the standard at the time. All my X300 are the same on this regard, though their VGA ports are indeed at the bottom of the card, according to your theory, and they a have a proper DVI-I port.

[krick]

Nice tool this BeyondCompare, I didn't know it.

I've used BeyondCompare almost every day since I purchased it almost 10 years ago.

It can compare binary files, text files, word documents, PDF files, images, excel files, and tons of other types.  Plus, for certain types, like source code or XML it can apply beautification before comparing.  There's additional free file filters available on their site for download.

It can compare zip files directly without unzipping them first too.  You can even compare a folder to a zip file.

I love being able to select two files in explorer and then right-click on one of them and hit "compare".

It's totally worth every penny.

Well, your 32/64-bit logs are identical for the relevant bits. Something interesting is that some of your magic resolutions in the 32-bit log were already modified with previous modeline data, that's the proof that HS was just killing the process before it could restore the registry data.  But that doesn't explain ddraw not working. Actually both logs show that the ddraw surfaces are succesfully created.

I made a change to my HyperSpin config so that it doesn't use "HyperLaunch" and now it exits properly.

The ultimate test would be installing the 9.3 CRT_Emudriver now with the X600XT, as this one should be supported by both. If ddraw works, it would mean the problem is video card related. If ddraw doesn't work, then we should conclude it's driver dependent.

Now I'm thinking that possibly it was the X300 the card that I used when testing this last summer, not the HD 4350, because it allowed me testing with both versions of the driver without removing the card (accessing the mother board is a nightmare with my current cab). As it just worked I assumed that any supported card should work just the same.

I installed the 9.3 driver and ddraw works perfectly.  So the problem must be my HD 4550 card.

As for the driver installation problem, I found this post: http://www.hardwareheaven.com/windows-xp-radeon-display-drivers/69335-common-problems-fixes.html
Find quote #19, there's a fix for this issue. However I don't believe it's a critical issue, at least for the use of the drivers that we do.

I had a slightly different error this time.  I had the "copy file" error as usual.  But then the "thunk.exe" error said something different...  "'Setup did not find a driver compatible with your current hardware or operating system. Setup will now exit."  Of course, this is totally bogus as the driver installed fine.  However, when I shut down, re-connected my arcade monitor, and restarted, windows was running 640x480, but NOT interlaced.  I had to run VMMaker and restart before it would come up interlaced.

Based on that link you posted above, I think that thunk.exe stuff is related to setting the best resolution for the next restart. (smart gart?).  With the 9.3 drivers, it failed for some reason.

Based on other stuff I've found, I suspect that the other "copy file" error might be related to the missing ATI Catalyst Control Center (CCC).

As a side note, how are you supposed to change your desktop resolution when you're using magic resolutions?  Or is the only supported resolution 640x480 interlaced?

About the interlace quality, that' also interesting. You know that we can't actually control the interlace timing by means of modelines. This is a limitation indeed. We just specify that this specific modeline must be interlaced. Then the videocard is responsible for providing the relative shift of exactly 0.5 lines for each of the fields. I guess that some chipsets do better than others.

The interlace looks the same on my X600XT with both 6.5 and 9.3 drivers, so the problem must be in my other card.

However as a sidebar, do you remember the issues I was having with my ArcadeVGA 3000 card and interlaced resolutions a while back that turned out to be driver related?...

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

The problem was totally in the ArcadeVGA driver.  It didn't have anything to do with the refresh rate at all.  It had something to do with the screen geometry.  When I use the ArcadePerfect utility from the Ultimarc site, simply bumping up the vertical height +1 will completely fix 640x480 or 800x600 so they no longer look terrible.  However to make the change permanent, Andy had to change the geometry in the driver itself.

The giveaway was that 720x480 looked great.  When I compared it against 640x480 using ArcadePerfect, I noticed that the vertical height parameter was one less on 640x480, even though they should be the same.

The VGA being the primary port in your X600XT was probably the standard at the time. All my X300 are the same on this regard, though their VGA ports are indeed at the bottom of the card, according to your theory, and they a have a proper DVI-I port.

Yeah, I've never seen a video card with a DVI-D port.  I was surprised.  I'm not sure who ASUS made this card for, or why, but TigerDirect was selling it in a plain brown box, so it's some sort of OEM card.

[Calamity]

I've used BeyondCompare almost every day since I purchased it almost 10 years ago.

I've just tested the trial version and it really looks that it could make my life much easier.

I installed the 9.3 driver and ddraw works perfectly.  So the problem must be my HD 4550 card.

Oh, thanks a LOT for getting to the bottom of the subject Krick. Now it makes sense, I'm almost sure that I used the X300 for testing. So for newer cards (HD 4xxx and probably others), d3d must be used with magic resolutions. Older cards can use either ddraw or d3d for this.

I don't have an idea of what possible reason can be behind of this. It could be that the drivers code follows a different path for the newer chipsets.

However, when I shut down, re-connected my arcade monitor, and restarted, windows was running 640x480, but NOT interlaced.  I had to run VMMaker and restart before it would come up interlaced.

I believe what happened is that the registry modelines didn't get properly installed because of the faulty installation process. Otherwise the 640x480 31 KHz would have been overriden by its 15 kHz counterpart. Anyway VMMaker rebuilt the mode table so that's fine.

As a side note, how are you supposed to change your desktop resolution when you're using magic resolutions?  Or is the only supported resolution 640x480 interlaced?

Any resolution you want to use for the desktop should be defined in ReslList.txt so it's processed by the ModeTableMethod_Custom variable and its values are preserved.

However as a sidebar, do you remember the issues I was having with my ArcadeVGA 3000 card and interlaced resolutions a while back that turned out to be driver related?...

Sure I remember. Interlaced modelines need to be defined with an odd number of lines. My experience with older ATI cards is that if you define intelaced modelines with an even number of lines, the result is interlaced but the vfreq obtained is slightly different from expected, so it seems that the number of lines is internally truncated to an odd number anyway. But some newer versions of the hardware or drivers might require an explicit odd number for interlace to work properly.

[hexray]

I can't seem to get the magic resolutions to work.  I deleted the all of the VMMaker gerated files (mame.xml/DropList.txt/MameList.txt/ModeInfo.txt/Modeline.txt/ModeList.txt/RegMdlns.txt) and use the following settings in VMMaker.ini:

MonitorType="D9200"
ModeTableMethod_Custom = 2
ListFromXML = 1
GereateXML = 1

All other settings I've left as the default.  I ran VMMaker, rebooted and tried to launch HyperSpin and it still seem to be crashing.  When I run ArcadeOSD it looks like there are about 120 resolutions in the list.  Any ideas what else might be going on ?

-hexray

Edit: I found the another thread and used these options:

ModeTableMethod_Custom = 1
ModeTableMethod_XML = 2

This left me with 69 resolutions and HyperSpin runs but now the problem is that it seems to be running on the left side of screen.  For example the left half of the hyperspin screen I can't see and the right half is only covering half of the desktop.  Is there some HyperSpin setting I need to change ?

Edit #2: Ok.. if I run HyperHQ and run it in full screen mode that seems to fix it :-)  The last thing I need to figure out now is why HyeprSpin can't seem to launch MAME games.  I'll keep poking around in HyperHQ to see if I can find the right settings.