Software Support > GroovyMAME
Switchres: modeline generator engine
bitbytebit:
Version .9 is up, now on sourceforge or my website since it got larger with the additional optional xserver source with default modeline setup removed to avoid useless ones we don't ever use on an arcade monitor. It also has an xrandr resolution switching wrapper script that solves the issue with having multiple resolutions with the same height and width but different refresh rate. Lots of bug fixes, read the first post on the thread for more details.
Calamity:
Hi bitbytebit,
I'ts so good you figured out how to fix the built-in modelines issue and also included xrandr functionallity.
It's funny that the x server messes with modelines, that's not what it's supposed to do according to this:
http://www.x.org/archive/X11R6.8.1/doc/xorg.conf.5.html
--- Quote ---The Identifier entry specifies the unique name for this monitor. The Monitor section provides information about the specifications of the monitor, monitor-specific Options, and information about the video modes to use with the monitor. Specifying video modes is optional because the server now has a built-in list of VESA standard modes. When modes are specified explicitly in the Monitor section (with the Modes, ModeLine, or UseModes keywords), built-in modes with the same names are not included. Built-in modes with different names are, however, still implicitly included.
--- End quote ---
As for the increasing/decreasing method, I think decreasing is not an option, as you must consider xres to be measured by characters (8 pixel block) instead of pixels. When passing xres values to the hardware, at some point I believe Xres is rounded to its lower 8-multiple, as VGA registers work with characters (btw, that's why the horizontal part of the modeline must use 8-multiples). So if you decrease xres you might loose 8 pixels instead of one (I haven't tested this).
bitbytebit:
--- Quote from: Calamity on October 13, 2010, 04:40:24 am ---Hi bitbytebit,
I'ts so good you figured out how to fix the built-in modelines issue and also included xrandr functionallity.
It's funny that the x server messes with modelines, that's not what it's supposed to do according to this:
http://www.x.org/archive/X11R6.8.1/doc/xorg.conf.5.html
--- Quote ---The Identifier entry specifies the unique name for this monitor. The Monitor section provides information about the specifications of the monitor, monitor-specific Options, and information about the video modes to use with the monitor. Specifying video modes is optional because the server now has a built-in list of VESA standard modes. When modes are specified explicitly in the Monitor section (with the Modes, ModeLine, or UseModes keywords), built-in modes with the same names are not included. Built-in modes with different names are, however, still implicitly included.
--- End quote ---
As for the increasing/decreasing method, I think decreasing is not an option, as you must consider xres to be measured by characters (8 pixel block) instead of pixels. When passing xres values to the hardware, at some point I believe a "Xres MOD 8" operation is performed, as VGA registers work with characters (btw, that's why the horizontal part of the modeline must use 8-multiples). So if you decrease xres you might loose 8 pixels instead of one (I haven't tested this).
--- End quote ---
Yeah, this xrandr stuff is just really strange though because it worked pretty well then crashed and after reboot it really didn't act like I expected. So I guess it's some hope, but now looking like 50% better than waiting for SDL 1.3 to arrive, which claims to fix the vsync issues (although seems if it isn't working yet then it hasn't yet, but that must be why it's taking so long). The incremental stuff at least works quite well, I get the best overall look of the games from it so far, definitely my favorite right now. I don't know if this xrandr is really unstable or I just need to update all of my X Windows to the current versions, but that seems pretty crazy and not expecting everyone to do that because it's a big task.
elvis:
I just want to say thanks especially to Calamity and bitbytebit for all their open discussion in this thread. It's explained a hell of a lot for me, and why I've been having so many dramas with recent Xorg builds (the forced 60.00Hz issue and Xorg ignoring my modeline refresh was driving me nuts).
I'll be playing with xrandr over the next week myself (based on the perl script in the GenRes stuff) to see if that solves my issue. I'm using NVidia hardware and hacked nv_drv.so myself to force pclocks lower than 12MHz (which is hard set in the nv drivers).
But yeah, thanks again to you both. This thread has shone a lot of light on a few issue for me.
bitbytebit:
There's a lot of brick walls it seems in linux for Arcade monitors, which I'm finding and working on breaking. First the Xorg servers all seem to not have options for CGA/EGA or anything below 31Khz, plus the pclock lock and moving away from modelines and to CVT. On top of that I'm finding that there is also the kernel framebuffer which has similar issues where the drivers force a higher minimum pclock. Last night I changed uvesafb to allow a lower pclock and finally got mame to modeswitch using an fb.modes file to arcade resolutions. Still working out issues there, but it at least finally responded unlike the default vesa framebuffer which is useless for an arcade monitor or the radeon one which seems to ignore my ArcadeVGA card (still not sure why about that). Also there's the fact we aren't into the Vertical Refresh rate being accurate till SDL 1.3 which currently the newest build is broken with mame. I have a patch which makes it work, and it's really nice how it truly can choose the right modeline by both resolution and refresh rate. It also has a vsync support I guess, so it all looks neat. The only issue though is they haven't implemented the ability to hide the mouse cursor or turn it into a full non-limited mouse. So any game needing a mouse, trackball, spinner has limits of the mouse movement to the sides of the screen and you see a huge mouse all the time. SDL 1.3 though is nice for games like pacman or any other simpler classic games, just avoids the incrementing the horizontal frame size hack. I've got a newer version of genres coming which I'm now mainly working on besides some odds n ends for bug fixes, getting the vertical refresh rates as perfectly accurate as possible (to avoid needing as many vsync hacks). Of course this really is mostly geared at Wells Gardner D9x00 monitors which can somewhat go into odd Horizontal refresh rates above 15.725 so I can actually run pacman at Vertial 60.61Hz and 252x288 by going into 19.2Khz horizontal refresh rates (which I've really notices the games act so much nicer when they match the right refresh rate). With this I've also been working on learning the modeline voodoo to be able to improve lrmc, studying the modelines from Soft 15Khz to try and learn what they are doing because those modelines are always really nice examples to go by. I have actually found some tweaks to lrmc which seems like it is creating modelines much more like the ones I see people using in Windows/Soft15Khz, one is the vertical game aspect ratio/horizontal width sizing which in lrmc is different and I think I figured out how to correct it. I'm still trying to figure out though how to make sure the refresh rates are good enough for people with just arcade monitors, yet be able to get them exact for people with this multisync able to do 15-40Khz WG type monitors. Hopefully I post a new genres by the end of the weekend with those general fixes, and the SDL 1.3 patch to mame for those who want to play with it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version