Switchres: modeline generator engine

[bitbytebit]

bitbytebit,

today i bought all the required parts to build a new pc to install inside my cab.  presently, it is being co-used with my main pc, so i'm now ready to hard-install it inside the cab.

i like the fact that the linux version runs pretty much ootb and is currently running better than in windows, so i''m going to attempt to install it in my cab innards.

is there a guide to getting it all setup and running, with the pre-installed front end?

It mostly should be automatic if you have an empty non partitioned drive and choose the Install option on the menu.  Looking to make it as easy as possible, but of course it'll take time so any feedback will help get closer to that goal.
sorry to be a pain, mate...

[/quote]

[MonkeyJug]

my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?

[bitbytebit]

my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?

If you choose it as the Roms/Snaps drive whenthe install asks, it should be able to see it.  If not then we can figure out any remaining issues there.  I made changes that should allow it, not sure if it's been tested, but really it should be somewhat seamless since linux can easily mount ntfs read only, you just won't be able to write to it in linux.

[Calamity]

Just another question, I've seen you moved all the monitor values setup for switchres/groovymame into the code itself, so no longer have a switchres.conf file, etc. I'd like to use your values for different monitors in VMMaker, so I can add support for multisync monitors. The idea is that needed resolutions are monitor depending, as in some circunstances GroovyMame will use different resolutions for different monitors, being vertical games the most obvious case, so for instance twincobr will use 576x320 or something like that if set up for D9800, while with my H9110 it will use 720x560 (virtualized). So the prefixed mode table will be different for each monitor case, and for best experience the mode table VMMaker creates and GroovyMame expects should be perfectly synced. So, back to the config thing, I need to add those monitor ranges to my ini file, but maybe it's more convenient to have them built in my code like you do now and leave the ini params for a single custom mode, with four lines for each range, as the format you used to have in switchres.conf, so people can experiment to find the best values for their monitors and eventually add them to the project as built in ones. Having all values in a line is somewhat confusing but as I intend to have a graphical interface in future versions then it will be good to have it like that and maybe use the same format in GroovyMame so it can read the monitor info produced with VMMaker. I'd need to clone your modeline weighting system too so I'm able to guess which range will be used by GroovyMame in order to have the right modeline ready.

EDIT: I remember you had to set sync polarities to 1 for some of your ranges, now it seems they're all 0, but for the multi and vga cases. I'm wondering if this is actually tested for these cases or maybe guessed. In Windows, we'd need to use an extra registry key to account for polarities different to the default negative case, I'd like to think it's not really needed but just wondering.

[bitbytebit]

Just another question, I've seen you moved all the monitor values setup for switchres/groovymame into the code itself, so no longer have a switchres.conf file, etc. I'd like to use your values for different monitors in VMMaker, so I can add support for multisync monitors. The idea is that needed resolutions are monitor depending, as in some circunstances GroovyMame will use different resolutions for different monitors, being vertical games the most obvious case, so for instance twincobr will use 576x320 or something like that if set up for D9800, while with my H9110 it will use 720x560 (virtualized). So the prefixed mode table will be different for each monitor case, and for best experience the mode table VMMaker creates and GroovyMame expects should be perfectly synced. So, back to the config thing, I need to add those monitor ranges to my ini file, but maybe it's more convenient to have them built in my code like you do now and leave the ini params for a single custom mode, with four lines for each range, as the format you used to have in switchres.conf, so people can experiment to find the best values for their monitors and eventually add them to the project as built in ones. Having all values in a line is somewhat confusing but as I intend to have a graphical interface in future versions then it will be good to have it like that and maybe use the same format in GroovyMame so it can read the monitor info produced with VMMaker. I'd need to clone your modeline weighting system too so I'm able to guess which range will be used by GroovyMame in order to have the right modeline ready.

EDIT: I remember you had to set sync polarities to 1 for some of your ranges, now it seems they're all 0, but for the multi and vga cases. I'm wondering if this is actually tested for these cases or maybe guessed. In Windows, we'd need to use an extra registry key to account for polarities different to the default negative case, I'd like to think it's not really needed but just wondering.

 

Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy .  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

Basically all the default modelines are all in src/emu/switchres/monitor.c and the weight system in the src/emu/switchres/modeline.c files, sounds good to have the same convention for VMMaker too.

[Calamity]

Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy .  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

TV screen users are reporting problems with prefixed settings, mainly overscan or picture shifted to the right and stuff. In the cases where the problem is common to all modes, then one can easily edit the back porch value for instance and fix all modes with that. Arcade monitors are much more flexible in this area it seems.

[bitbytebit]

Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy .  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

TV screen users are reporting problems with prefixed settings, mainly overscan or picture shifted to the right and stuff. In the cases where the problem is common to all modes, then one can easily edit the back porch value for instance and fix all modes with that. Arcade monitors are much more flexible in this area it seems.

Yeah I'm guessing the settings for NTSC/PAL are wrong, if we can get those right probably will fix that, or does that really differ among each TV?  I need to put that configuration option in so people can find the good values, then report them back to us and we can use those from now on.  Probably will do that this weekend and have a new ISO possibly Sunday night I hope, and new groovymame build for Windows with the change. 

[MonkeyJug]

my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?

If you choose it as the Roms/Snaps drive whenthe install asks, it should be able to see it.  If not then we can figure out any remaining issues there.  I made changes that should allow it, not sure if it's been tested, but really it should be somewhat seamless since linux can easily mount ntfs read only, you just won't be able to write to it in linux.

ok, i've tried this via several different methods.  it keeps saying 'no drives are available to use' when i try and point it at my roms folder (on an ntfs drive).

when it comes to installing on the hard drive, it can see the other drive, but it can't see it when it comes to pointing to it regarding the roms folder.

i have tried two separate partitions on the same drive, and two separate hard drives, both give the same results...

[bitbytebit]

my roms currently reside on a windows formatted (ntfs) drive.  if i point the linux install to this folder (when asked for the snap/roms folder), will linux be able to see it?

If you choose it as the Roms/Snaps drive whenthe install asks, it should be able to see it.  If not then we can figure out any remaining issues there.  I made changes that should allow it, not sure if it's been tested, but really it should be somewhat seamless since linux can easily mount ntfs read only, you just won't be able to write to it in linux.

ok, i've tried this via several different methods.  it keeps saying 'no drives are available to use' when i try and point it at my roms folder (on an ntfs drive).

when it comes to installing on the hard drive, it can see the other drive, but it can't see it when it comes to pointing to it regarding the roms folder.

i have tried two separate partitions on the same drive, and two separate hard drives, both give the same results...

Ah ok, I just hopefully fixed that bug, see now I had been checking for only Linux type partitions in the Data/Roms disk listing.  I'll have new ISO's out sometime this weekend with the fix.

Thanks for helping figure that out, one of the things I forgot to change when trying to make any type of partition type work for the Data/Roms drive.

The other way to do this for now, till it's in the ISO, is browse to the http://system.ip/ interface, login as 'admin' with pwd of 'arcade' and map the drive that way to the /home/roms/ folder on the system.  Make sure you tell it to set the permissions on the drive to allow the arcade user to read it too.

[bitbytebit]

Yeah, basically groovymame just doesn't have the config option to read new ranges into it, yet, I still need to do that, it actually won't be too hard but I've been lazy .  Also figured it's less needed, but if lots of people are wanting it now then I can get it done pretty soon.

TV screen users are reporting problems with prefixed settings, mainly overscan or picture shifted to the right and stuff. In the cases where the problem is common to all modes, then one can easily edit the back porch value for instance and fix all modes with that. Arcade monitors are much more flexible in this area it seems.

I just added the custom monitor config option into groovymame, it's -monitor_specs <> with the same syntax as in switchres.  The main difference is that it can only be setup for one range, since in mame I can't give a parameter multiple times and have it store it as an array.  That should be ok though, since right now mostly to fiddle around with the TV settings and more likely a monitor has one range than many, else they are covered already or should be a special case and added in.  I have new builds as 011d for this, possibly you could test it and then have the people with the TV issues try some changes in the front porches and other values to see if things can use better values.  Just use switchres to figure out what the current default settings are for NTSC and PAL, it'll print them out in verbose mode, and work off of those outputs.

[MonkeyJug]

bitbytebit,  one other issue i noticed last night - when it comes to installing onto the hard drive, it doesn't recognise a separate partition on the drive, but instead only sees the whole drive, and if there is something already on it, ie. my mame roms on a separate partition, it won't install onto (see) the unpartitioned space...

eg.  i have a 320gb drive, first partition is 50gb, unpartitioned, and the second partition is 250gb, which contains my roms folder (formatted ntfs).

when i choose to install to hard disk, it sees only the 320gb partition, but is unable to install to the first unparitioned space, because the 'partition is not empty', or words to that effect...

maybe you can look into this too...

regards

[bitbytebit]

bitbytebit,  one other issue i noticed last night - when it comes to installing onto the hard drive, it doesn't recognise a separate partition on the drive, but instead only sees the whole drive, and if there is something already on it, ie. my mame roms on a separate partition, it won't install onto (see) the unpartitioned space...

eg.  i have a 320gb drive, first partition is 50gb, unpartitioned, and the second partition is 250gb, which contains my roms folder (formatted ntfs).

when i choose to install to hard disk, it sees only the 320gb partition, but is unable to install to the first unparitioned space, because the 'partition is not empty', or words to that effect...

maybe you can look into this too...

regards

Yeah that's currently a limitation of how I've done the automatic partitioning, since it becomes a bit more complicated when the drive isn't clean since we then have to move around the partition numbers and may not be able to get the first one for the /boot partition and then grub installation becomes a bit trickier too.  I've been thinking of ways to automate that, but right now it's more of a manual partition task which of course then runs into requiring the knowledge of how to partition the drives.  So I'll get that ability hopefully soon, but it's kind of the next step since It'll change around how I do things somewhat and there are a few issues to figure out there.

Good news is I have ISO's uploading with the NTFS fix, hopefully I got it working now, I at least removed the part that ignores them on the partition search and it shouldn't say no drives available anymore.  Should be done uploading hopefully in a few hours, will post when they are done.

[bitbytebit]

This should hopefully allow NTFS drives to be used now for Roms/Snaps, report any issues if there's remaining bugs.  Monitor specs are now able to be customized, but you'll need to know the right format from switchres to pass to the new -monitor_specs option in groovymame...

02042011 - 1.546 Release
         - Added new option to groovymame named -monitor_specs that takes switchres monitor specs format
         - Now NTFS drives really should allow being used as the Roms/Snap folder
         - fixes for xorg.conf generation when lspci shows other interfaces with VGA in them
         - cwiid controller fixes
         - Really prevent extra setup on install if already done

[MonkeyJug]

just a quick question.  it now sees the ntfs when enquiring about the roms location, but it then said it coulnd't find any matched roms once it rebooted and at the front end...

do the roms have to be on the root of the partition?  presently, they are inside mame\roms...

[bitbytebit]

just a quick question.  it now sees the ntfs when enquiring about the roms location, but it then said it coulnd't find any matched roms once it rebooted and at the front end...

do the roms have to be on the root of the partition?  presently, they are inside mame\roms...

You'll have to edit the Advance Menu config (in the System Setup menu) and point to the roms locations.  The drive is mounted as /home/roms/ so from there where the exist on the NTFS drive they will be something like /home/roms/Mame/roms or something similar. 

[MonkeyJug]

making slow progress...

got the folder structure sorted thanks to your last post, but now i have a new, unrelated problem...

i have a tri-sync monitor, but when i select d9200 or d9800, the front end is displayed in a split screen.  the roms seem to launch ok and most of them sync up and run fine...

when i select h9110 from the video setup, the front end displays normally, full screen, but when i flick between different games, it sometimes has problems re-syncing back at the front end, and then some games have problems syncing when launched.  randomly, if i escape back to the front end, sometimes it syncs, sometimes it doesn't, and likewise, when i launch a game, sometimes it syncs up and sometimes it doesn't...  but if i remove the vga from the j-pac and re-connect it, it re-syncs itself...

also, completely unrelated - the controls for player 1 don't seem right.  i haven't adjusted anything here, but 'up' doesn't respond, and when i launch a game, left doesn't work.  i had a look in the general controls within mame, and it seems to be setup correctly...

i haven't touched my controls at all, which is why i'm baffled...

edit:  ignore the control problems... i went into universal controls and even though they were set to up, down, left, right, there was also a joy1, 2, 3, 4 in there.  i reset them to only up, down, left, right and now all is working control-wise...

[Calamity]

I just added the custom monitor config option into groovymame, it's -monitor_specs <> with the same syntax as in switchres.  The main difference is that it can only be setup for one range, since in mame I can't give a parameter multiple times and have it store it as an array.  That should be ok though, since right now mostly to fiddle around with the TV settings and more likely a monitor has one range than many, else they are covered already or should be a special case and added in.  I have new builds as 011d for this, possibly you could test it and then have the people with the TV issues try some changes in the front porches and other values to see if things can use better values.  Just use switchres to figure out what the current default settings are for NTSC and PAL, it'll print them out in verbose mode, and work off of those outputs.

GREAT, testing that in a minute. So the format you're using is the same as in Switchres:

# HfreqMin-HfreqMax,VrefMin-VrefMax,HFP,HSP,HBP,VFP,VSP,VBP,HPol,VPol,ActiveLinesLimit,VirtualLinesLimit
#
# CGA Monitor
#MonitorLimits 15750-15750,55-60,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288,448

...so -monitor_specs <15750-15750,55-60,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288,448>

[newmanfamilyvlogs]

the monitor value section sounds awesome. will it select 2x scaled modes correctly?

[Calamity]

when i select h9110 from the video setup, the front end displays normally, full screen, but when i flick between different games, it sometimes has problems re-syncing back at the front end, and then some games have problems syncing when launched.  randomly, if i escape back to the front end, sometimes it syncs, sometimes it doesn't, and likewise, when i launch a game, sometimes it syncs up and sometimes it doesn't...  but if i remove the vga from the j-pac and re-connect it, it re-syncs itself...

That's actually a problem with your j-pac board itself, I have similar issue with one of my j-pacs here, although lately it seems it has cured itself from that, sometimes it starts doing that for a while and it's annoying. I guess the problem has to do with the voltage on the usb it uses as power supply, if I remove the usb and switch it again then it resyncs perfectly.

the monitor value section sounds awesome. will it select 2x scaled modes correctly?

Well not yet actually, that only accounts for monitor timings, to do what you need GroovyMame must be specifically instructed to do so, either by manually making an ini for each game or modifying the pick_best_mode function in the code and adding an option for that case.

[kevinp]

Guys,

This is simply fantastic stuff!!  Calamity's driver and Groovymame have alleviated so many of the issues I have been fighting for years on mameing arcade monitors.  No more stuttering and a huge reduction in adjusting VSize and Vhold between roms.  Thank you so much for your efforts!

[newmanfamilyvlogs]

the monitor value section sounds awesome. will it select 2x scaled modes correctly?

Well not yet actually, that only accounts for monitor timings, to do what you need GroovyMame must be specifically instructed to do so, either by manually making an ini for each game or modifying the pick_best_mode function in the code and adding an option for that case.

By 'it', I did mean GroovyMame in general, not the new monitor values section, though looking back I realize that's not what it looks like.

Bitbytebit: Are you planning on implementing this?

[bitbytebit]

the monitor value section sounds awesome. will it select 2x scaled modes correctly?

Well not yet actually, that only accounts for monitor timings, to do what you need GroovyMame must be specifically instructed to do so, either by manually making an ini for each game or modifying the pick_best_mode function in the code and adding an option for that case.

By 'it', I did mean GroovyMame in general, not the new monitor values section, though looking back I realize that's not what it looks like.

Bitbytebit: Are you planning on implementing this?

Yeah I am, I have just about gotten 0142 ready, which took a bit of work completely redoing the patches. 

Now that's looking ready, I plan on doing this next.  So basically when doublescan is necessary, instead we just double the height and width, and no settings in mame are needed changing?  Then it'll just do the work at making the output fit?  Want to get more clear on the necessary changes, if it's just simply replacing doublescan with double height width, that's probably pretty easy.

[Calamity]

So basically when doublescan is necessary, instead we just double the height and width, and no settings in mame are needed changing?  Then it'll just do the work at making the output fit?  Want to get more clear on the necessary changes, if it's just simply replacing doublescan with double height width, that's probably pretty easy.

In my tests I just doubled one of the dimensions, for instance, for 320x224, I know that if you select 320x448 or 640x224 Mame will scale it automatically without any pain, so I understand that doubling both dimensions will also work.

In theory for 31Khz monitors we'd only need double yres in order to achieve the fake doublescan we need, that would be my preferred approach if you ask me, but I know people will prefer to double both dimensions to have 4:3 resolutions, just for having better looking fonts and stuff like that.

EDIT: Maybe could be good to check for either double xres and yres too, it would help users of some ATI families in Windows, like HD3000, that are known to not accept low dotclocks. For those cases, I've enabled a "DotclockMin" option in VMMaker that just doubles xres in case it's needed, leaving yres unmodified (this is necessary for lowres arcade monitors).

[bitbytebit]

So basically when doublescan is necessary, instead we just double the height and width, and no settings in mame are needed changing?  Then it'll just do the work at making the output fit?  Want to get more clear on the necessary changes, if it's just simply replacing doublescan with double height width, that's probably pretty easy.

In my tests I just doubled one of the dimensions, for instance, for 320x224, I know that if you select 320x448 or 640x224 Mame will scale it automatically without any pain, so I understand that doubling both dimensions will also work.

In theory for 31Khz monitors we'd only need double yres in order to achieve the fake doublescan we need, that would be my preferred approach if you ask me, but I know people will prefer to double both dimensions to have 4:3 resolutions, just for having better looking fonts and stuff like that.

EDIT: Maybe could be good to check for either double xres and yres too, it would help users of some ATI families in Windows, like HD3000, that are known to not accept low dotclocks. For those cases, I've enabled a "DotclockMin" option in VMMaker that just doubles xres in case it's needed, leaving yres unmodified (this is necessary for lowres arcade monitors).

Something I just realized, in Windows should I turn off doublescan calculation then, does it ever even work and if so isn't the modeline registry entry require something different (from what I can tell, there isn't a flag for that anyways). 

[Calamity]

Something I just realized, in Windows should I turn off doublescan calculation then, does it ever even work and if so isn't the modeline registry entry require something different (from what I can tell, there isn't a flag for that anyways). 

Yes, we don't have doublescan support for ATI cards in Windows unfortunately, so better have it disabled

I believe doublescan actually worked at some point in the past. There's actually a documented flag for that but it doesn't work any more. Instead, Catalyst drivers were badly hardcoded to enable doublescan just for 320x and 400x modes, and I'm pretty sure that was what broke generic doublescan support. Something I always do when I patch Catalyst drivers is to disable that behaviour by modifying the points where those checks are done. This is needed in order to allow normal 320x224 and such resolutions without doublescan (notice that ArcadeVGA drivers don't have this patch, that's why those cards use resolutions defined as 321x and 401x to avoid doublescan and these have become so popular).

Actually, there's one way I could restore doublescan support in ATI drivers, but to be honest I don't know if I want to go through the pain involved. If I modified the original hardcoded checks for 320x and 400x resolutions, and made them check for the least significant bit of xres instead, then we could have double scan for resolutions with odd xres, so in case we wanted 320x224 doublescanned we would define it as 321x224. The problem is that it would break the logic I have for "labels" when using static modelists, so maybe that would cause more problems than benefits, and after all doublescan can be easily faked by doubling yres.

[bitbytebit]

Something I just realized, in Windows should I turn off doublescan calculation then, does it ever even work and if so isn't the modeline registry entry require something different (from what I can tell, there isn't a flag for that anyways). 

Yes, we don't have doublescan support for ATI cards in Windows unfortunately, so better have it disabled

I believe doublescan actually worked at some point in the past. There's actually a documented flag for that but it doesn't work any more. Instead, Catalyst drivers were badly hardcoded to enable doublescan just for 320x and 400x modes, and I'm pretty sure that was what broke generic doublescan support. Something I always do when I patch Catalyst drivers is to disable that behaviour by modifying the points where those checks are done. This is needed in order to allow normal 320x224 and such resolutions without doublescan (notice that ArcadeVGA drivers don't have this patch, that's why those cards use resolutions defined as 321x and 401x to avoid doublescan and these have become so popular).

Actually, there's one way I could restore doublescan support in ATI drivers, but to be honest I don't know if I want to go through the pain involved. If I modified the original hardcoded checks for 320x and 400x resolutions, and made them check for the least significant bit of xres instead, then we could have double scan for resolutions with odd xres, so in case we wanted 320x224 doublescanned we would define it as 321x224. The problem is that it would break the logic I have for "labels" when using static modelists, so maybe that would cause more problems than benefits, and after all doublescan can be easily faked by doubling yres.

From what I can tell it seems that we need to do double width too, else we need to use keepaspect with it using only height and I've found things don't look as good with keep aspect as getting the width right (at least for vertical games this seems true).  Is this not the case with doubling the xres, that the yres would be able to avoid being doubled, without using keepaspect.  Or for both of these cases would using keepaspect allow the other value not to need doubling?

I think I may have all these about done, lowdotclock double res and disabled doublescan in Windows, just need to make sure the aspect is still correct though.

[Calamity]

Interesting, probably I've had keepaspect on all the time (as it's necessary for virtualized modes) and just thought it was the default behaviour, it makes sense that the keepaspect is needed there. So you mean it's looking worse with keepaspect? I didn't notice that but probably you're right, or maybe the vertical games are specially affected by their rotation and Mame performs a fractional scaling there. I'll need to do more testing on this.

[bitbytebit]

Interesting, probably I've had keepaspect on all the time (as it's necessary for virtualized modes) and just thought it was the default behaviour, it makes sense that the keepaspect is needed there. So you mean it's looking worse with keepaspect? I didn't notice that but probably you're right, or maybe the vertical games are specially affected by their rotation and Mame performs a fractional scaling there. I'll need to do more testing on this.

Yeah this was one of the first things I noticed about it and especially when I was originally using my arcadeVGA card and how the instructions recommended using keepaspect.  One pacman, it squishes the numbers oddly, and are too skinny on the sides, but yet if the resolution is wider and doing the aspect ratio correctly, then it is nice.

[bitbytebit]

I updated the patch, to 012a, builds coming soon.

These are the new options:

-monitor_doublescan  Use doublescan if necessary, not available in Windows
-monitor_dotclock    Lowest dotclock videocard accepts, 0 is the default
-monitor_ymin        Minimum height to calculate, default is no minimum

basically under Windows, it automatically disables doublescan, but can be done in Linux manually if using a card that doesn't.
The dotclock option takes the lowest dotclock, like 10000000 for 10Mhz
The ymin option is there to control the minimum height, in case you want 240 minimum instead of 224, although it's really not something necessary most of the time.

I *think* the way I did this will work well, at least in testing seems to be really nice on my LCD now when disabling doublescan with the double height/width method.  Also the low dotclock does a similar thing too.  There might be some odd little bugs too that I have possibly fixed, rare I think but basically when calculating resolutions more than once I discovered by doing the dotclock change that some values like doublescan would still be set, I now completely clear the modeline structure on each re-calculation .

[Calamity]

Great, I'll test this today. So when you set the monitor_dotclock, in case the resulting initial dotclock is below that value you do xres*2?

[bitbytebit]

Great, I'll test this today. So when you set the monitor_dotclock, in case the resulting initial dotclock is below that value you do xres*2?

Yeah, and also yres because otherwise it's a squished screen, I can't see how it would work actually any other way.  I'm guessing that by doing this, on a 15khz monitor, it'll virtualize.  That probably is the most workable method I'm guessing because keepaspect doesn't seem to help in this case, and having the resolution wide like that looks pretty odd otherwise.  Check the latest git for the changes and play around with it though, if you can figure out how that can work better would be great, but it should all be there in the right places hopefully to allow us to perfect it.

[Calamity]

Yeah, and also yres because otherwise it's a squished screen, I can't see how it would work actually any other way.  I'm guessing that by doing this, on a 15khz monitor, it'll virtualize.  That probably is the most workable method I'm guessing because keepaspect doesn't seem to help in this case, and having the resolution wide like that looks pretty odd otherwise.  Check the latest git for the changes and play around with it though, if you can figure out how that can work better would be great, but it should all be there in the right places hopefully to allow us to perfect it.

I see, but if you double yres then as you say we can't use that for 15Khz monitors, and I'm nearly sure it works just with xres*2 at least for horizontal games. I'll do some testing anyway.

Check this bublbobl.log, it's interesting. I'm testing it with an lcd. The game originally uses 256x224 resolution. The first odd thing is that even if we have 512x448 available, that should be the one selected, it chooses 256x512 instead. Second, 256x512 is a registry defined modeline, but it's not available as an usable mode, probably because my lcd's edid is blocking that mode. Although this is not intended to be used with an lcd, it's good to know this and after reading registry modelines check if they've been accepted by the system and actually available.

EDIT: Just out of curiosity, here and there I see this word 'squished' used for a bad picture, but I don't get the accurate meaning of it and my dictionary is not helping with this one
EDIT2: When I say xres*2 works for me, I mean it is indistinguishable of the real thing, to the point that I'm tempted to get rid of the lower ones to do a better use of the limited space for video modes (anyway I might be wrong)

[bitbytebit]

Yeah, and also yres because otherwise it's a squished screen, I can't see how it would work actually any other way.  I'm guessing that by doing this, on a 15khz monitor, it'll virtualize.  That probably is the most workable method I'm guessing because keepaspect doesn't seem to help in this case, and having the resolution wide like that looks pretty odd otherwise.  Check the latest git for the changes and play around with it though, if you can figure out how that can work better would be great, but it should all be there in the right places hopefully to allow us to perfect it.

I see, but if you double yres then as you say we can't use that for 15Khz monitors, and I'm nearly sure it works just with xres*2 at least for horizontal games. I'll do some testing anyway.

Check this bublbobl.log, it's interesting. I'm testing it with an lcd. The game originally uses 256x224 resolution. The first odd thing is that even if we have 512x448 available, that should be the one selected, it chooses 256x512 instead. Second, 256x512 is a registry defined modeline, but it's not available as an usable mode, probably because my lcd's edid is blocking that mode. Although this is not intended to be used with an lcd, it's good to know this and after reading registry modelines check if they've been accepted by the system and actually available.

EDIT: Just out of curiosity, here and there I see this word 'squished' used for a bad picture, but I don't get the accurate meaning of it and my dictionary is not helping with this one
EDIT2: When I say xres*2 works for me, I mean it is indistinguishable of the real thing, to the point that I'm tempted to get rid of the lower ones to do a better use of the limited space for video modes (anyway I might be wrong)

Ah, I mean it basically is really wide and really short, like 32:9 aspect ratio or something, with 1/3 of the screen black above and below the picture.  It just horizontally fills the picture but vertically it's barely filling 1/3 of it right in the middle. 

[Calamity]

Ah, I mean it basically is really wide and really short, like 32:9 aspect ratio or something, with 1/3 of the screen black above and below the picture.  It just horizontally fills the picture but vertically it's barely filling 1/3 of it right in the middle. 

Ah ok, I now see what you mean, yes I've also seen that before but I think I got it working, will test it in a while.

[Calamity]

I've confirmed the xres*2 method works here, but I'm thinking it could be a DirectDraw behaviour and maybe not the same with SDL. I'm testing this with keepaspect 0. I've created a list of modelines starting from dotclock 7.5 and up, so the lowest is 360x.

goldnaxe uses 320x224, so it's supposed to use 640x224 with this setup. The interesting thing here is how DirectDraw uses the original 320x224 blit size when the resolution is below 640 (320*2) but as soon as it reaches 640x224 it automatically scales xres*2 and leaves yres unmodified:

> This one has very big borders on the sides
DirectDraw: Mode selected =  624x 288@ 54Hz
DirectDraw: primary surface created: 624x288x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 320x224

> This looks perfect, exactly as real 320x224
DirectDraw: Mode selected =  640x 224@ 60Hz
DirectDraw: primary surface created: 640x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

> This has little borders on the sides
DirectDraw: Mode selected =  672x 239@ 60Hz
DirectDraw: primary surface created: 672x239x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

I think it's just the same for vertical values.

[bitbytebit]

I've confirmed the xres*2 method works here, but I'm thinking it could be a DirectDraw behaviour and maybe not the same with SDL. I'm testing this with keepaspect 0. I've created a list of modelines starting from dotclock 7.5 and up, so the lowest is 360x.

goldnaxe uses 320x224, so it's supposed to use 640x224 with this setup. The interesting thing here is how DirectDraw uses the original 320x224 blit size when the resolution is below 640 (320*2) but as soon as it reaches 640x224 it automatically scales xres*2 and leaves yres unmodified:

> This one has very big borders on the sides
DirectDraw: Mode selected =  624x 288@ 54Hz
DirectDraw: primary surface created: 624x288x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 320x224

> This looks perfect, exactly as real 320x224
DirectDraw: Mode selected =  640x 224@ 60Hz
DirectDraw: primary surface created: 640x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

> This has little borders on the sides
DirectDraw: Mode selected =  672x 239@ 60Hz
DirectDraw: primary surface created: 672x239x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224

I think it's just the same for vertical values.

So in the height case for doublescan, is it also able to do the same thing?  Interesting, I am guessing it's a direct draw feature or something.  I'm looking at a couple possible changes, first check if SDL or driect draw and only mess with the height on this or width on no-doublescan if it's SDL.  Also looks like in the best mode function, I'm now seeing how after checking exact matches, like you've been saying, I can try double width ones too.  Should I also then after that check for double height ones with the same original width, then mabye double width + double height after that?



Update: Patch to try, which only does the aspect keeping part in SDL, not in Windows...

Code: [Select]

--- a/src/emu/switchres/modeline.c
+++ b/src/emu/switchres/modeline.c
@@ -96,7 +96,8 @@ int ModelineCreate(ConfigSettings *cs, GameInfo *game, MonitorMode *monitor, Mod
                        if (cs->verbose > 2)
                                mame_printf_verbose("SwitchRes: Double height width instead of doublescan\n");
                        mode->vactive *= 2; // Double height
-                       mode->hactive *= 2; // Double width
+                       if (cs->keepaspect)
+                               mode->hactive *= 2; // Double width
                        mode->result |= RESULT_DOUBLERES;
                } else {
                         double num, den;
diff --git a/src/emu/switchres/switchres.c b/src/emu/switchres/switchres.c
index 05dc1ba..589286f 100644
--- a/src/emu/switchres/switchres.c
+++ b/src/emu/switchres/switchres.c
@@ -203,7 +203,8 @@ void calc_modeline(running_machine &machine)
                if (modeLine->pclock < cs->dotclockmin) {
                        mame_printf_verbose("SwitchRes: Dotclock too low, doubling horizontal size\n");
                        gameInfo->width *= 2;
-                       gameInfo->height *= 2;
+                       if (cs->keepaspect)
+                               gameInfo->height *= 2;
 
                        ModelineCreate(cs, gameInfo, switchRes->monitorMode, &switchRes->monitorMode->modeLine);
                        switchRes->monitorMode->modeLine.result |= RESULT_LOWDOTCLOCK;
diff --git a/src/emu/switchres/switchres.h b/src/emu/switchres/switchres.h
index cb1145a..550b2a9 100644
--- a/src/emu/switchres/switchres.h
+++ b/src/emu/switchres/switchres.h
@@ -50,6 +50,7 @@ typedef struct ConfigSettings {
        int    cleanstretch;
        int    soundsync;
        int    changeres;
+       int    keepaspect;
 } ConfigSettings;
 
 typedef struct ModeLine {
diff --git a/src/osd/sdl/switchres.c b/src/osd/sdl/switchres.c
index 9367aad..77882ef 100644
--- a/src/osd/sdl/switchres.c
+++ b/src/osd/sdl/switchres.c
@@ -105,6 +105,7 @@ bool switchres_modeline_setup(running_machine &machine)
        // Get .ini resolution if any
        if (!machine.switchRes.resolution.count) {
                strcpy(machine.switchRes.gameInfo.resolution, options.resolution());
+               machine.switchRes.cs.keepaspect = 1;
        }
 
        // Get connector name



[Calamity]

So in the height case for doublescan, is it also able to do the same thing?  Interesting, I am guessing it's a direct draw feature or something.  I'm looking at a couple possible changes, first check if SDL or driect draw and only mess with the height on this or width on no-doublescan if it's SDL. 

Yes, for what I've been seeing with the lcd on the other system if you select 320x448 it will scale yres instead and the result will be perfect, so that would be the case of fake doublescan on vga monitors.

I'm not sure if it's a directdraw feature or just something explicitly coded in the ddraw osd part, that could be ported to the sdl side.

Also looks like in the best mode function, I'm now seeing how after checking exact matches, like you've been saying, I can try double width ones too.  Should I also then after that check for double height ones with the same original width, then mabye double width + double height after that?

Yes, the only caution needed is to penalize interlaced modes, as I wouldn't choose an interlaced mode if I have a better progressive one available although not exact. So I'm guessing it can get a little tricky to account for everything, although that will make a very flexible system.

[bitbytebit]

So in the height case for doublescan, is it also able to do the same thing?  Interesting, I am guessing it's a direct draw feature or something.  I'm looking at a couple possible changes, first check if SDL or driect draw and only mess with the height on this or width on no-doublescan if it's SDL.

Yes, for what I've been seeing with the lcd on the other system if you select 320x448 it will scale yres instead and the result will be perfect, so that would be the case of fake doublescan on vga monitors.

I'm not sure if it's a directdraw feature or just something explicitly coded in the ddraw osd part, that could be ported to the sdl side.

Also looks like in the best mode function, I'm now seeing how after checking exact matches, like you've been saying, I can try double width ones too.  Should I also then after that check for double height ones with the same original width, then mabye double width + double height after that?

Yes, the only caution needed is to penalize interlaced modes, as I wouldn't choose an interlaced mode if I have a better progressive one available although not exact. So I'm guessing it can get a little tricky to account for everything, although that will make a very flexible system.

Try the current patch or git, I haven't made builds of the changes yet, but I hopefully have done the scoring a lot better now and might have gotten close to doing like you mention above.  

See the changes, let me know how it works, I do have a few questions about when the match is 'fuzzy', which you may want to test.  Like what do we need to set when width is a bit less than we wanted (especially vertical games), possibly keep aspect and hwstretch?  And when width is wider than what we wanted, but not double, gessing we need keepaspect but no hwstretch in that case.  You'll see in the changes I've made since the patch above I posted, (git diff ac7266e137b5ac37efd45f339f9bc3a6f369a3c0) that I'm now doing some extra checking to set keepaspect and/or hwstretch in the non-perfect match cases.  Also now only set filter if interlaced is used, just to make sure it's always on in any interlaced mode, thinking that is best just in case.  I also score down the interlaced modes, but that might need some perfecting, my score system is kinda a quick hack but hopefully improves if not already good enough.

Update:
  Ok I'm uploading builds as 012b for this now, since from what I can tell it probably is only going to be better than what has been being done in the past.  At least seems like there's a lot more chance of things working, even when you have a limited custom modeline table.  Also wondering about how to check if a custom modeline is really usable, with my testing since it's on a system without 15khz monitors I never reboot and activate them, so I can test without going into them.  So is it only by that active modelines check we do to reload things, does that actually return the custom modelines too once they are active?

[Calamity]

I'm going to try the new patch here with a lcd, although won't be able to test it in my cab probably until Sunday as I'm away this weekend.

Yes, this could be the moment to work on the pick best mode algorithm, I've always wanted to figure out a good one but never started with it. It's not a trivial matter probably, and I think no one has come with a really good algorithm yet, even the original one from Mame is far from perfect. However the one in GroovyMame is already doing pretty good when fed with a decent mode list.

By using EnumDisplaySettings api you get the modes actually available in the system, so by matching that list with your registry modeline list you can check which of them are available and most important, which of the are custom modes instead of native modes: unless explicitly stated we should not use native modes as we can't tweak or have any control on them.

There's something else I noticed in the last logs, if I launch Groovymame with the -resolution0 param I think we should force it to update the registry modeline we're asking for (in case it exists) instead of making its own decision, mainly because after that it's actually using the resolution we asked for so the modified registry modeline is never used.

Update: I've done basic testing here. It works perfect when one of the dimensions is doubled (goldnaxe case: 320x448), but doesn't choose the right one when both dimensions are doubled (bublbobl: should select 512x448). However if I force bublbobl to select 512x448 then it displays perfectly (but groovymame does not target the right modeline as I explained above, so it runs 101%). For these tests I'm using monitor option "vga" and have a modeline list calculated with fake doublescan. Notice that even if I have created modelines with yres=512, for games that are 256 lines tall (*2), those modes are not available in my system, probably blocked by my lazy Dell lcd monitor edid (its native resolution is 1680x1050).

[bitbytebit]

I'm going to try the new patch here with a lcd, although won't be able to test it in my cab probably until Sunday as I'm away this weekend.

Yes, this could be the moment to work on the pick best mode algorithm, I've always wanted to figure out a good one but never started with it. It's not a trivial matter probably, and I think no one has come with a really good algorithm yet, even the original one from Mame is far from perfect. However the one in GroovyMame is already doing pretty good when fed with a decent mode list.

By using EnumDisplaySettings api you get the modes actually available in the system, so by matching that list with your registry modeline list you can check which of them are available and most important, which of the are custom modes instead of native modes: unless explicitly stated we should not use native modes as we can't tweak or have any control on them.

There's something else I noticed in the last logs, if I launch Groovymame with the -resolution0 param I think we should force it to update the registry modeline we're asking for (in case it exists) instead of making its own decision, mainly because after that it's actually using the resolution we asked for so the modified registry modeline is never used.

Update: I've done basic testing here. It works perfect when one of the dimensions is doubled (goldnaxe case: 320x448), but doesn't choose the right one when both dimensions are doubled (bublbobl: should select 512x448). However if I force bublbobl to select 512x448 then it displays perfectly (but groovymame does not target the right modeline as I explained above, so it runs 101%). For these tests I'm using monitor option "vga" and have a modeline list calculated with fake doublescan. Notice that even if I have created modelines with yres=512, for games that are 256 lines tall (*2), those modes are not available in my system, probably blocked by my lazy Dell lcd monitor edid (its native resolution is 1680x1050).

Do that bublboble with a -md 4 or more, something is odd there, it should have scores for some of those resolutions and they are all 0.00.  So something odd, and more debug might show me how that's happening.