Software Support > GroovyMAME
Switchres: modeline generator engine
bitbytebit:
--- Quote from: ves on October 08, 2010, 09:23:46 am ---Hi, thanks for your patches and improvements in Genres, I wanted to ask if this genre to implement real arcade monitors as HANTAREX or otherwise you're just applying it to the Wells Gardner, which would be an optimum configuration for Hantarex?
With regard to the diff, you could explain more what they actually do? I have understood the implemented improvements cabmame.diff cleanstretch emuspeed resolution (resolved or additions would be problems in sdlmame Syncrefresh and waitvsync?).
With nativeres.diff would leave only select their original resolution?
Parameters that would need the mame.ini with new patches?
Thanks.
--- End quote ---
It should work for any monitor/TV, since it's using lrmc it should be able to either use -cga for arcade monitors or even any custom set of Horizontal/Vertical frequencies using an lrmc.conf file. I of course have only tested on the d9800, but suspect it should work for anything that lrmc supports, which seems to be any lowres monitor or PAL/NTSC TV. You basically just have to give it a command like this for an actual arcade monitor...
./create_xorg.sh -cga
and add -ff if using the frogger/galaxian included patches. If there are limits on max resolution sizes, alter those with the command line args and any other lrmc args needed to create a good modeline for the monitor. I would be interested in any additional args needed, then I could add those as defaults for different monitor types, like the maximum height/width most likely since I have it at 800x600 for the d9800 as the default.
The nativeres is a patch from the qmc2 project and just basically uses the games native resolution settings instead of changing it in mame, really I don't see it doing too much actually to be honest so can have nativeres at the default of 0 to be safe. I also made the nativeres setting work when the changeres option is used, I think that makes it to where it keeps the games original resolution inside the forced resolution from the .ini file but not 100% sure on that, it seems act fine that way and maybe a few pixels/lines nicer on the edges with that from what I can tell. The other patch just applies to a source tree that has the nativeres patch already applied. Really the main bonus I've seen of the patches so far is that the frogger/galaxian games fixes, which do seem to rely some on the cleanstretch patch although it seems like just an opposite of the unevenstretch option already in sdlmame but a different take on how to do it I think. I've just started exploring the CabMame patches and ported the ones to Linux that seem doable, the sound frequency one seems possibly hard because SDL sound doesn't allow frequency changing on the fly easily like the Windows API seems to. Seems like the patches run fine still with waitvsync either on/off, the options below are the additional options they enable...
nativeres 1/0 (0 by default)
cleanstretch 1/0 (1 by default)
I also think I fixed a possible bug in the cleanstretch patch working with the frogger/galaxian patch properly, at least when cleanstretch is turned off it seems that the frogger/galaxian fix wasn't also done in that case while now it will work with cleanstretch off as well. There is an oddity I see with the frogger/galaxian patch though when using software video instead of opengl for some reason the frogger/galaxian resolution games don't get put in the window centered (they are way down below so basically just a black screen). That's one issue I don't fully understand, that opengl is required for that fix, also similar to an issue that happens in mame without patches in SDL where if the artwork is present but turned off the games are offset by the bezel sizes using software video while in opengl it properly centers then correctly even with the artwork present but settings turning it off. I get the feeling somehow software rendering in SDL mame doesn't do something that opengl is doing to setup the screen to the actual game dimensions once artwork or the galaxian vertical size adjustment is done. Would be interesting to see if others really see this same issue as me or it's just something I'm doing wrong locally on my setup.
Also it's important to set the following mame options in the mame.ini to these, to avoid any stretching in SDL mame.
video opengl # prefered for reasons explained above
filter 0 # off to prevent opengl softening
gl_glsl_filter 0 # Assume filtering is bad, guessing this is not necessary
waitvsync 1 # sounds good, works fine with patches, not sure if really necessary
window 0
maximize 0
keepaspect 0 # this is setup only for a few games in the .ini files which resolutions don't match the aspect ratio
unevenstretch 0 # same as above, used together
cleanstretch 0 # Actually surprisingly I have this off for now, not fully tested. It DOES NOT work well with unevenstretch enabled. Seem like opposite options.
# Off for an arcade setup, oddly in soft mode even if off and I have the artwork directory, game is offset size of artwork from top. Same as with frogger patch, since it reduces the vertical size I guess.
artwork_crop 0
use_backdrops 0
use_overlays 0
use_bezels 0
Hopefully that helps clear up some things of how to set the options to work the best and the patches, similar to what the ArcadeVGA card setup instructions are in Windows yet somewhat different for SDL. I still don't get why they ask you to use unevenstretch and keepaspect as defaults (which makes pacman look terrible, at least in SDL). Or why the current Windows based .ini file generators used choose some of the resolutions they do, which is why I created this genres method plus getting those modelines in Linux and knowing they all would work was proving to be way too tricky. Usually they say go through and tweak them by hand, but I've really worked to make this able to not require that and automated all of the tweaking by hand since most of the time there's some algorithm there you can put into code for all the games following the same logic.
Edit: I think I'm going to remove the cabmame.diff and just include a Linux SDL version of the frogger.diff fix from cabmame. This seems like the only real important patch necessary to work with lrmc like this and get those games like frogger/galaxian to natively display correctly on arcade monitors. Doing some testing, next version will include just the frogger patch and nativeres one although it is only optional since I don't even know for sure yet if it does much of anything :/.
Calamity:
Hi bitbytebit,
This is a highly interesting project, I hope we can share some stuff. I also wrote a program to generate modelines + .inis from Mame XML, for the Windows platform. Mine is called VideoModeMaker, and can be downloaded here (in Spanish):
http://postback.geedorah.com/foros/viewtopic.php?id=1424
As you state, there is a limitation to Windows video drivers that, by default, just allow for a small number of custom modes to be defined. That's why I patched Ati Catalyst drivers so they can admit more modelines, up to 200. I focused on Ati because at the beginning I was only interested in extending ArcadeVGA capabilities. However, 200 modelines is still not enough to accommodate all resolutions needed for emulation, that's why I wrote that program, that attempts to order them by importance so they can fit in a predefined-length mode table.
Though I have no experience with Linux, I'm trying to help VeS (who posted above) to prepare a live distribution of Linux that works like AdvanceMame, we've been struggling with it in this thread (in Spanish also):
http://www.retrovicio.com/foro/showthread.php?t=9258
In Windows, I have worked out a modeline "labeling" system that works reasonably well for it's purpose, but we're having some troubles to port it to Linux. Maybe with your system and inis we can achive the results we're looking for. I'd highly appreciate some help with this.
To add up, in Windows OS video modes are stored using three integers: xres, yres, vfreq. So, to invoke a given resolution using Mame, you just have to set the ini up like this:
resolution0 320x224@58
Now consider we have two modelines which vertical refresh rate just differs in some tenths:
Modeline "320x224@57.6Hz 15.7KHz (58Hz)" 6.630 320 336 368 424 224 239 242 272 -hsync -vsync
Modeline "321x224@58.0Hz 15.7KHz (58Hz)" 6.640 320 336 368 424 224 238 241 270 -hsync -vsync
As vertical refresh rate is stored as an integer, I need to modify the mode "label" so both video modes can coexist. I do that by increasing xres by one pixel each time (321, 322, ...) so I can store 8 variations of a resolution within 1 Hz interval (as I only use 8 pixel multiples for xres). This can be done because we store these "labels" in windows registry before they are used by the OS, which by the way are indepent of the actual modeline info that we store together.
BUT... I suspect that in Linux, the modeline part between quotations is just considered as a name, it could be "320x224" or "whatever". Am I right?
SO... how can you manage to make a difference among above modelines?
How would you invoke them from Mame inis to be sure the proper modeline is used?
Now, about CabMame stuff... I also use Windows CabMame to work with the modelines produced by my program, as Syncrefresh was spoiled since v0.107 (as far as I know), so it's also a great surprise that you are trying to port those patches to SDLMame. Even if we don't have triplebuffer in SDLMame, have you got Waitvsync to work smoothly as it's intended? What we need, is an option that disables normal throttling and just syncs the game action to the vertical frequency, whatever it is. I was able to hack regular Mame to do this without the help of CabMame patches, but whatever method you use and works we'll be grateful to know.
Thanks!
Calamity
bitbytebit:
--- Quote from: Calamity on October 08, 2010, 02:06:55 pm ---Hi bitbytebit,
This is a highly interesting project, I hope we can share some stuff. I also wrote a program to generate modelines + .inis from Mame XML, for the Windows platform. Mine is called VideoModeMaker, and can be downloaded here (in Spanish):
http://postback.geedorah.com/foros/viewtopic.php?id=1424
As you state, there is a limitation to Windows video drivers that, by default, just allow for a small number of custom modes to be defined. That's why I patched Ati Catalyst drivers so they can admit more modelines, up to 200. I focused on Ati because at the beginning I was only interested in extending ArcadeVGA capabilities. However, 200 modelines is still not enough to accommodate all resolutions needed for emulation, that's why I wrote that program, that attempts to order them by importance so they can fit in a predefined-length mode table.
--- End quote ---
Yes definitely, I currently have 442 modes generated with both mess and mame combined. Next version of genres has mess support too, and it just adds tons of new ones.
--- Quote from: Calamity on October 08, 2010, 02:06:55 pm ---
Though I have no experience with Linux, I'm trying to help VeS (who posted above) to prepare a live distribution of Linux that works like AdvanceMame, we've been struggling with it in this thread (in Spanish also):
http://www.retrovicio.com/foro/showthread.php?t=9258
In Windows, I have worked out a modeline "labeling" system that works reasonably well for it's purpose, but we're having some troubles to port it to Linux. Maybe with your system and inis we can achive the results we're looking for. I'd highly appreciate some help with this.
To add up, in Windows OS video modes are stored using three integers: xres, yres, vfreq. So, to invoke a given resolution using Mame, you just have to set the ini up like this:
resolution0 320x224@58
Now consider we have two modelines which vertical refresh rate just differs in some tenths:
Modeline "320x224@57.6Hz 15.7KHz (58Hz)" 6.630 320 336 368 424 224 239 242 272 -hsync -vsync
Modeline "321x224@58.0Hz 15.7KHz (58Hz)" 6.640 320 336 368 424 224 238 241 270 -hsync -vsync
As vertical refresh rate is stored as an integer, I need to modify the mode "label" so both video modes can coexist. I do that by increasing xres by one pixel each time (321, 322, ...) so I can store 8 variations of a resolution within 1 Hz interval (as I only use 8 pixel multiples for xres). This can be done because we store these "labels" in windows registry before they are used by the OS, which by the way are indepent of the actual modeline info that we store together.
--- End quote ---
Oh, that's an integer value in the ini files? Very odd, wonder why they have it like that since they are all not like that in the xml file and in the code too. I wonder if that can be changed to read the ini files refresh rates as doubles instead, which would solve the need for extra work like that.
--- Quote from: Calamity on October 08, 2010, 02:06:55 pm ---
BUT... I suspect that in Linux, the modeline part between quotations is just considered as a name, it could be "320x224" or "whatever". Am I right?
SO... how can you manage to make a difference among above modelines?
How would you invoke them from Mame inis to be sure the proper modeline is used?
--- End quote ---
In linux they are just labels, and can be anything such as "BIGRES" and that'd work if in the Modes section in line, also in Linux if you put basic "800x600" in the Modes section it'll find the default on from the cards driver. I just do the "800x600@60.00" and have them different that way, looks like the best way to pull that from ini files (I had thought were accepting the full double values) would be to hack mame to accept that.
--- Quote from: Calamity on October 08, 2010, 02:06:55 pm ---
Now, about CabMame stuff... I also use Windows CabMame to work with the modelines produced by my program, as Syncrefresh was spoiled since v0.107 (as far as I know), so it's also a great surprise that you are trying to port those patches to SDLMame. Even if we don't have triplebuffer in SDLMame, have you got Waitvsync to work smoothly as it's intended? What we need, is an option that disables normal throttling and just syncs the game action to the vertical frequency, whatever it is. I was able to hack regular Mame to do this without the help of CabMame patches, but whatever method you use and works we'll be grateful to know.
--- End quote ---
Really new to the cabmame patches, as of yesterday basically, and definitely interested in this throttle issue and vsync. I do notice in SDL if I set throttle to 0 or off, then the games run as fast as they can and are fast forwarding basically, so in SDL seems even with waitvsync set to 1 it doesn't work. I know I can set waitvsync to 1 and things work fine, but not sure if it's really doing anything and I know the throttle setting has to be 1 for things not to fly super fast. Have seen how triplebuffer would be better, not sure if that's a driver thing missing in SDL or fully how all that works yet. I'd be interested in seeing how you got the vsync working, would help me understand more how that all is setup in the code and maybe help figure out more about the throttle issue and SDL.
I have the frogger patch figured out, it's simple, although there's still something odd there because it won't work without opengl so it's missing some proper setup in SDL to do both soft/opengl. The cleanstretch still strange to me because it seems like it would only be needed when having to stretch things and the unevenstretch interferes with it oddly, trying to see how that all works. I swear it looks like the cleanstretch patch changes the action of things so they aren't the same when it's set to 0, sort of how the frogger patch only was setup to work when the cleanstretch patch was applied and set to 1. A lot of the other cabmame patches look like either would not fit SDL without some really heavy changes to things from lack of SDL support for audio resampling on the fly (at least what I can tell it doesn't work), I have a hiscore patch for Linux (just adds onto the current one on these forums, so it's a quick easy fix per version change of mame to add on top of that one), the defaults patch and changeres seems probably not necessary for basic arcade games so I'm looking at it later (plus seems a bit tricky to port). The emuspeed patch I don't fully see what it's doing, or resolution one I'm not fully sure either yet. So the vsync thing seems really interesting to me, since this all would really work well with getting the .ini files and modelines exact, waiting on all the other cabmame patches for now since seems not as centered around the resolution stuff and require some redoing I think in the SDL part of mame.
--- Quote from: Calamity on October 08, 2010, 02:06:55 pm ---Thanks!
Calamity
--- End quote ---
Thanks, I'm going to look at the .ini refresh rate thing and also have a lot of fixes/cleanups actually to genres including the support for mess modelines/merging. Sounds like this .ini file issue would be a big step, since now I realize not all my modelines are probably getting used.
Thanks,
Chris
bitbytebit:
--- Quote from: Calamity on October 08, 2010, 02:06:55 pm ---
To add up, in Windows OS video modes are stored using three integers: xres, yres, vfreq. So, to invoke a given resolution using Mame, you just have to set the ini up like this:
resolution0 320x224@58
--- End quote ---
Oh my, look at this, at least in the sdl code we are doing it wrong...
if (sscanf(data, "%dx%dx%d@%d", &config->width, &config->height, &config->depth, &config->refresh) < 2 && report_error)
Actually the resolution value needs to be widthxheightxdepth@refresh
How odd, but they are definitely integers, that's for sure.
Ah, ok, in windows this doesn't have the depth value...
if (sscanf(data, "%dx%d@%d", &config->width, &config->height, &config->refresh) < 2 && report_error)
But also an integer
At least I'm finding where to start looking.
Calamity:
--- Quote from: bitbytebit on October 08, 2010, 03:45:36 pm ---Oh, that's an integer value in the ini files? Very odd, wonder why they have it like that since they are all not like that in the xml file and in the code too. I wonder if that can be changed to read the ini files refresh rates as doubles instead, which would solve the need for extra work like that.
--- End quote ---
It's not a Mame issue, it's the OS that stores videomodes in that way, so it doesn't matter that you use doubles in Mame, because at least in windows you end up having to a ask the OS for the mode you need, and the functions involved use integers.
I don't mean it's the same in Linux, but think about this... do you think that when you add a modeline the operating system is really working out the vfreq resulting from that modeline data so that you can ask for it later? I really doubt it.
--- Quote from: bitbytebit on October 08, 2010, 03:45:36 pm ---In linux they are just labels, and can be anything such as "BIGRES" and that'd work if in the Modes section in line, also in Linux if you put basic "800x600" in the Modes section it'll find the default on from the cards driver. I just do the "800x600@60.00" and have them different that way, looks like the best way to pull that from ini files (I had thought were accepting the full double values) would be to hack mame to accept that.
--- End quote ---
Are those labels stored somewhere? Can you by any means invoke those video modes by using it's text label, like "BIGRES"? That would definitely solve the problem if we modified Mame to read a string from the inis instead of a numbers for the resolution. It's just a suggestion as I have no idea how Linux manages this stuff.
--- Quote from: bitbytebit on October 08, 2010, 03:45:36 pm ---Really new to the cabmame patches, as of yesterday basically, and definitely interested in this throttle issue and vsync. I do notice in SDL if I set throttle to 0 or off, then the games run as fast as they can and are fast forwarding basically, so in SDL seems even with waitvsync set to 1 it doesn't work. I know I can set waitvsync to 1 and things work fine, but not sure if it's really doing anything and I know the throttle setting has to be 1 for things not to fly super fast. Have seen how triplebuffer would be better, not sure if that's a driver thing missing in SDL or fully how all that works yet. I'd be interested in seeing how you got the vsync working, would help me understand more how that all is setup in the code and maybe help figure out more about the throttle issue and SDL.
I have the frogger patch figured out, it's simple, although there's still something odd there because it won't work without opengl so it's missing some proper setup in SDL to do both soft/opengl. The cleanstretch still strange to me because it seems like it would only be needed when having to stretch things and the unevenstretch interferes with it oddly, trying to see how that all works. I swear it looks like the cleanstretch patch changes the action of things so they aren't the same when it's set to 0, sort of how the frogger patch only was setup to work when the cleanstretch patch was applied and set to 1. A lot of the other cabmame patches look like either would not fit SDL without some really heavy changes to things from lack of SDL support for audio resampling on the fly (at least what I can tell it doesn't work), I have a hiscore patch for Linux (just adds onto the current one on these forums, so it's a quick easy fix per version change of mame to add on top of that one), the defaults patch and changeres seems probably not necessary for basic arcade games so I'm looking at it later (plus seems a bit tricky to port). The emuspeed patch I don't fully see what it's doing, or resolution one I'm not fully sure either yet. So the vsync thing seems really interesting to me, since this all would really work well with getting the .ini files and modelines exact, waiting on all the other cabmame patches for now since seems not as centered around the resolution stuff and require some redoing I think in the SDL part of mame.
--- End quote ---
This is the patch I used for restoring Syncrefresh functionallity in Mame v0.131 (I believe it's still usable). However, in SDLMame there's no Syncrefresh so it should be adapted for Waitvsync (I don't know how this option works in SDLMame or if it's equivalent). It's a very simple hack. Bear in mind I have never used C for programming, so if you find a more intelligent way for referencing those declares it would be great.
--- Code: ----------------------------------------------------------------------------------
Restoring Syncrefresh option - Mame v0.131
02/02/09 Calamity
-------------------------------------------------------------------------------
In src\emu\video.c:
After the includes, we copy:
/***************************************************************************
Restoring Syncrefresh
Declares copied from src\osd\windows\video.h
***************************************************************************/
#define MAX_WINDOWS 4
typedef struct _win_window_config win_window_config;
struct _win_window_config
{
float aspect; // decoded aspect ratio
int width; // decoded width
int height; // decoded height
int refresh; // decoded refresh
};
typedef struct _win_video_config win_video_config;
struct _win_video_config
{
// global configuration
int windowed; // start windowed?
int prescale; // prescale factor
int keepaspect; // keep aspect ratio
int numscreens; // number of screens
int layerconfig; // default configuration of layers
// per-window configuration
win_window_config window[MAX_WINDOWS]; // configuration data per-window
// hardware options
int mode; // output mode
int waitvsync; // spin until vsync
int syncrefresh; // sync only to refresh rate
int triplebuf; // triple buffer
int switchres; // switch resolutions
// ddraw options
int hwstretch; // stretch using the hardware
// d3d options
int filter; // enable filtering
};
extern win_video_config video_config;
Still in src\emu\video.c:
Below, we'll search for:
/* if we're throttling, synchronize before rendering */
if (!debug && !skipped_it && effective_throttle(machine))
We'll replace it with:
/* if we're throttling, synchronize before rendering */
if (!debug && !skipped_it && effective_throttle(machine) && !video_config.syncrefresh)
--- End code ---
The problem with this hack is that if modeline's vfreq is slightly different from the original game vfreq we should have sound sync problems, I believe.
Until Mame v0.106, it was enough to turn Syncrefresh on to have perfectly smooth scrolls with sound syncronized. Triplebuffer enables vsync but it's not as cpu consuming as vsync (syncrefresh). IMHO, the most important hack in CabMame is the soundsync option, which allows you to activate Triplebuffer without the sound issues that exist since v0.107. As triplebuffer may not be implemented in SDL (I don't really know), we could manage with the hack above if we got it working, despite the sound.
If vsync is not working properly, it's noticeable as you'll have horrible tearing in your games.
BTW, if you run mame with -verbose option it will prompt the video mode chosen, this might help to determine if it's working as expected.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version