CabMame

[bitbytebit]

I needed to add this so the changeres patch finally works properly. Before, it only worked when OPTION_MODELINE was not true, that's why it was working on my desktop computer but not on my cab where that option get's enabled automatically when it finds registry modelines, so the Switchres engine was forcing the resolution width/height options and then the ddraw pick_best_mode was always resulting in the initial resolution overriding the changeres option.

Code: [Select]

// Resolution change
if (window->machine->switchRes.resolution.changeres == 1) {
window->machine->switchRes.resolution.changeres = 0;
window->maxwidth = window->machine->switchRes.resolution.width;
window->maxheight = window->machine->switchRes.resolution.height;
window->refresh = window->machine->switchRes.resolution.refresh;
winwindow_toggle_full_screen();
winwindow_toggle_full_screen();
}

Of course there might be a better way of doing that.

Obvioulsy only first resolution modeline is actually calculated, for the second (usually the main one) and the next ones it will go to the default ddraw pick_best_mode, so one of the dummy modelines will be used probably with default 60Hz. But at least it doesn't crash any more and is pretty stable even with psx games for what I've seen.

Looks good, I just updated the patches and git repository with that change (I have the full source in git now too, http://mame.groovy.org lists it, can follow development and skip having to patch with that).  I'll rebuild the windows builds with it too here in a bit.

I think I can somewhat easily do the recalculation of the new modeline needed, I need to try to get that code to be more mobile so I can do it at that point.  Isn't that the place to alter the new modeline, seems like it would be.  I am going to drop resetting the old ones, since really not necessary to change them back since we always change them each use of them.  That way it should be pretty simple to jump from modeline to modeline this way as it's needed, I just need to make that code a bit easier to call quickly than having the complicated chunk in winmain.c as it is right now.

[bitbytebit]

Calamity,

Could you pull from the git repository and test it now, I hopefully have made it recalculate the modeline at resolution switching.  It at least should be close I think, but I'm not sure if there might be a few odds n ends to clean up.  Check the last change diff too and see how it's done, possibly any other additional improvements that you see could be made.  Hopefully this makes things really change resolution and get the best modeline and refresh rate for it each time.  If it works good, then I can create new diffs and builds, but figuring the git repository will work well for testing these changes since I don't have a windows/arcade monitor setup to test with.

[Calamity]

I've compiled and tested it grabbing the files from your git (it's really cool to have the full source there). It's actually recalculating the modeline each time the resolution changes but seems the switchres_calc_modeline function doesn't get the new values and always recalculates the first resolution used, (so in ga2 you'll see it always getting the 416x224 one). Which param is actually used to extract the video mode from, machine.gamedrv or &machine.switchRes?

[bitbytebit]

I've compiled and tested it grabbing the files from your git (it's really cool to have the full source there). It's actually recalculating the modeline each time the resolution changes but seems the switchres_calc_modeline function doesn't get the new values and always recalculates the first resolution used, (so in ga2 you'll see it always getting the 416x224 one). Which param is actually used to extract the video mode from, machine.gamedrv or &machine.switchRes?

Do a pull, I just pushed a bunch of fixes and think I figured out possibly at least some of what would cause that.   I basically check and let the machine.resolution. stuff override the machine.gamedrv values if the resolution height and width are filled in, which only happens after a resolution change.  Also there's the .ini file that has to be overridden too with the resolution informaiton, because I set those values to force the resolution the first modeline calculation, unless the already exist, so then after that they must be updated too but also know they'll not be 0 because we set them.  I need to probably work on the .ini file issue some more, right now hopefully it works, but I have to probably store the fact there was an .ini file resolution so we can ignore changes in resolution if someone wants to force the same resolution the whole time.

I also just made a change, I think I might have found the issue, see if it prints this out:
INI File resolution: %dx%d@%d

the changes I made should prevent that unless there really was a .ini file, also I was not running the modline calcuations without overwriting the configuration each time, I fixed that.

It might work better, good news too on the Linux side, I might just have that somewhat working soon possibly.  Some weirdness there, definitely it won't be switching through SDL because it seems deeply in SDL where it won't read modelines again unless you completely kill off and restart SDL (which of course doesn't work very nice at all).  I'm probably going to override SDL after the first modeline and any new ones will use xrandr to switch, I just have to figure out now how to resize/remaximize the window to the new resolution (probably very similar to what the windows code is doing actually).

[Calamity]

Now the new modeline is being properly recalculated it seems for what it prompts with -v so that probably is working ok, I have a problem however with this build here, the monitor options are not probably read or something, so it defaults to cga and a random aspect_ratio, don't know if it's a problem with my build not having properly updated your files but the compiler didn't give any errors.

Update: definitely the monitor options are wrong, when it prints "Monitor: %s Orientation: %s\n", it says Monitor: 000100010 or something like that.

[bitbytebit]

Now the new modeline is being properly recalculated it seems for what it prompts with -v so that probably is working ok, I have a problem however with this build here, the monitor options are not probably read or something, so it defaults to cga and a random aspect_ratio, don't know if it's a problem with my build not having properly updated your files but the compiler didn't give any errors.

Update: definitely the monitor options are wrong, when it prints "Monitor: %s Orientation: %s\n", it says Monitor: 000100010 or something like that.

Make sure to do a complete make clean, remove entire obj directory, it might be something like that and everything needs to be recompiled.  I'll double check things, but it sounds  like it might be related to the fixes I did and not all the code getting recompiled with that change.

[bitbytebit]

Now the new modeline is being properly recalculated it seems for what it prompts with -v so that probably is working ok, I have a problem however with this build here, the monitor options are not probably read or something, so it defaults to cga and a random aspect_ratio, don't know if it's a problem with my build not having properly updated your files but the compiler didn't give any errors.

Update: definitely the monitor options are wrong, when it prints "Monitor: %s Orientation: %s\n", it says Monitor: 000100010 or something like that.

Make sure to do a complete make clean, remove entire obj directory, it might be something like that and everything needs to be recompiled.  I'll double check things, but it sounds  like it might be related to the fixes I did and not all the code getting recompiled with that change.

Also I've made a few changes to make the .ini file honored and setup the resolution variable a bit better, so do a new pull in git and complete make clean and build again.  In Linux it's odd because it in theory would work but it seems Linux/SDL will lock the resolution change ability somehow so it doesn't allow even xrandr to work.  It does look like the correct monitor is used to calculate, so probably the other issue your seeing I'm guessing is from not doing a complete make clean, otherwise seems like some other trickiness happening.

[Calamity]

I'll get the new files and try a new clean build of the whole thing today, I just hoped I could avoid doing that as it takes so long but I figured it could be something related to old object files getting mixed up as I've seen problems like that before, I somewhat thought the make tool could do a better job guessing dependencies and stuff but it has to be complicated thing to do. Hopefully the Linux part will be figured up sooner or later.

[bitbytebit]

I'll get the new files and try a new clean build of the whole thing today, I just hoped I could avoid doing that as it takes so long but I figured it could be something related to old object files getting mixed up as I've seen problems like that before, I somewhat thought the make tool could do a better job guessing dependencies and stuff but it has to be complicated thing to do. Hopefully the Linux part will be figured up sooner or later.

yeah there's some issues I always see with the building and changes made, sometimes just depends on what was changed and other things like adding stuff to the structures requires a complete rebuild.  Most changes don't require a complete make clean, but the last one for the .ini file fixes does for sure.  From what I can tell it technically should not be having issues with the monitor type though, at least now, since in Linux it's retaining the same monitor type and all that code is pretty much the same for both linux and windows. 

It's like in SDL there's a lock on video mode changes, I can add video modes, but can't see them or switch to the new ones from an SDL enabled app, only the ones that were there when SDL first loaded.   I am totally confused why xrandr is also affected by this, thought it would bypass it but it says it can't see the video modes when run but can add them fine.  I'm starting to wonder if it'd be easier to fix SDL or change it to allow new video modes, or really figure out how to completely tear down and bring back up the mame OSD in mid game.  Either one is probably really tricky to do, and most likely required to get around the problem.

[bitbytebit]

I synced the builds and patches to git, so are now labeled as version .006 and can be tested more to see if the resolution changing is working right or if it needs more work.  Also this should possibly fix some issues with how soundsync worked and really turn it off, the configuration settings issue I saw with fixing the changeres stuff also affected that too.

[Calamity]

Probably today I'll be able to compile and test it. I've been trying to do it do it twice but for one or the other reason I had to stop it and messed it up, I haven't been able to stay more than two hours in the same place for some days...

[retrorepair]

So I just tested the latest build on my cab and here's my findings (apologies if I'm repeating known info here):

Soundsync can now be fully disabled, at least in the games I tested (Tekken Tag, Gradius 4, Gradius 2)

switchres (now called changeres?) works with some oddities. When changing resolution in game, it seems to take a lot longer than it should and the MAME command windows flashes up about 3 times in between. I have MALA hiding the MAME window by default and if I change that to minimise things freak out and it doesn't focus on the MAME render window once it's done changing resolutions.

Tekken Tag seems to work great, switches from interlace to progressive as it should, though the initial boot screen (coloured bars) is compressed at the sides as MAME usually renders it. However it seems other PSX based games now won't go into a progressive mode as they always have before with cabmame. I tried Shikigami no Shiro, G-Darius and Psyvariar which are all the same.

Multithreading with switchres doesn't hang up the system any more though

[Calamity]

switchres (now called changeres?) works with some oddities. When changing resolution in game, it seems to take a lot longer than it should and the MAME command windows flashes up about 3 times in between. I have MALA hiding the MAME window by default and if I change that to minimise things freak out and it doesn't focus on the MAME render window once it's done changing resolutions.

It's always been "changeres" in CabMame, "switchres" param is from Mame itself, to enable resolution switching (if it's off it will default to your desktop resolution).

Yes, this "new" method of switching resolutions on the fly is not the smoothest possible, I just wanted to find one that was safe and stable enough and start optimizing it from there. It seems the problem with the other one was that it tried to destroy the window from the main thread, so this method uses Mame's native ortodox functions to toggle fullscreen on/off.

I'll try the new build tonight and report.

[retrorepair]

Ah. I often get those confused.

I expected to be repeating known info there, just thought I'd offer some feedback. I had a feeling it was preliminary work, it certainly did the trick though.

[Calamity]

I've finally been testing this version. I've attached some logs.

ga2 is switching resolutions properly but if you see the log it looks like it's not updating the right modeline after first switch yet, it still tries to recalculate 416x224 one (although the right 320x224 resolution is selected by ddraw after that)

twincobr uses a single resolution but in this case it's virtualized for my monitor as expected. However the proper stretch does not occur and instead of that the picture appears as a wide panoramic band of only 320 pixels tall. If you see the log, notice this line:

DirectDraw: blit surface created: 720x320x32 (R=00FF0000 G=0000FF00 B=000000FF)

(this game was working perfectly right before so there must be something broken since last change)

[bitbytebit]

I've finally been testing this version. I've attached some logs.

ga2 is switching resolutions properly but if you see the log it looks like it's not updating the right modeline after first switch yet, it still tries to recalculate 416x224 one (although the right 320x224 resolution is selected by ddraw after that)

twincobr uses a single resolution but in this case it's virtualized for my monitor as expected. However the proper stretch does not occur and instead of that the picture appears as a wide panoramic band of only 320 pixels tall. If you see the log, notice this line:

DirectDraw: blit surface created: 720x320x32 (R=00FF0000 G=0000FF00 B=000000FF)

(this game was working perfectly right before so there must be something broken since last change)

Cool, thanks for the log files.  I think I fixed it, the patch is updated and also the git repository.  I need to redo the builds but might be later tonight.

Update: builds are being uploaded, will be .007, make sure they look like they are the right size since I'm uploading them into place

Update2: Realized after I left the house and going over the code an issue, so not ready just yet.  When the resolution change setting is kept, I should not change it, and the height/width used in the actual window.c code to resize the window should be the result of the modeline calculation and not the resolution mame had wanted that we used.

Update3: Ok I uploaded new patches/builds with the fix for that, only would have been an issue for a vertical game or virtualized resolutions for changes in resolution I am guessing.  Now should be mostly correct, of course I suspect a few lingering problems, hopefully can figure out the SDL issue in Linux because I'd really like to see it working and would help testing it for me.

[Calamity]

New logs attached:

ga2 seems it's fixed now, the right registry modeline is used now for resolution switching, so things seem to be working here.
twincobr still has the same problem, uses a wide rectangle of 720x320, stretching is not working for some reason.

[bitbytebit]

New logs attached:

ga2 seems it's fixed now, the right registry modeline is used now for resolution switching, so things seem to be working here.
twincobr still has the same problem, uses a wide rectangle of 720x320, stretching is not working for some reason.

Is it possibly the cleanstretch option affecting it, that should now actually get enabled or disabled, before it was always disabled actually I'm guessing in virtualized modes.  Try the newest git, be warned I've done some big changes, but want to test that it now can actually reset all the registry modelines back to how they were as it switches properly.  Besides that, also now you can force cleanstretch off all the time even if thought to be needed, basically doesn't set it if not set in the .ini or command line.  Try disabling it completely and see if virtualization works better, or maybe forcing it always enabled.  At the bottom of switchres.c where it makes those decisions based on the result of the modeline, that's where you can do that.  It may need to be different on Windows with hardware stretch opposed to in SDL with unevenstretch.

[Calamity]

Yes, it could be the cleanstretch option getting in the middle, i'll try that later and let you know...

[bitbytebit]

Yes, it could be the cleanstretch option getting in the middle, i'll try that later and let you know...

That's such an interesting option to me now, I never realized before doing this inside of mame itself how that cleanstretch option can be a key in not needing keepaspect in Linux.  Also it seems to get the aspect perfectly for me now too, on a 16:9 monitor I can setup modelines that make vertical games correct in width without keepaspect now.  The normal scaling and stretch, actually even non-stretching, in mame won't do that for me.  I think it's main thing is it calculates the x and y scale for the height and width separately, seems like that's the key, otherwise I get squares on certain games sort of.  I also of course see how in the Windows code there's a completely different interaction, and all the variables change on what looks correct and what doesn't.  I'm not sure why the old changeres option cut out all scaling, so that's another interesting difference to look at too.

[Calamity]

Well, afaik the cleanstretch hack was thought for d3d only, not for ddraw. This was because d3d always introduces some sort of fractional stretching (although d3d is what most systems use nowadays for rendering 2D stuff, it's actually a highly barroque way of doing things if you ask me. DirectDraw has a much more reasonable approach of what a frame buffer should be).

We do not stretch normally with ddraw (we're trying to get pixel perfect always that we can), and in the situations where we're using stretching we always have interlace enabled (when we virtualize due to our monitor limitations), so we DO want to have fractional stretching (filtered), as it highly reduces the flicker associated to interlaced resolutions. So I think it's safe to disable cleanstretch when using ddraw. However, I might be missing something about the cleanstretch option.

In ddraw we explicitly ask Mame to stretch the picture by using hwstretch option. I think the difference with unevenstretch is that hwstretch already has the keepaspect option built in it seems, while with unevenstretch you have to explicitly add keepaspect, otherwise it will stretch the game to full screen regardless the original aspect, maybe that's why cleanstretch is helping there recalculating things with the correct aspect ratio.

[bitbytebit]

Well, afaik the cleanstretch hack was thought for d3d only, not for ddraw. This was because d3d always introduces some sort of fractional stretching (although d3d is what most systems use nowadays for rendering 2D stuff, it's actually a highly barroque way of doing things if you ask me. DirectDraw has a much more reasonable approach of what a frame buffer should be).

We do not stretch normally with ddraw (we're trying to get pixel perfect always that we can), and in the situations where we're using stretching we always have interlace enabled (when we virtualize due to our monitor limitations), so we DO want to have fractional stretching (filtered), as it highly reduces the flicker associated to interlaced resolutions. So I think it's safe to disable cleanstretch when using ddraw. However, I might be missing something about the cleanstretch option.

In ddraw we explicitly ask Mame to stretch the picture by using hwstretch option. I think the difference with unevenstretch is that hwstretch already has the keepaspect option built in it seems, while with unevenstretch you have to explicitly add keepaspect, otherwise it will stretch the game to full screen regardless the original aspect, maybe that's why cleanstretch is helping there recalculating things with the correct aspect ratio.

Interesting, in windows then it might be best to turn it off then.  Try the git version with -nocleanstretch and see how that works, it should always force it off now.

In Linux it seems that the cleanstretch option solves a big issue with stretching, that otherwise occurs no matter what.  So very odd, seems like the way it works make Linux do what happens normally in Windows without it and using ddraw and hwstretch turned off.

I got modeswitching working in Linux, if I change the SDL library to add the modeline reading function in the resize portion of SDL calls.  It statically reads it at startup, at video init actually, and so after that it won't read it again.  I'm still looking at that, there's still oddities like not resetting anymore to the original resolution on exit, but at least I've got the issue someone pinned down.

Update:  

Make that perfect resolution switching now in Linux/SDL.  Got the library patched at the ListModes point in X11 to re-read the modelines on the system, and have to do a funky trick when exiting if we switched modes.  Seems to catch 2 bugs that I can tell in SDL, first is the not re-reading the modelines at east listmodes call, second is it was always choosing the last used mode instead of the original one we had on the desktop.

Also note the last change in the git logs, one where I fixed the SDL for Linux, there is a change that forces cleanstretch off now for Windows when we are stretching there (oddly opposite of Linux, where stretching occurs if we don't use cleanstretch but doesn't if we do?)

[bitbytebit]

I just uploaded new builds and the patch, so can test that, I have cleanstretch turn off in the windows switchres part if needing stretching.  So can see if that fixes virtualized games.  New patches also make a 'patches' directory with the SDL patch in it, for those wanting to use changeres in Linux correctly, which is working very nicely now.

[Calamity]

 

The cleanstretch on/off didn't help, it might not be related to that.

twincobr is still the same, using 720x320 (that 320 value is actually the rotated xres that for some reason is getting used there, maybe the right 560 value is overwritten by one of the last code changes).

ga2 now crashes when it attempts to switch resolutions. Notice the log is not complete, it's missing the end of it but I'm able to see it prompted in the screen and it reaches the line "SwitchRes [ga2] (1) horizontal..." where the second resolution is about to be used.

BTW: Great news that you got that in Linux!
I'll try to check the new patches for the Windows part in case I see something...

Update: I've tested ga2 without the modeline option and it works, so it looks like the new code added to the winwindow_video_window_update function in window.c is what's making it crash, that function runs in the main thread so we probably should not be adding too much stuff there and better keep the changeres code in the windows thread, so at that point in winwindow_video_window_update we'd better send an special message to the window thread and wait for it to finish.

[bitbytebit]

The cleanstretch on/off didn't help, it might not be related to that.

twincobr is still the same, using 720x320 (that 320 value is actually the rotated xres that for some reason is getting used there, maybe the right 560 value is overwritten by one of the last code changes).

ga2 now crashes when it attempts to switch resolutions. Notice the log is not complete, it's missing the end of it but I'm able to see it prompted in the screen and it reaches the line "SwitchRes [ga2] (1) horizontal..." where the second resolution is about to be used.

BTW: Great news that you got that in Linux!
I'll try to check the new patches for the Windows part in case I see something...

Update: I've tested ga2 without the modeline option and it works, so it looks like the new code added to the winwindow_video_window_update function in window.c is what's making it crash, that function runs in the main thread so we probably should not be adding too much stuff there and better keep the changeres code in the windows thread, so at that point in winwindow_video_window_update we'd better send an special message to the window thread and wait for it to finish.

Ah weird, it must be in the Windows side of the code for twincobr, can't repeat that in Linux so it must be somewhere in window.c.

The crash is odd, it might be explained though through me adding a count variable to the resolution structure so I can tell how many mode switches happened and reverse the resolution to the original in SDL.  I am completely rebuilding my windows binaries to see, and will upload those a little later.  I definitely do need to setup my windows system to test this, I think all the code to reset the old modelines are very possibly the issue.

Yeah the Linux stuff is looking nice now, so amazing it was just a simple little line in SDL to re-read those modelines. Now just to figure out what is going on in Windows.

[bitbytebit]

Yeah there's some issues I'm seeing in the code and am reworking the Windows stuff, also some of the SDL stuff too.  Some usage of the video_config variables combined with the need to make the modeline stuff a bit less dependent on the registry changing.  Also the cleanstretch option was actually being forced in some cases of stretching I think still.  Will hopefully get it sorted out in a bit, and have some builds with the changes to test.

[bitbytebit]

The cleanstretch on/off didn't help, it might not be related to that.

twincobr is still the same, using 720x320 (that 320 value is actually the rotated xres that for some reason is getting used there, maybe the right 560 value is overwritten by one of the last code changes).

ga2 now crashes when it attempts to switch resolutions. Notice the log is not complete, it's missing the end of it but I'm able to see it prompted in the screen and it reaches the line "SwitchRes [ga2] (1) horizontal..." where the second resolution is about to be used.

BTW: Great news that you got that in Linux!
I'll try to check the new patches for the Windows part in case I see something...

Update: I've tested ga2 without the modeline option and it works, so it looks like the new code added to the winwindow_video_window_update function in window.c is what's making it crash, that function runs in the main thread so we probably should not be adding too much stuff there and better keep the changeres code in the windows thread, so at that point in winwindow_video_window_update we'd better send an special message to the window thread and wait for it to finish.

Ah, I see, yeah I didn't see that update till now but makes sense I guess.  I didn't think about that when the normal check for changes occurs it's actually in the main thread.  Where do you think it should be setup and how to call that?  I haven't really gotten my mind around the whole separate thread part of mame and figured out too much of how to pass the code back and forth like that.  I do a lot of changes to test in git, but I *think* it'll crash when trying to switch resolutions with changeres (I'm recompiling from scratch to make sure).  I hopefully have gotten the virtualization issue worked out more though, not sure, but there's also the values assigned to the window->maxheight which I'm not sure the correct one, one is the resolution it had originally requested and the other is the one we've calculated and will use...

Code: [Select]

                       window->maxwidth =
                                window->machine->switchRes.resolution.width;
                                //window->machine->switchRes.modeLine->hactive;
                        window->maxheight =
                                window->machine->switchRes.resolution.height;
                                //window->machine->switchRes.modeLine->vactive;

I've made it so in theory changeres doesn't need modeline changes to work again, if there's available modelines that fit it, so can be used without just ATI cards again.  The odd crash is weird and I am suspecting recompiling, or what your saying about the windows thread and main one clashing, which also makes sense now too.

I changed the way it sets up the virtualization values, might help there I hope, shouldn't run into issues unless a changeres is turned on I am hoping, with crashing at least.  I also turned off keepaspect which I had been turning on for virtualization, that option does some weird stuff and in Linux it makes it so I can't figure out the original desktop size so I fully disable it there.  Not sure where to get the original desktop size if it's on, was using  window->monitor->center_width, window->monitor->center_height for that and works normally till keepaspect comes in and uses those values for the game size to aspect ratio it to that then I don't see where else I can find those values.  Might have to store them there or something, but that's a Linux problem, definitely more interested in the thread issue and how to do that right.

[bitbytebit]

Calamity,

Oddly I see a crash still, but even with -nomt (newest git has it so it actually turns off again from the command line).  Also it's really strange, in the debugger and also when putting in print out statements, it's right when the readSoft15KhzResolutions() function is entered, but I don't see anything printed out in that function when I put it there or the debugger, and all input variables look good.  It's the second run of it, I'm wondering if I've really ever run it twice before, but guessing that one version working for you did run it twice.  Which exact date/version/filename was it called that worked, and can you see in the git logs around which commits probably introduced it?  Pretty odd, I don't know what it's doing, seems like some weird bug that isn't giving me any information at all about it. 

[Calamity]

Hi bitbytebit,

I think the previous binary (.007) was recalculating the modeline at mode switching without crashing at all.
I also think the virtualizing problems started after these changes:

http://forum.arcadecontrols.com/index.php?topic=107255.msg1169118#msg1169118

However I'm not completely sure as I was not able to get it to compile at some points in the middle. It could help me to have an updated diff of groovymame with all the last changes so I can compile it here removing just some lines each time, and test it through Ollydbg to check were the crash comes from. Also it could be interesting from the testing point of view (it could be there already, not sure) to have groovymame setup so that you can enable modeline option and go to the whole process even if the registry modelines are not found, having an internal boolean called UpdateRegistry or something set to 0/1 only used to block the access to the registry in case no ATI-like modelines are found.

[bitbytebit]

Hi bitbytebit,

I think the previous binary (.007) was recalculating the modeline at mode switching without crashing at all.
I also think the virtualizing problems started after these changes:

http://forum.arcadecontrols.com/index.php?topic=107255.msg1169118#msg1169118

However I'm not completely sure as I was not able to get it to compile at some points in the middle. It could help me to have an updated diff of groovymame with all the last changes so I can compile it here removing just some lines each time, and test it through Ollydbg to check were the crash comes from. Also it could be interesting from the testing point of view (it could be there already, not sure) to have groovymame setup so that you can enable modeline option and go to the whole process even if the registry modelines are not found, having an internal boolean called UpdateRegistry or something set to 0/1 only used to block the access to the registry in case no ATI-like modelines are found.

I've updated the patch on the site with what I have currently.  Oddly it seems as if there's any access to the dv[] TCHAR variable in the winreg.c code, after the DefaultVideo name is found and wrote to it, then the next run of the soft15khz function will fail.  It's odd, I'm not sure what is going on, definitely a tricky one. It just seams like running that function twice, becomes odd and corrupted but not sure why, it works fine the first time and then second run just entering the function is right where it fails.

Also check this version possibly for the virtualization issues, might be better.  I found some issues in Linux that looked like the same as you saw, when using cga monitor mode, so hopefully figured those out mostly.  Now it might change things to force cleanstretch off, possibly.

Yeah I have been somewhat trying to separate it from the registry writing as much, and now it does everything but enter the parts that write the registry and do the setup of the settings from the results of the registry modeline found. 

It doesn't seem to have any difference in multithreaded or non-multithreaded mode, so I'm guessing that isn't the issue, but definitely sounds nice to move that code into the other thread if possible. 

[bitbytebit]

Calamity,

I just updated git, uploaded a patch, and am about done uploading a 32 bit build for Windows (64 coming) of version 010.  I got it to stop crashing in Windows, at least looks that way to me.  Check and see if you have it work better there, and what we need to do if anything with the virtualization  issues.  I hopefully also did something to fix that, now cleanstretch is off by default and changeres on.

I split up the method of reading the registry modelines, so I only read them on startup and use them after that so I no longer need to access the registry as much during the resolution changes.  I suspect that code was the issue having it run more than once, or it might be the thread part where the window update is that I am running the resolution change has issues if certain registry calls are made and gets sensitive.  Something strange there but now it seems to be working for me in testing, where before it was consistently crashing.  

Do you know where we should tuck the resolution change code that would be in the window thread, that is able to access the window structure and check for the changeres and act on it.  Figure we could hold off on the window update thread at touching resolutions resizes when changeres is set, and instead do it in the other location, unless you think it's ok where it's at now.  Since it only executes once or twice at startup usually if at all, resolution changes won't happen often, doesn't seem terrible there and that's of course where mame already had the basic idea of resolution resizing kept.

Update: make sure to use .010a, because I commented out some code that actually did something with the registry writing, and that build fixes it.

[Calamity]

Oh great, I'll test that when I get home. Also will think where's the right place to put the changeres code, however if you've fixed the crashing then it may be ok to keep it there by now (you're right actually, it shouldn't be a threads issue when it has worked before for me here in the previous version).

[Calamity]

Well, things are improving here. Now it's working properly with no crash at all.

ga2: the changeres is working although instead of updating modeline 320x224 its choosing 328x224, after that Mame actually uses 320x224 so the updated modeline is not used. Could you have changed anything in the resolution selection algorithm? (it used to get the right one)

twincobr: now what happens is that the game covers the full screen. It's interesting because if I set the keepaspect option on, then it looks right but in any case the aspect n:d option is not having any effect there, neither the monitor_aspect one, so it seems the usual aspect managing in Mame is overriden for some reason since the last changes.

Hopefully during the weekend I'll have some time to look throgh the code, although it's likely you'll have it fixed already by then

[bitbytebit]

Well, things are improving here. Now it's working properly with no crash at all.

ga2: the changeres is working although instead of updating modeline 320x224 its choosing 328x224, after that Mame actually uses 320x224 so the updated modeline is not used. Could you have changed anything in the resolution selection algorithm? (it used to get the right one)

twincobr: now what happens is that the game covers the full screen. It's interesting because if I set the keepaspect option on, then it looks right but in any case the aspect n:d option is not having any effect there, neither the monitor_aspect one, so it seems the usual aspect managing in Mame is overriden for some reason since the last changes.

Hopefully during the weekend I'll have some time to look throgh the code, although it's likely you'll have it fixed already by then

I think I fixed those two problems.  Check the git diff of the last checkin and should be pretty obvious, I hope it is correct.  Basically in the virtualized game case the resolution we picked size in the registry needed to be give to the window->maxheight parameters instead of the original mame requested size.  Also the registry modeline picking was not setting the resolution setting input variable to the exact one the registry had, so it was looking for the original.

Will have some binaries as 010b up in a bit to test.

[Calamity]

Testing 010b:

- twincobr is still the same, full screen.
- ga2 now ddraw and 'switchres' mode are synced, unfortunately switchres algorithm is picking 328 instead of 320x224.

Update: Shouldn't we be checking for "machine.switchRes.modeLine->result & RESULT_VIRTUALIZE" instead of this: (window.c)

                       // Aspect ratio specified
340                           if ((machine.switchRes.gameInfo.orientation && !strcmp(machine.switchRes.cs.morientation, "horizontal")) ||
341                               (!machine.switchRes.gameInfo.orientation && !strcmp(machine.switchRes.cs.morientation, "vertical")))
342                           {
343                                   options_set_string(&machine.options(), WINOPTION_ASPECT, machine.switchRes.cs.aspect, OPTION_PRIORITY_MAXIMUM);
344                           }

Oh, forget that, I see now that it's is checked right before...

[bitbytebit]

Testing 010b:

- twincobr is still the same, full screen.
- ga2 now ddraw and 'switchres' mode are synced, unfortunately switchres algorithm is picking 328 instead of 320x224.

I made a change and uploaded the new diff/new builds as 010c.  Basically am now double checking for the exact height width first before trying the fuzzy matching, so we can get an exact match if it exists.  Really odd that changed, the code is pretty much exactly the same from what I can tell, only possible thing would be it reversed the direction it's searching the list or it was out of order, but I don't think either is occurring from what I can tell.  Seems like this is a good change though, better not go through the complicated checking unless we really need to.  I am also thinking this might have always been a weakness, just not sure why not triggered before.

I don't know what is going on with twincobr, but it is an odd game because on Linux it's always done the same thing without keepaspect.  What command line options can you run normally in mame with switchres and see it work perfectly?  I'm definitely getting interested in the Windows stretching, seems like I'm doing the exact same stuff as in switchres now and only thing I can think of is if cleanstretch is getting on somehow externally which I double, or some other trick is occurring.  The aspect ratio calculation shouldn't be altered, so I'm not sure why it's acting that way.  I'll also play around with it more here, seems like it's an issue duplicating the command line perfectly that works.


Also try running those tests for twincobr (and ga2 if it still has issues with the newest update) with the arg added -md 4 or more, that might give more details too.

[Calamity]

Well, this is definitely a mystery. I've rescued groovymame patch 004, and with it twincobr sets aspect ratio perfectly, and monitor_aspect works again, same mame.ini, same command line. I've attached the logs of both 004 and 010b patches, notice they both are actually using the same resolution, modelines, and all, so could be good to know which exact mame config options are actually being used to see if there's something wrong with that, maybe a side effect of some change that you've done recently.

On the other hand ga2 insists on selecting 328 instead of 320...

And also tried switchres by first time since and installed xp64, it's not working here (seems it can't find the path for mame binary, it's in the same folder), could it be a problem of this switchres being a 32bit build?

[bitbytebit]

Well, this is definitely a mystery. I've rescued groovymame patch 004, and with it twincobr sets aspect ratio perfectly, and monitor_aspect works again, same mame.ini, same command line. I've attached the logs of both 004 and 010b patches, notice they both are actually using the same resolution, modelines, and all, so could be good to know which exact mame config options are actually being used to see if there's something wrong with that, maybe a side effect of some change that you've done recently.

On the other hand ga2 insists on selecting 328 instead of 320...

And also tried switchres by first time since and installed xp64, it's not working here (seems it can't find the path for mame binary, it's in the same folder), could it be a problem of this switchres being a 32bit build?

Odd, really strange how the change I made didn't get that resolution correct, seems something else is going on.

I uploaded new 010d versions that now print out every option changed, that might help see what is going on hopefully.

I'll have to look deeper into what is going on with the registry modeline choice.

[Calamity]

Well, finally got it. I have actually been wrong all this time on how I thought the keepaspect option was working. It is necessary indeed to have keepaspect on to enable the aspect correction mechanism to work, so if it's off it won't use the screen_aspect option at all. So just enabled it in the ini and it started to work as usual. I can't understand how I haven't noticed that while doing all the tests during these days, silly me, sorry.

Then it sounds this mechanism is exactly the same in Linux, and maybe explains why you've been seeing that also there.

Also have managed to get Switchres working again, so I can double test with it.

This weekend I'll have a look at that modeline selection function in case I see something that explains the 328 thing.

[bitbytebit]

Well, finally got it. I have actually been wrong all this time on how I thought the keepaspect option was working. It is necessary indeed to have keepaspect on to enable the aspect correction mechanism to work, so if it's off it won't use the screen_aspect option at all. So just enabled it in the ini and it started to work as usual. I can't understand how I haven't noticed that while doing all the tests during these days, silly me, sorry.

Then it sounds this mechanism is exactly the same in Linux, and maybe explains why you've been seeing that also there.

Also have managed to get Switchres working again, so I can double test with it.

This weekend I'll have a look at that modeline selection function in case I see something that explains the 328 thing.

Ah cool, well makes more sense to me now yeah I was really seeing in Linux it was required so didn't understand why in Windows it'd be different, hopefully having things print out like that will be nice for any other issues we run into now.

Also I just uploaded a 010e with more debugging output in the registry modeline selection, but of course will be another 010f now adding the keepaspect change, but they'll have that extra output from now on and possibly some more later tonight.