Switchres: modeline generator engine

[Calamity]

Ah sorry, I always forget the md 4 param, here it is.

[bitbytebit]

Ah sorry, I always forget the md 4 param, here it is.

I've got a fix hopefully, I was checking the wrong one for doubling for the height/width, that probably is the issue.  Also might have fixed the logic in the other checks there, was doing it backwards from the registry value to the target value .

Also trying to check in the available modes to make sure the resolution is available, see if it really can figure that out, it says none of mine are available because they aren't, not sure if it will be able to know for sure.  Right now it just checks and warns, since by the time that is called the resolution is already picked.  Have to look at a way to do it yet avoid the large static arrays like before which cause issues and too much extra looping over and over, at least try to do the minimal amount.

I have a patch uploaded, git updated, and updated the 012b builds with the fix so you can see if it's working right now.

Update:
 Ah I actually now see how it just needed a 2x width and height case, I didn't actually have that case built in, and the other change I made was not good and probably broke the other ones that did work . 

I am uploading new builds with fixes to that, but also I think I hopefully got the other logic right too, a bit confusing getting the logic all right in comparing the correct one with the right multiplier. The newer uploads should be in place now, these should be a bit better I hope.

[bitbytebit]

Ah sorry, I always forget the md 4 param, here it is.

I've got a fix hopefully, I was checking the wrong one for doubling for the height/width, that probably is the issue.  Also might have fixed the logic in the other checks there, was doing it backwards from the registry value to the target value .

Also trying to check in the available modes to make sure the resolution is available, see if it really can figure that out, it says none of mine are available because they aren't, not sure if it will be able to know for sure.  Right now it just checks and warns, since by the time that is called the resolution is already picked.  Have to look at a way to do it yet avoid the large static arrays like before which cause issues and too much extra looping over and over, at least try to do the minimal amount.

I have a patch uploaded, git updated, and updated the 012b builds with the fix so you can see if it's working right now.

Update:
 Ah I actually now see how it just needed a 2x width and height case, I didn't actually have that case built in, and the other change I made was not good and probably broke the other ones that did work .  

I am uploading new builds with fixes to that, but also I think I hopefully got the other logic right too, a bit confusing getting the logic all right in comparing the correct one with the right multiplier. The newer uploads should be in place now, these should be a bit better I hope.

 

I'm uploading some more changes, should be up now, because now I'm properly making interlaced a lower priority, and should be doing the fuzzy matching in a much more precise way with more complex scoring for that.  If working right, it should now really be intelligent about which fuzzy match it picks if any are close to decent.  It's interesting because right now it seems to be able to pick the couple most popular resolutions in order for vertical games, like with pacman it'll pick first the 400x288, then second 382x288 and third 352x288, which are all ones I've seen used in different places (so it knows that 400x288 is the proper aspect ratio one, but the others are decent compromises).  

The scoring is definitely looks like quite a tricky thing to do, at least the 'fuzzy matching' which mame really doesn't seem to do from what I've been able to ever tell (it just picks a large resolution, it can't find one that's just 8-16 lines/pixels bigger, at least from what I've seen).  That might be an SDL specific characteristic though, those double resolutions and possibly the general way it picks seem a bit different.  I was looking at the direct draw vs. d3d picking method, and that's interesting how that all works, I need to compare the SDL part to those and see if the differences really are in the actual OS libraries/drivers themselves.

Update: Also the last commit in the git repository tries to really skip and not use the non-available modelines, it's only in the updated patch and git, not the builds.  So I can't test that one here, since my modelines are all non-active, but see how that works there and if it does things right.  Only fear I have is mainly the calling of that Enum call too much, not sure if that is safe or not, I'm hoping it's harmless.  It avoids the issue of needing the big array allocated that causes the Windows stack to crash.

[MonkeyJug]

hi bitbytebit - i have the linux cd installed and running now, and i'm very pleased with how it all looks.  just a couple of questions...

1. i have downloaded a whole bunch of snaps, and they are placed inside the snaps folder, however, i can see no way to get them to appear on the advancemenu frontend.  can you advise on this, please?

2. ordered a new j-pac, and it is now re-syncing everytime i switch games, and switch back to the frontend.  seems like it was indeed faulty - not sure what happened to it, but my question is this:  for a tri-sync monitor (15/24/31), what video settings should i be selecting in the monitor setup section?  my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

3.  for the video output, i'm assuming i should be selecting 15khz, even though my monitor is tri-sync?  and why is there an option for 'disable output'?  what is the relevance of that?

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...

[bitbytebit]

hi bitbytebit - i have the linux cd installed and running now, and i'm very pleased with how it all looks.  just a couple of questions...

1. i have downloaded a whole bunch of snaps, and they are placed inside the snaps folder, however, i can see no way to get them to appear on the advancemenu frontend.  can you advise on this, please?

2. ordered a new j-pac, and it is now re-syncing everytime i switch games, and switch back to the frontend.  seems like it was indeed faulty - not sure what happened to it, but my question is this:  for a tri-sync monitor (15/24/31), what video settings should i be selecting in the monitor setup section?  my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

3.  for the video output, i'm assuming i should be selecting 15khz, even though my monitor is tri-sync?  and why is there an option for 'disable output'?  what is the relevance of that?

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...

Ah, yeah that snaps folder is something that is wrong actually, I need to clear that up better.  It's actually this folder...

emulator_altss "mame" "/home/roms/ttl"

So /home/roms/ttl/ for the title screens or basically it looks in there, by the advance menu config currently setup.

Yeah it uses interlaced when setup to arcade monitors, but yet your monitor can do the 640x480 like mine.  I am guessing the J-Pac is doing the thing where it refuses to pass the 31khz signal to your monitor and doubling the screen.  Maybe Calamity knows what to do in this case, is it a jumper or setting? That would allow the 32khz signals through too.

Oh, ignore that, it's only for changing the video card output when you want to for example change from VGA-0 to DVI-0, or basically the VGA to the DVI connector, or back.  So if you boot with the right option and don't change the output ever, then you can ignore that setup menu.

I'll give alcon a check on my arcade monitor, on my LCD here with resolution switching it is running at 100% but this computer may be different.
Update: Yeah alcon works fine here, sounds odd, possibly a full -verbose -md 4 log from groovymame would show something, also what exact brand is that monitor?  I could try to find specs on it and add it, possibly another issue, although less likely. 

[MonkeyJug]

I'll give alcon a check on my arcade monitor, on my LCD here with resolution switching it is running at 100% but this computer may be different.
Update: Yeah alcon works fine here, sounds odd, possibly a full -verbose -md 4 log from groovymame would show something, also what exact brand is that monitor?  I could try to find specs on it and add it, possibly another issue, although less likely.  

wow, that would be great!

it's a 'Wei-Ya M31 Series CGA/EGA/VGA 29" Monitor', with a 3129DB chassis.

i had a quick look on google and found this link, but i'm unable to confirm what's there due to it being filtered out at my workplace.  hopefully it contains the info you're looking for:

wiki.arcadeotaku.com/w/File:Wei-ya_M3192D_manual.pdf

basically the monitors are installed into the Big Century (and i think, OK Baby) cabinets.  a link for the cabinets is here:

http://www.gremlinsolutions.co.uk/ebaybigcentury.htm

maybe you could contact them and see if they can help you with that information...

if you can do that, a hefty donation will be coming your way!

regarding Alcon, i've tried it on 2 fairly beefy pcs, and i can get it to run slightly faster, (about 92% if i try with d9800 as the selected monitor) - weird how it runs 100% your end - i loved that game as a boy!

[bitbytebit]

I'll give alcon a check on my arcade monitor, on my LCD here with resolution switching it is running at 100% but this computer may be different.
Update: Yeah alcon works fine here, sounds odd, possibly a full -verbose -md 4 log from groovymame would show something, also what exact brand is that monitor?  I could try to find specs on it and add it, possibly another issue, although less likely.  

wow, that would be great!

it's a 'Wei-Ya M31 Series CGA/EGA/VGA 29" Monitor', with a 3129DB chassis.

i had a quick look on google and found this link, but i'm unable to confirm what's there due to it being filtered out at my workplace.  hopefully it contains the info you're looking for:

wiki.arcadeotaku.com/w/File:Wei-ya_M3192D_manual.pdf

basically the monitors are installed into the Big Century (and i think, OK Baby) cabinets.  a link for the cabinets is here:

http://www.gremlinsolutions.co.uk/ebaybigcentury.htm

maybe you could contact them and see if they can help you with that information...

if you can do that, a hefty donation will be coming your way!

regarding Alcon, i've tried it on 2 fairly beefy pcs, and i can get it to run slightly faster, (about 92% if i try with d9800 as the selected monitor) - weird how it runs 100% your end - i loved that game as a boy!

I think to start off, trying a d9200 profile for this monitor but minus the SVGA section would be good.  I'm not sure if the front/back porch values are exact, but might not be so bad.  So I added an m3292 monitor type to groovymame to try, I'll put it into the next Linux ISO and will upload new Windows builds with it.  So trying it with an m3192 monitor with the Windows build might be interesting, I'll need to look at adding this to the menu on the Linux ISO too.

Mostly the d9200 profile should work, except if it creeps up into the SVGA range, but that shouldn't happen too often, most everything normally would stay in the VGA and below.  I think the alcon issue might just be the processor, but amazing that it takes that much processor to run that game, but sounds like the issue. The J-Pac issue I'm guessing is trying to use the J-Pac with something more than 15khz, so that's possibly some setting on it, at least from what I can tell.

[Calamity]

my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

You'll need to remove the proper jumpers on your jpac to allow 31Khz signal to pass the filter.

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...

That game, when rotated, uses 280 lines. You can't get 60Hz having to draw so many lines with a normal arcade monitor, that's why you only get 88% of its speed. pacman, contra, dspirit and such games should show the same issue. But they *should* run 100% with the D9800 setup, if otherwise please post your logs so we can check what's wrong there.

[MonkeyJug]

I think to start off, trying a d9200 profile for this monitor but minus the SVGA section would be good.  I'm not sure if the front/back porch values are exact, but might not be so bad.  So I added an m3292 monitor type to groovymame to try, I'll put it into the next Linux ISO and will upload new Windows builds with it.  So trying it with an m3192 monitor with the Windows build might be interesting, I'll need to look at adding this to the menu on the Linux ISO too.

Mostly the d9200 profile should work, except if it creeps up into the SVGA range, but that shouldn't happen too often, most everything normally would stay in the VGA and below.  I think the alcon issue might just be the processor, but amazing that it takes that much processor to run that game, but sounds like the issue. The J-Pac issue I'm guessing is trying to use the J-Pac with something more than 15khz, so that's possibly some setting on it, at least from what I can tell.

the d9200 profile works very well for the most part.  one game that i'd like to play that is problematic though is strikers 1945 ii (s1945ii) which just won't sync with that profile, but will sync no problems when the video mode is set to CGA.

one minor issue, that link that i gave you above, i only just noticed it says M3192, whereas my monitor/chassis is M3129.  i checked last night and that .pdf is exactly the same as the manual that came with my cabinet.  not sure if it's a typo or not, but as i'm not at home right now to test it, can you just confirm that i should set the monitor type in the groovymame .ini file to M3292 and not M3192 or even M3129!  i'm just a bit confused with the 29s or 92s!

thank you so much for doing this, by the way!

[Calamity]

A quick fix, in your GetAvailableVideoModes function you need to change this:

Code: [Select]

while (EnumDisplaySettings( NULL, iModeNum, &lpDevMode ) != 0) {
if (lpDevMode.dmBitsPerPel == 32) {
if (lpDevMode.dmPelsWidth == width
&& lpDevMode.dmPelsHeight == height
//&& lpDevMode.dmPelsWidth == height)
&& lpDevMode.dmDisplayFrequency == freq)
Now it works here, I've attached bublbobl log...
Update: Also have a look at loht's log, it doesn't choose any mode so ddraw selects its own one.

[bitbytebit]

I think to start off, trying a d9200 profile for this monitor but minus the SVGA section would be good.  I'm not sure if the front/back porch values are exact, but might not be so bad.  So I added an m3292 monitor type to groovymame to try, I'll put it into the next Linux ISO and will upload new Windows builds with it.  So trying it with an m3192 monitor with the Windows build might be interesting, I'll need to look at adding this to the menu on the Linux ISO too.

Mostly the d9200 profile should work, except if it creeps up into the SVGA range, but that shouldn't happen too often, most everything normally would stay in the VGA and below.  I think the alcon issue might just be the processor, but amazing that it takes that much processor to run that game, but sounds like the issue. The J-Pac issue I'm guessing is trying to use the J-Pac with something more than 15khz, so that's possibly some setting on it, at least from what I can tell.

the d9200 profile works very well for the most part.  one game that i'd like to play that is problematic though is strikers 1945 ii (s1945ii) which just won't sync with that profile, but will sync no problems when the video mode is set to CGA.

one minor issue, that link that i gave you above, i only just noticed it says M3192, whereas my monitor/chassis is M3129.  i checked last night and that .pdf is exactly the same as the manual that came with my cabinet.  not sure if it's a typo or not, but as i'm not at home right now to test it, can you just confirm that i should set the monitor type in the groovymame .ini file to M3292 and not M3192 or even M3129!  i'm just a bit confused with the 29s or 92s!

thank you so much for doing this, by the way!

The manual probably is the same for either, just basically showing that it has the 3 different khz ranges and basically like the d9200.  The difference is that the d9200 can also use the SVGA range and so possibly that one game is trying to use that range, and so can't sync.  The change I made skips that range if given the new m3292 monitor type, although I need to rethink some things on how the Linux setup works for monitor selection.  Mainly because it is getting kind of full of monitor types, 10 already, I need to either submenu them or some other method.  Also I need to now look at the way the general desktop modeline is generated, am using switchres but I'm now thinking that redoing it so that switchres shares the same code as mame, or groovymame itself has a -showmode arg or something so it has the switchres modeline generation output built into it.  So I can have the monitor types and ranges it supports not have to be added into switchres and groovymame, plus the calculations in groovymame are now advancing a bit ahead of what switchres does and best to find a way to unify them now instead of later.

[bitbytebit]

A quick fix, in your GetAvailableVideoModes function you need to change this:

Code: [Select]

while (EnumDisplaySettings( NULL, iModeNum, &lpDevMode ) != 0) {
if (lpDevMode.dmBitsPerPel == 32) {
if (lpDevMode.dmPelsWidth == width
&& lpDevMode.dmPelsHeight == height
//&& lpDevMode.dmPelsWidth == height)
&& lpDevMode.dmDisplayFrequency == freq)
Now it works here, I've attached bublbobl log...
Update: Also have a look at loht's log, it doesn't choose any mode so ddraw selects its own one.

Ah, wow, I definitely didn't look closely at that , I am uploading the 012d builds with that fix.  So all the scoring seems sane?, one thing I'm wondering is if in all cases interlacing is properly scored lower than the progressive possibilities, at least in the fuzzy match cases where things can't be multiples.  It's definitely a big change/leap in how that all works, hopefully for the good since before compared to this things were really going to be random with a small set of resolutions like the default Soft15khz ones.

[Calamity]

Ah, wow, I definitely didn't look closely at that , I am uploading the 012d builds with that fix.  So all the scoring seems sane?, one thing I'm wondering is if in all cases interlacing is properly scored lower than the progressive possibilities, at least in the fuzzy match cases where things can't be multiples.  It's definitely a big change/leap in how that all works, hopefully for the good since before compared to this things were really going to be random with a small set of resolutions like the default Soft15khz ones.

Yes I'm starting to have a look at the scoring system now as before all the modelines were marked as non available but for the "square" ones (same width/height) so it was easy to find the bug . Now I'm testing on my lcd here, so have no interlaced modes. I'm seeing that when no suitable resolution is found all are scored to 0.00 so directdraw is free to select whatever it decides, we should fix that I'm thinking. Although this lcd case is not our target, it would be elegant to make it work the best possible even if lcds are evil.

There are very subtle details that need to be accounted for, I'll try to think of them and probably help with implementation. It's not a trivial matter at all. Not all refresh rates can be obtained for all resolutions, and it will highly depend on the monitor selected, fortunately we have the info to do that based on our calculations. No one has done that before afaik.

I've noticed a big slowdown at startup, probably due to the way EnumDisplaySettings is called so many times now. Not important by now but I believe it could be solved by using a static array for our modes, maybe allocating memory at the beginning and using it after that.

[MonkeyJug]

my understanding, although likely wrong, is that i should be selecting either d9200 or d9800, but when i do this, i get the split-screen on the frontend.  games however mostly launch fine, with the odd one not syncing properly.  when i set it to either cga, or h9110, the front end displays fine, but is 'flickery' as if interlaced...  my monitor can display 640x480p, and i'm not sure what resolution the front end is being displayed at.

You'll need to remove the proper jumpers on your jpac to allow 31Khz signal to pass the filter.

edit: 4: can you have a look at 'alcon' (slap fight here in the uk).  i can only get it to run at around 88% speed-wise...

That game, when rotated, uses 280 lines. You can't get 60Hz having to draw so many lines with a normal arcade monitor, that's why you only get 88% of its speed. pacman, contra, dspirit and such games should show the same issue. But they *should* run 100% with the D9800 setup, if otherwise please post your logs so we can check what's wrong there.

as a test this morning, i ran the video settings in the linux cd as VGA (31khz) and removed the 15khz jumper from the jpac, leaving just the 31khz attached.  the frontend displayed, full-screen, with no flicker, (640x480p) and 'alcon' did indeed run at 100%, although the screen resolution was obviously completely messed up.

it's a brand new jpac, but i'm unsure if it is displaying symptoms that are considered normal.  ie. selecting d9200 from the linux cd, with jumpers on both 15khz and 31khz, it boots to the front end, in split screen (interlaced?), whereas i believe it 'should' be displaying a 640x480p full-screen.  launch any low-res game and it displays perfectly, full-screen, then if i exit back to the front end, i still get the split screen...

however, if i then remove the power to the jpac temporarily, and remove the 15khz jumper, leaving just the 31khz jumper attached, and then reconnect the power, it displays 640x480p in the front end perfectly, full-screen.  then if i launch, for example, tekken tag tournament (which off the top of my head is 640x480p), it also displays full-screen and looks perfect...  nothing happens when i launch a low-res game (black screen) which i'm guessing is perfectly normal because i have removed the 15khz jumper.

with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

[Calamity]

with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

Attaching both 15 and 31Khz jumpers is only intended for 15Khz monitors, to filter 31Khz signal and show it as split screen. Otherwise you should only use one jumper, depending on your monitor frequency range. What happens if you have a multisync monitor? I don't know I'd check if it works by removing all jumpers: that way your jpac sends composite sync, there's a chance your monitor will accept that.

[Calamity]

I'm testing this version with tricky mode tables to see how it behaves and looks pretty good. I'm using modes starting from 432 or so, and it works surprisingly well. I've noticed with this mode table that I need to set keepaspect in order to have vertical games like pacman to show properly: instead of 400x288, that's missing, it goes for 800x288, but then it looks double wide unless I use keepaspect (which doesn't seem to create any artifacts so I think it's clean to do so). On the other hand most horizontal games look perfect, although I have not defined resolutions below 432, it goes for the exact multiple and it's impossible to tell the difference. I've found two odd cases:

- ghouls for some reason picks the right resolution and all the logs look perfect, but for some reason it doesn't perform the xres*2 scaling and the picture is very narrow
- mk works fine but 110% of it's speed, even if the logs look correct, it's confusing...

Apart from the big slowdown when checking resolutions, I've seen it get in a loop when trying to switch resolutions back and forth sometimes, until you kill the app. This is for sure due to the abuse of EnumDisplaySettings I'm thinking. That could be causing the mk issue probably as a side effect if the dynamic modeline magic is affected by that, not sure.

[bitbytebit]

I'm testing this version with tricky mode tables to see how it behaves and looks pretty good. I'm using modes starting from 432 or so, and it works surprisingly well. I've noticed with this mode table that I need to set keepaspect in order to have vertical games like pacman to show properly: instead of 400x288, that's missing, it goes for 800x288, but then it looks double wide unless I use keepaspect (which doesn't seem to create any artifacts so I think it's clean to do so). On the other hand most horizontal games look perfect, although I have not defined resolutions below 432, it goes for the exact multiple and it's impossible to tell the difference. I've found two odd cases:

- ghouls for some reason picks the right resolution and all the logs look perfect, but for some reason it doesn't perform the xres*2 scaling and the picture is very narrow
- mk works fine but 110% of it's speed, even if the logs look correct, it's confusing...

Apart from the big slowdown when checking resolutions, I've seen it get in a loop when trying to switch resolutions back and forth sometimes, until you kill the app. This is for sure due to the abuse of EnumDisplaySettings I'm thinking. That could be causing the mk issue probably as a side effect if the dynamic modeline magic is affected by that, not sure.

Yeah I'm reworking how the resolutions are read/stored to fix the need to call Enum so much.  Basically closer to what you originally had, but just one single list of active resolutions, filled in custom modelines.  So it will both only allow real active resolutions into the list, have the non-custom ones there for the ability to choose them if we must, and probably more possibilities from having them all read into an array at startup and labeled properly (plus sorted too, so making sure they are in order, although the scoring has probably made that less likely to matter).  Will see how this works out, should be interesting doing it this way, and how easily I can figure out ways to exploit the system resolutions when we don't have custom ones that fit, or being able to see the ArcadeVGA 3000 possible resolutions to use. 

[bitbytebit]

I'm testing this version with tricky mode tables to see how it behaves and looks pretty good. I'm using modes starting from 432 or so, and it works surprisingly well. I've noticed with this mode table that I need to set keepaspect in order to have vertical games like pacman to show properly: instead of 400x288, that's missing, it goes for 800x288, but then it looks double wide unless I use keepaspect (which doesn't seem to create any artifacts so I think it's clean to do so). On the other hand most horizontal games look perfect, although I have not defined resolutions below 432, it goes for the exact multiple and it's impossible to tell the difference. I've found two odd cases:

- ghouls for some reason picks the right resolution and all the logs look perfect, but for some reason it doesn't perform the xres*2 scaling and the picture is very narrow
- mk works fine but 110% of it's speed, even if the logs look correct, it's confusing...

Apart from the big slowdown when checking resolutions, I've seen it get in a loop when trying to switch resolutions back and forth sometimes, until you kill the app. This is for sure due to the abuse of EnumDisplaySettings I'm thinking. That could be causing the mk issue probably as a side effect if the dynamic modeline magic is affected by that, not sure.

I have made changes, 012e builds will show up in a few minutes.  I have completely changed the way it gathers the custom modelines and now it basically gets all active modelines and marks them as either custom or not, very much like your original methods, put back all the active modeline reading code I had removed.  Also I now actually treat active modelines as possible usable modelines (although without ability to change the refresh rates) yet they never will be chosen over a custom modeline (unless I have bugs there).  So there's a lot to test, but this might be really neat when it works right, which hopefully is now but I'm suspecting everything might not be perfect yet since it required quite a bit of changes.  Also this in theory will work really good with an ArcadeVGA 3000 card and avoid .ini files, although it's funny because now I realize you never can really get vsync with an arcade VGA 3000 card since how could you with it not even reporting the proper refresh rates for the modelines.  I guess with the Arcade Perfect utility you could tweak each games modeline chosen to match, and then know it through that, but wow that sounds like a pain in the butt to do for every single game by hand.  Well I basically default to using throttle and possible the other lesser things like triple buffer etc. if either it's a System modeline or ArcadeVGA3000 modeline. 

Anyone wanting to test this, great, otherwise stick to the previous 012d version for stability till Calamity confirms it's safe .       

[MonkeyJug]

with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

Attaching both 15 and 31Khz jumpers is only intended for 15Khz monitors, to filter 31Khz signal and show it as split screen. Otherwise you should only use one jumper, depending on your monitor frequency range. What happens if you have a multisync monitor? I don't know I'd check if it works by removing all jumpers: that way your jpac sends composite sync, there's a chance your monitor will accept that.

therein lies my problem!

via the jpac, if i remove both jumpers, i get split screen, with vertical roll that can't be held.
but if i then install a jumper in 31khz, it snaps straight into place, with full screen and games like tekken launch perfectly.  obviously, 15khz games won't display.

when i bypass the jpac altogether (my preferred method) and go straight to the vga of the monitor, the picture rolls vertically and split screen, and ONLY when i tick the box in ATI CCC for 'composite sync' does it snap to fullscreen and holds perfectly.

unfortunately, on the live-cd, i don't have such an option.  i've even gone so far as to buy a vga breakout cable, and run it to the vga of the monitor, and have tried connecting every single possible combination of h/v sync, but can't get the picture to stop rolling vertically...

sorry to go off-topic, but i've spent four days now trying to get the bloody thing to stop rolling vertically via the linux install, but i'm stumped!  i feel like chucking the whole thing off my balcony!



what i need is an option for 'composite sync' in the linux install, as it is in the ati ccc, but i'm not sure if bitbytebit could achieve such a thing...

i'm gonna give it a rest for a week or two very soon, cos it's putting years on me!

[bitbytebit]

with both jumpers attached, (allowing to launch low-res and hi-res games), my problem seems to be 640x480p isn't given priority over the jpac insisting on splitting the signal and displaying a split screen... i very confused!

Attaching both 15 and 31Khz jumpers is only intended for 15Khz monitors, to filter 31Khz signal and show it as split screen. Otherwise you should only use one jumper, depending on your monitor frequency range. What happens if you have a multisync monitor? I don't know I'd check if it works by removing all jumpers: that way your jpac sends composite sync, there's a chance your monitor will accept that.

therein lies my problem!

via the jpac, if i remove both jumpers, i get split screen, with vertical roll that can't be held.
but if i then install a jumper in 31khz, it snaps straight into place, with full screen and games like tekken launch perfectly.  obviously, 15khz games won't display.

when i bypass the jpac altogether (my preferred method) and go straight to the vga of the monitor, the picture rolls vertically and split screen, and ONLY when i tick the box in ATI CCC for 'composite sync' does it snap to fullscreen and holds perfectly.

unfortunately, on the live-cd, i don't have such an option.  i've even gone so far as to buy a vga breakout cable, and run it to the vga of the monitor, and have tried connecting every single possible combination of h/v sync, but can't get the picture to stop rolling vertically...

sorry to go off-topic, but i've spent four days now trying to get the bloody thing to stop rolling vertically via the linux install, but i'm stumped!  i feel like chucking the whole thing off my balcony!



what i need is an option for 'composite sync' in the linux install, as it is in the ati ccc, but i'm not sure if bitbytebit could achieve such a thing...

i'm gonna give it a rest for a week or two very soon, cos it's putting years on me!

I don't know if it's really still supported, I'm hoping it is, but in Linux seems that adding Composite and possibly either +CSync or -CSync to the modeline enables composite sync.  I'll look into if that really is a valid option still.

[Calamity]

I have made changes, 012e builds will show up in a few minutes.  I have completely changed the way it gathers the custom modelines and now it basically gets all active modelines and marks them as either custom or not, very much like your original methods, put back all the active modeline reading code I had removed.  Also I now actually treat active modelines as possible usable modelines (although without ability to change the refresh rates) yet they never will be chosen over a custom modeline (unless I have bugs there).  So there's a lot to test, but this might be really neat when it works right, which hopefully is now but I'm suspecting everything might not be perfect yet since it required quite a bit of changes.  Also this in theory will work really good with an ArcadeVGA 3000 card and avoid .ini files, although it's funny because now I realize you never can really get vsync with an arcade VGA 3000 card since how could you with it not even reporting the proper refresh rates for the modelines.  I guess with the Arcade Perfect utility you could tweak each games modeline chosen to match, and then know it through that, but wow that sounds like a pain in the butt to do for every single game by hand.  Well I basically default to using throttle and possible the other lesser things like triple buffer etc. if either it's a System modeline or ArcadeVGA3000 modeline. 

Anyone wanting to test this, great, otherwise stick to the previous 012d version for stability till Calamity confirms it's safe .       

I can confirm it's not slow anymore at startup so the new method for storing video modes seems pretty good now. Anyway I'm testing on my lcd so I can't give a good report yet. I notice that in many situations no good match is found ("SwitchRes: Index -1/101 modeline  score 0.00 has no match") and then a bunch of undesired options are enabled (like hwstretch) and it gives ddraw the oportunity to make its own decisions. I think we should always come with a decision even if not a very good one, and completely override what ddraw decides. Also, the scoring system could be inverse, as in Switchres, so the bigger the score the worse the mode, that way you always make sure to have a rate for each mode. Being able to use native video modes is definitely a good thing, however we should be able to decide if we want to use them or not. For instance, when using my hacked drivers, native modes are still present but they run at 31Khz or whatever, so those are there in case we want to plug a lcd but should be avoided all the time for emulation with arcade monitors, some of them are even broken (320x and 400x ones). On the other hand, if using a lcd that is fixed to 60Hz, maybe it makes no sense to use modelines at all and better use the native video modes, so it's good to be able choose the best one. Even in that case, one could decide to turn vsync + soundsync on all the time to make all games run at 60Hz with smooth scrolling. The same is valid for ArcadeVGA 3000, we should not make decisions based on the fake vfreq label, as some advanced users might have tweaked their modes using ArcadePerfect so better give the opportunity to enable vsync + syncrefresh in all cases and let the user be responsible of mantaining his adjustments.

[bitbytebit]

I have made changes, 012e builds will show up in a few minutes.  I have completely changed the way it gathers the custom modelines and now it basically gets all active modelines and marks them as either custom or not, very much like your original methods, put back all the active modeline reading code I had removed.  Also I now actually treat active modelines as possible usable modelines (although without ability to change the refresh rates) yet they never will be chosen over a custom modeline (unless I have bugs there).  So there's a lot to test, but this might be really neat when it works right, which hopefully is now but I'm suspecting everything might not be perfect yet since it required quite a bit of changes.  Also this in theory will work really good with an ArcadeVGA 3000 card and avoid .ini files, although it's funny because now I realize you never can really get vsync with an arcade VGA 3000 card since how could you with it not even reporting the proper refresh rates for the modelines.  I guess with the Arcade Perfect utility you could tweak each games modeline chosen to match, and then know it through that, but wow that sounds like a pain in the butt to do for every single game by hand.  Well I basically default to using throttle and possible the other lesser things like triple buffer etc. if either it's a System modeline or ArcadeVGA3000 modeline. 

Anyone wanting to test this, great, otherwise stick to the previous 012d version for stability till Calamity confirms it's safe .       

I can confirm it's not slow anymore at startup so the new method for storing video modes seems pretty good now. Anyway I'm testing on my lcd so I can't give a good report yet. I notice that in many situations no good match is found ("SwitchRes: Index -1/101 modeline  score 0.00 has no match") and then a bunch of undesired options are enabled (like hwstretch) and it gives ddraw the oportunity to make its own decisions. I think we should always come with a decision even if not a very good one, and completely override what ddraw decides. Also, the scoring system could be inverse, as in Switchres, so the bigger the score the worse the mode, that way you always make sure to have a rate for each mode. Being able to use native video modes is definitely a good thing, however we should be able to decide if we want to use them or not. For instance, when using my hacked drivers, native modes are still present but they run at 31Khz or whatever, so those are there in case we want to plug a lcd but should be avoided all the time for emulation with arcade monitors, some of them are even broken (320x and 400x ones). On the other hand, if using a lcd that is fixed to 60Hz, maybe it makes no sense to use modelines at all and better use the native video modes, so it's good to be able choose the best one. Even in that case, one could decide to turn vsync + soundsync on all the time to make all games run at 60Hz with smooth scrolling. The same is valid for ArcadeVGA 3000, we should not make decisions based on the fake vfreq label, as some advanced users might have tweaked their modes using ArcadePerfect so better give the opportunity to enable vsync + syncrefresh in all cases and let the user be responsible of mantaining his adjustments.

Cool, I have made changes that mostly fit those issues.  I didn't reverse the scoring system, yet, but think I have worked around the need to.  Also now the logic will always skip interlaced modes if we've found a progressive, instead of just scoring them lower.  Also if there's a custom modeline, even one,  it'll always pick them over system ones.  Figure if a user has any custom modelines, then it says they aren't using an ArcadeVGA for sure, and probably aren't going to want system modelines in the way.  Also I removed that default options stuff when no modelines were found (which now should only happen when there are absolutely no system or custom modelines larger or equal to the height of the target resolution.

It'll be 012f and uploaded builds here in  a few minutes.   At least should address the major issues your seeing, can see how there could be some more improvement on setting choices/methods for users overriding them at times, and possibly the scoring system reversing although I think they way I'm doing it now might work as well.

[Calamity]

I'm stress testing the new one and works pretty well. No more stretching issues. Some games are far from perfect with the modes I have defined for this lcd, specially the ones that are 256 lines tall and many vertical rotated ones for the same reason: my monitor is hiding 512 lines modes, so it will go for 384 lines resulting in big borders. Of course this system is not optimal for emulation but somehow it's helping me detecting some issues that otherwise are masked when testing in my cab. I'm seeing how it would be good to also check for xres*3, yres*3 and maybe more, so here I would pick 768 lines to render 256*3 lines as a workaround. I'll have a look later at how you're doing your scoring system in case I can think something useful.

[bitbytebit]

I'm stress testing the new one and works pretty well. No more stretching issues. Some games are far from perfect with the modes I have defined for this lcd, specially the ones that are 256 lines tall and many vertical rotated ones for the same reason: my monitor is hiding 512 lines modes, so it will go for 384 lines resulting in big borders. Of course this system is not optimal for emulation but somehow it's helping me detecting some issues that otherwise are masked when testing in my cab. I'm seeing how it would be good to also check for xres*3, yres*3 and maybe more, so here I would pick 768 lines to render 256*3 lines as a workaround. I'll have a look later at how you're doing your scoring system in case I can think something useful.

Cool, yeah I've done another change that just basically allows a second pass at recalculating the modeline in the case that
the registry one was virtualized when it was calculated again if it didn't fit.  This really seems to only happen in cases like on
ntsc monitor types.  I ran into it while testing and basically it is where you get the modeline you want, find a registry modeline
that might be double or something, then recalculate that modeline with the refresh, and it virtualizes it to another resolution,
so then I go back and find that resolution from the registry or best match for it.  Seems to at least avoid the bad condition where
it's using a registry modeline with different height/width than it should be, and if it can't get the right height/width after the second
pass through the registry it gives up and just does throttling after that point.  It'll be up in a bit as 012g.

[Calamity]

This one is interesting. I think I found the issue with mk. It seems to happen only if changeres is enabled. When it's enabled, speed is 110% (although the log does not reflect that for some reason). If changeres is disabled, the modeline is properly updated and the game runs 100%. I think it has to do with the fact that after the resolution is switched, the same registry modeline is used again, and probably something goes wrong after resetting it:

SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 400x384@60
SwitchRes: [2] Resetting Custom modeline DALDTMCRTBCD400X384X0X60 to original values...
SwitchRes: Set Registry mode DALDTMCRTBCD400X384X0X60 with:
SwitchRes: (61206/61206/61206) Modeline 15.880000 400 408 472 504 384 442 444 525

...so it wouldn't be necessary to reset to the original values if the same one is going to be used again, until you actually exit, although I don't know if that would be easy to do or would break something else.

[bitbytebit]

This one is interesting. I think I found the issue with mk. It seems to happen only if changeres is enabled. When it's enabled, speed is 110% (although the log does not reflect that for some reason). If changeres is disabled, the modeline is properly updated and the game runs 100%. I think it has to do with the fact that after the resolution is switched, the same registry modeline is used again, and probably something goes wrong after resetting it:

SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 400x384@60
SwitchRes: [2] Resetting Custom modeline DALDTMCRTBCD400X384X0X60 to original values...
SwitchRes: Set Registry mode DALDTMCRTBCD400X384X0X60 with:
SwitchRes: (61206/61206/61206) Modeline 15.880000 400 408 472 504 384 442 444 525

...so it wouldn't be necessary to reset to the original values if the same one is going to be used again, until you actually exit, although I don't know if that would be easy to do or would break something else.

Ah interesting, I had actually thought about if that were a possibility and to avoid switching if the outcome resolution is the same anyways.  I'll have to actually figure out how to change that to work right in that case, and just not do the switch since it is already the best it can do.

[bitbytebit]

This one is interesting. I think I found the issue with mk. It seems to happen only if changeres is enabled. When it's enabled, speed is 110% (although the log does not reflect that for some reason). If changeres is disabled, the modeline is properly updated and the game runs 100%. I think it has to do with the fact that after the resolution is switched, the same registry modeline is used again, and probably something goes wrong after resetting it:

SwitchRes: Setting Option -waitvsync
SwitchRes: Setting Option -resolution 400x384@60
SwitchRes: [2] Resetting Custom modeline DALDTMCRTBCD400X384X0X60 to original values...
SwitchRes: Set Registry mode DALDTMCRTBCD400X384X0X60 with:
SwitchRes: (61206/61206/61206) Modeline 15.880000 400 408 472 504 384 442 444 525

...so it wouldn't be necessary to reset to the original values if the same one is going to be used again, until you actually exit, although I don't know if that would be easy to do or would break something else.

Ah interesting, I had actually thought about if that were a possibility and to avoid switching if the outcome resolution is the same anyways.  I'll have to actually figure out how to change that to work right in that case, and just not do the switch since it is already the best it can do.

I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

[Calamity]

I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.

[bitbytebit]

I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.

I changed the scoring system, the part finding the best score after they were all scored, split it up into categories so hopefully now the system resolutions and interlaced ones are put into lower priority unless no custom ones exist that were scored at all.  I think this will fix that issue, I still need to look at keepaspect some since I should probably set it sometimes when it isn't getting set.  Version 012h will have this fix, should have builds up soon. Definitely a bit tricky getting the scoring right for having the custom/system modes and then looking at them differently if interlaced, but what I've done now might make it work right in most cases.

Update: Just made a change, trying to set keepaspect when the width isn't the desired resolution like a doubled one with vertical games.

[Calamity]

I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.

I changed the scoring system, the part finding the best score after they were all scored, split it up into categories so hopefully now the system resolutions and interlaced ones are put into lower priority unless no custom ones exist that were scored at all.  I think this will fix that issue, I still need to look at keepaspect some since I should probably set it sometimes when it isn't getting set.  Version 012h will have this fix, should have builds up soon. Definitely a bit tricky getting the scoring right for having the custom/system modes and then looking at them differently if interlaced, but what I've done now might make it work right in most cases.

Update: Just made a change, trying to set keepaspect when the width isn't the desired resolution like a doubled one with vertical games.

Will test that later. However, just to make sure, the issue with gtmr is, rather than using a system video mode (that is a bad thing), is that it *creates* a new DAL... registry entry that does not exist at first hand, so after that I need to manually edit the registry to remove it.

[bitbytebit]

I uploaded a new build, same version number.  I hopefully fixed it, so that now it will not re-modify a modeline and just skip the rewrite of it, and then be able to reset it properly at the end too again.

This new version fixes mk issue and everything else works fine  

Please have a look at gtmr log, there's a bug because it's using a system video mode thinking its a custom one and so editing the registry when it shouldn't.

There's also a problem with Capcom games when using doubled resolutions, but it's not Switchres related, rather it seems internal to the ddraw routines. The right mode 768x224 is selected for 384x224 but the frame is not scaled for some reason. It's interesting because this doesn't happen on my other system (lcd). The logs look ok (ghouls.txt). Of course this doesn't happen either if a 384x224 modeline exists, but it's interesting because it seems a exception. Maybe some other systems/resolutions are affected but this is the only one I've found.

I've checked that -keepaspect is necessary for non-virtualized rotated vertical games, like pacman, when we're using a doubled resolution. I don't know if that would have any side effect on the Linux side, here it looks innocuous.

I changed the scoring system, the part finding the best score after they were all scored, split it up into categories so hopefully now the system resolutions and interlaced ones are put into lower priority unless no custom ones exist that were scored at all.  I think this will fix that issue, I still need to look at keepaspect some since I should probably set it sometimes when it isn't getting set.  Version 012h will have this fix, should have builds up soon. Definitely a bit tricky getting the scoring right for having the custom/system modes and then looking at them differently if interlaced, but what I've done now might make it work right in most cases.

Update: Just made a change, trying to set keepaspect when the width isn't the desired resolution like a doubled one with vertical games.

Will test that later. However, just to make sure, the issue with gtmr is, rather than using a system video mode (that is a bad thing), is that it *creates* a new DAL... registry entry that does not exist at first hand, so after that I need to manually edit the registry to remove it.

Yeah hopefully I fixed that since that version, at least now should not be possible to write what wasn't a custom modeline, will see.  In 012i 012j I've possibly really fixed the keepaspect issue, was checking after instead of before I should have for that.  Also have the output a bit better so should be more easy to see if it's writing, and which modelines are system by the labels now.  I'm re-uploading 012i 012j right now actually, so make sure it's timestamped after this post .  Should be a couple minutes before it's done.

[Calamity]

This new version is working great. The pick best mode function does it's job pretty well, I still need to test more to find problems if there are any. Vertical games with -keepaspect now look good with doubled resolutions.

The only feature I somehow miss is that when a given resolution is selected from command line it would actually be used for modeline calculation bypassing the pick best mode function. In fact, the resolution specified from command line is actually used later by direct draw, so the modified modeline is not used anyway. This would be very handy for testing purposes.

I still have the issue with games using 384x224 -> 768x224 (does not scale xres*2). It's interesting because 384x240 -> 768x240 works fine. I'm thinking it could be related to a possible aspect ratio check done somewhere in the ddraw side. It's a shame because it's the only problem I'm seeing with this doubled resolutions system. I'm interested in fixing this as it could be a possible way of reducing the needed modetable a lot. There's an additional benefit when doubling resolutions: we have a finer granularity both for dotclocks and porches, so at least in theory we could get more accurate refresh rates and differences in centering between modes would be smaller.

For anyone is following this thread, I would like to make clear that these issues don't happen if we install a normal mode table, so all this has been working fine for some time already. It's just that we are trying to make it more versatile for using special experimental mode tables, like the ones with doubled resolutions. So don't get discouraged to use it just because I keep reporting problems everyday

[bitbytebit]

This new version is working great. The pick best mode function does it's job pretty well, I still need to test more to find problems if there are any. Vertical games with -keepaspect now look good with doubled resolutions.

The only feature I somehow miss is that when a given resolution is selected from command line it would actually be used for modeline calculation bypassing the pick best mode function. In fact, the resolution specified from command line is actually used later by direct draw, so the modified modeline is not used anyway. This would be very handy for testing purposes.

I still have the issue with games using 384x224 -> 768x224 (does not scale xres*2). It's interesting because 384x240 -> 768x240 works fine. I'm thinking it could be related to a possible aspect ratio check done somewhere in the ddraw side. It's a shame because it's the only problem I'm seeing with this doubled resolutions system. I'm interested in fixing this as it could be a possible way of reducing the needed modetable a lot. There's an additional option when doubling resolutions: we have a finer granularity both for dotclocks and porches, so at least in theory we could get more accurate refresh rates and differences in centering between modes would be smaller.

For anyone is following this thread, I would like to make clear that these issues don't happen if we install a normal mode table, so all this has been working fine for some time already. It's just that we are trying to make it more versatile for using special experimental mode tables, like the ones with doubled resolutions. So don't get discouraged to use it just because I keep reporting problems everyday

Cool, yeah I was hoping I finally got the scoring system working right or at least close, was worried after seeing the last issue and rewriting the way to compare system/interlaced/custom ones properly. 

Isn't the input though possibly forced by doing -resolution args or a .ini file one, either should force it to what you want to be used for the game.  I'm not sure if that's exactly going to fit, but guessing it should essentially do the same thing (unless there's bugs in that vs. the scoring/modeline enumeration code).

Hopefully we get some results from ArcadeVGA3000 testing, I'm really curious how that works, since this should really be able to interact with that card as much as possible and choose it's internal resolutions dynamically instead of using .ini files.  Also I'm curious what the actual output of the resolutions from the enumeration looks like, would help know if there's any improvements that could still be made. 

Also there's the question still of how to properly allow overriding the throttling when using system modes, how to really know if the refresh rate is correct (like with the ArcadeVGA3000).  If there's no way built into the system at all, and we just blindly hope it's a good refresh to use vsync, a manual command/.ini file option seems awful painful to require since a user has to go through each game and decide or setup the ArcadePerfect utility (still wish that utility could be automated, seems like it could automatically be made to tweak the refresh rate, it should know what the game uses from mame, or we could tell it).  Also like the ArcadePerfect utility, I'm guessing the PowerStrip refresh rate change API call might be interesting with system resolutions, and then we'd mostly work with any card that PowerStrip supported and users could add custom resolutions through powerstrip if they needed, and we would just change the refresh rate with it.  Otherwise I don't see a way to use system resolutions without throttling, or actually triplebuffer I guess.  By the way, what settings are needed to have nothrottle and triple buffer, is it really that triplebuffer takes care of it without vsync?  I'm wondering because I was testing and I swear it had issues with triplebuffer without throttle or vsync, still ran full speed instead of proper speed, but it might just be my system I was testing on.

[Calamity]

Isn't the input though possibly forced by doing -resolution args or a .ini file one, either should force it to what you want to be used for the game.  I'm not sure if that's exactly going to fit, but guessing it should essentially do the same thing (unless there's bugs in that vs. the scoring/modeline enumeration code).

Yes, it listens the -resolution args and directdraw uses that resolution, but the modeline calculator still recalculates the one chosen by the pick best mode function, so the recalculated modeline is never used. It's not important anyway, just could be nice if the modeline calculator tried to use the resolution I pass, very useful at least in this testing phase, to compare with its own decisions and other situations when it'd become handy. I'm guessing it would require additional checks to make sure we pass a reasonable resolution, so I would leave it as it is by now.

Also there's the question still of how to properly allow overriding the throttling when using system modes, how to really know if the refresh rate is correct (like with the ArcadeVGA3000).  If there's no way built into the system at all, and we just blindly hope it's a good refresh to use vsync, a manual command/.ini file option seems awful painful to require since a user has to go through each game and decide or setup the ArcadePerfect utility (still wish that utility could be automated, seems like it could automatically be made to tweak the refresh rate, it should know what the game uses from mame, or we could tell it).  Also like the ArcadePerfect utility, I'm guessing the PowerStrip refresh rate change API call might be interesting with system resolutions, and then we'd mostly work with any card that PowerStrip supported and users could add custom resolutions through powerstrip if they needed, and we would just change the refresh rate with it.  Otherwise I don't see a way to use system resolutions without throttling, or actually triplebuffer I guess.  By the way, what settings are needed to have nothrottle and triple buffer, is it really that triplebuffer takes care of it without vsync?  I'm wondering because I was testing and I swear it had issues with triplebuffer without throttle or vsync, still ran full speed instead of proper speed, but it might just be my system I was testing on.

Yes it's the classical problem with the programs that have tried to do this before like Mame Res Tool and AVres. I think that if I had an ArcadeVGA3000 I'd like GroovyMame to have an option to "always force vsync", even if some games where slowed/accelerated, but at least avoid tearing and run smooth. Then launching GroovyMame from ArcadePerfect and press f-11 and if it's not 100%, tweak the mode from there so the next time it'll run fine. At least that's how that's intended to be used. Then if you disable that "always force vsync" option, it would use the normal throttling scheme in case we where too far from the theoric vfreq, and so bear with tearing.

Enabling triplebuffer in this suboptimal situation will remove tearing but produce scroll hiccups. Tripebuffer does wait for vsync on its own, so it get's in the middle of throttle. IMHO I see no benefit in using triplebuffer. Anyway, I think it was running full speed in your case because we didn't add it to the multithreading patch, here (winwindow_video_window_update):

+            if ((video_config.waitvsync || video_config.syncrefresh) && video_config.mode != VIDEO_MODE_GDI)

Yes, being able to drive PowerStrip from GroovyMame could be the ultimate solution for any card. The possibilities are great. This is an old post but shows some amazing use of PowerStrip's api.

http://forum.doom9.org/archive/index.php/t-73874.html

[MonkeyJug]

I don't know if it's really still supported, I'm hoping it is, but in Linux seems that adding Composite and possibly either +CSync or -CSync to the modeline enables composite sync.  I'll look into if that really is a valid option still.

I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

At the minute, i'm forced to run the vga via the jpac (jumpered both 15&31), but this is defeating the whole purpose of having a tri-sync monitor...

[Calamity]

I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

At the minute, i'm forced to run the vga via the jpac (jumpered both 15&31), but this is defeating the whole purpose of having a tri-sync monitor...

Hi MonkeyJug, I've been having a look at your monitor's manual, it's interesting as it claims to accept negative/positive and separate/composite sync, so in theory it should be syncing with the separate sync signal in Linux. You may have tested this already, but would be interesting to try using positive vsync polarity instead of the negative by default, to see if that makes any difference. Yo can do that by adding a custom monitor_specs line in GroovyMame.ini, like this one:

monitor_specs 15625-16200,50-60,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288,448

hsync / vsync polarities are the zero values by the end of the line, second zero is vsync, turn that to 1 and test with that.

(by doing this you will actually use a single hfreq range, so multisync capabilities will not be used but in case that works then it will be possible to fix your monitor definition).
 

[bitbytebit]

I don't know if it's really still supported, I'm hoping it is, but in Linux seems that adding Composite and possibly either +CSync or -CSync to the modeline enables composite sync.  I'll look into if that really is a valid option still.

I'd be most grateful if you could at least find the time to look into this, as i am at my wits end trying to get the vertical roll to hold properly.

At the minute, i'm forced to run the vga via the jpac (jumpered both 15&31), but this is defeating the whole purpose of having a tri-sync monitor...

I'm thinking this is the best option, I've been looking into the composite sync in Linux and so far I really don't see that it can work there with the +CSync option.  From my tests that option doesn't seem to do anything, and from researching people seem to have found the same conclusion.  So hopefully changing the positive values like Calamity is saying will work, and then can setup a monitor definition with those. 

[newmanfamilyvlogs]

When an ATI Driver crashes and it does the "VPU Recovery" thing after a driver crash it essentially re-loads the drivers, right? Does it re-enumerate available video modes from the registry when it does?

If that's the case I wonder if it would be possible to invoke that action on purpose and add/remove modelines at run time instead of only altering existing modes....

[Calamity]

When an ATI Driver crashes and it does the "VPU Recovery" thing after a driver crash it essentially re-loads the drivers, right? Does it re-enumerate available video modes from the registry when it does?

If that's the case I wonder if it would be possible to invoke that action on purpose and add/remove modelines at run time instead of only altering existing modes....

There is a way to dynamically reload video drivers, explained here:

http://msdn.microsoft.com/en-us/library/ff568527%28v=vs.85%29.aspx

I did some testing with that method and unfortunately it doesn't re-enumerate video modes. So I understand that is Windows itself the one which polls the video driver for available video modes during system startup, and it doesn't repeat that operation even if the driver is reloaded later. If that's the case (I can just analize evidence, there's no documentation about this that I have found), then we should actually hack Windows itself to do what we want.

[newmanfamilyvlogs]

That list still has to reside somewhere, and I'd bet it's in the registry and not just in ram..