Software Support > GroovyMAME
Switchres: modeline generator engine
bitbytebit:
--- Quote from: Calamity on October 21, 2010, 12:10:16 pm ---
--- Quote from: bitbytebit on October 21, 2010, 10:18:54 am ---I found something odd about the waitvsync setting though, I'm starting to think it's my video card can't handle it properly or the X drivers for my video card/opengl implementation. I got the vsync working on another computer using an nvidia quadro fx 3400, my arcade system uses the newer arcadeVGA3000 which is just a radeon 2600HD I guess and has the RV630 on it.
--- End quote ---
I'm afraid the problem is with the Radeon driver not implementing waitvsync properly, as the folks in the Spanish forum thought, as with nVidia they were able to make waitvsync work without problem.
Regarding porches and sync pulses, I am positive they keep constant through the range covered by my monitor: 15.625 - 16.670 KHz, so in order to keep my modes centered I have to use the same values all the time. This stuff is related to the speed of the electron beam, which is constant in my monitor regardless of hfreq. There's a visible effect due to this: when you increase hfreq, the picture becomes narrower in width, as the extra lines, being the beam speed constant, need to come from somewhere: the sides of the picture! Your monitor must have more complex electronics, to be able to program the electrom beam at different speeds according to some previously defined hfreq intervals (you would notice the explained narrowing effect somewhere), or... have a really progresive beam speed, which would allow to interpolate the porch values for the whole range.
--- End quote ---
Interesting, good to know and now I guess I'm going to try my nvidia cards, sounds like I need that for vsync and sounds great to finally get it working right with all these resolutions having the right refresh rate.
I'm currently realizing I can now do all the odd calculations that lrmc was doing, like the vertical game resizing or dual screen adjustment, inside switchres now. That is going to make it a lot simpler doing all the pre-work inside the perl script and just let lrmc take a resolution and refresh rate and expect it to not do any fiddling with it other than perfecting the modeline. This makes it much easier to have dual monitor support, which switchres should basically have now with some changes I just made, and testing. I had thought of the advv utility ability actually before, and have it right now just bringing up xvidtune in -testmode, but we need a better program than xvidtune I think. Seems that xvidtune is under the same spell the X drivers have gotten into where it doesn't listen to custom modelines very easily, or maybe it's just ignoring the xrandr modelines possibly. At any rate it basically will only come up with the modeline in the config xorg.conf and even then won't allow altering it claiming it is out of range unless it's a VESA compliant modline.
I am really interested in this aspect ratio issue though, because from what I can tell it's calculated different by everybody, some using 1.22222 some 1.333333 and lrmc was doing some odd division of the width by .56 on vertical games. Some games you have to leave alone, some need some tweaking (like dbz or virtua racer, mortal kombat). Seems it may be a range of vertical resolutions that have either larger than 1.3 or smaller aspect ratios, but never below 1.25. I'm not sure if it's something I'm doing, but from what I can tell I can get dbz at the exact original resolution and refresh but it's off the sides and I have to do some odd calculations to make it be in a letter box type screen and it fits then. Same with Virtua Racer but opposite, It's a smaller than 1.3, like 1.28 aspect ratio and It needs a slight different screen size I have to calculate weirdly. I have found algorithms that seem to work with these games mostly consistent but trying to see the deeper logic in it and if it really translates to all games and/or what ranges. So far if the vertical size is above 224 and below 400 and the aspect is above 1.3 I do one thing, while if below 1.3 but above 1.25 I do another. Seems to mostly work, and possibly only other unique thing is that maybe the ones above 1.3 only qualify for my change if they are below 56 Hz vertical refresh rates. So that's something I've been trying to wrap my brain around the last day or so, seems like it's a pixel aspect ratio vs. screen aspect ratio thing and not sure if lrmc might be a culprit and I'm fighting it or this information isn't in mame for the games and makes it hard to get exact display output that matches all parameters and fits perfect/refreshes perfectly. This of course isn't practical for normal arcade monitors to do all the games that way, but for the d9800 this seems to be an issue because you can actually match most and so it starts to get somewhat tricky because unlike the AVGA card or in Windows you don't just have a set of 30 modelines and know the games are going to have boarders sometimes and so leave extra which seems to make up for these odd aspect ratio games.
Calamity:
You may have already checked this, but just in case:
http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=46353&page=1
--- Quote from: bitbytebit on October 21, 2010, 12:29:33 pm ---I'm currently realizing I can now do all the odd calculations that lrmc was doing, like the vertical game resizing or dual screen adjustment, inside switchres now. That is going to make it a lot simpler doing all the pre-work inside the perl script and just let lrmc take a resolution and refresh rate and expect it to not do any fiddling with it other than perfecting the modeline.
--- End quote ---
Definitely YES, I recommend you to keep all the mode adaptation stuff in your script, and just pass lrmc a plain modeline to calculate it - as your project progresses, you might get rid of lrmc at all ;)
--- Quote from: bitbytebit on October 21, 2010, 12:29:33 pm ---I am really interested in this aspect ratio issue though, because from what I can tell it's calculated different by everybody, some using 1.22222 some 1.333333 and lrmc was doing some odd division of the width by .56 on vertical games. Some games you have to leave alone, some need some tweaking (like dbz or virtua racer, mortal kombat). Seems it may be a range of vertical resolutions that have either larger than 1.3 or smaller aspect ratios, but never below 1.25. I'm not sure if it's something I'm doing, but from what I can tell I can get dbz at the exact original resolution and refresh but it's off the sides and I have to do some odd calculations to make it be in a letter box type screen and it fits then. Same with Virtua Racer but opposite, It's a smaller than 1.3, like 1.28 aspect ratio and It needs a slight different screen size I have to calculate weirdly. I have found algorithms that seem to work with these games mostly consistent but trying to see the deeper logic in it and if it really translates to all games and/or what ranges. So far if the vertical size is above 224 and below 400 and the aspect is above 1.3 I do one thing, while if below 1.3 but above 1.25 I do another. Seems to mostly work, and possibly only other unique thing is that maybe the ones above 1.3 only qualify for my change if they are below 56 Hz vertical refresh rates. So that's something I've been trying to wrap my brain around the last day or so, seems like it's a pixel aspect ratio vs. screen aspect ratio thing and not sure if lrmc might be a culprit and I'm fighting it or this information isn't in mame for the games and makes it hard to get exact display output that matches all parameters and fits perfect/refreshes perfectly. This of course isn't practical for normal arcade monitors to do all the games that way, but for the d9800 this seems to be an issue because you can actually match most and so it starts to get somewhat tricky because unlike the AVGA card or in Windows you don't just have a set of 30 modelines and know the games are going to have boarders sometimes and so leave extra which seems to make up for these odd aspect ratio games.
--- End quote ---
I am not sure if I follow you here, but... I wouldn't care about pixel aspect at all. Think that arcade games picture was stretched using monitor potenciometers to cover the 4:3 full screen, regardless they had 192, 224, 240, 256 or whatever vertical resolution, so speaking of pixel aspect there doesn't make sense, unless you intend to add artificial side bordes to keep the picture 4:3 without adjusting monitor controls (something I would understand if you use a TV with no service mode, but not with an arcade monitor). So if DBZ asks you for 416x224, just make that exact resolution, then adjust your monitor's v-amp to cover the screen, it works for me this way. For vertical games it's a different story.
Gray_Area:
AdvanceMAME did dynamic modeline generation at game start-up, and was initially Linux-based. Maybe you want to look at the source?
http://advancemame.sourceforge.net/
bitbytebit:
--- Quote from: Gray_Area on October 21, 2010, 01:42:23 pm ---AdvanceMAME did dynamic modeline generation at game start-up, and was initially Linux-based. Maybe you want to look at the source?
http://advancemame.sourceforge.net/
--- End quote ---
Thanks for reminding me, I actually have wanted to do that and tried awhile back but now should take another look. I have learned a lot more since I last tried and suspect I can spot the stuff I need much easier now. Definitely seems like what this is turning into is a wrapper for the normal mame/mess or other emulators that can give them the ability that advancemame has/had when it was up to date. Hopefully can be a little less dependent on hardware, but I am starting to see how that is really a brick wall with certain cards with either the physical chips or the knowledge of how to get the chips to do what we need.
bitbytebit:
--- Quote from: Calamity on October 21, 2010, 01:13:00 pm ---You may have already checked this, but just in case:
http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=46353&page=1
--- Quote from: bitbytebit on October 21, 2010, 12:29:33 pm ---I'm currently realizing I can now do all the odd calculations that lrmc was doing, like the vertical game resizing or dual screen adjustment, inside switchres now. That is going to make it a lot simpler doing all the pre-work inside the perl script and just let lrmc take a resolution and refresh rate and expect it to not do any fiddling with it other than perfecting the modeline.
--- End quote ---
Definitely YES, I recommend you to keep all the mode adaptation stuff in your script, and just pass lrmc a plain modeline to calculate it - as your project progresses, you might get rid of lrmc at all ;)
--- Quote from: bitbytebit on October 21, 2010, 12:29:33 pm ---I am really interested in this aspect ratio issue though, because from what I can tell it's calculated different by everybody, some using 1.22222 some 1.333333 and lrmc was doing some odd division of the width by .56 on vertical games. Some games you have to leave alone, some need some tweaking (like dbz or virtua racer, mortal kombat). Seems it may be a range of vertical resolutions that have either larger than 1.3 or smaller aspect ratios, but never below 1.25. I'm not sure if it's something I'm doing, but from what I can tell I can get dbz at the exact original resolution and refresh but it's off the sides and I have to do some odd calculations to make it be in a letter box type screen and it fits then. Same with Virtua Racer but opposite, It's a smaller than 1.3, like 1.28 aspect ratio and It needs a slight different screen size I have to calculate weirdly. I have found algorithms that seem to work with these games mostly consistent but trying to see the deeper logic in it and if it really translates to all games and/or what ranges. So far if the vertical size is above 224 and below 400 and the aspect is above 1.3 I do one thing, while if below 1.3 but above 1.25 I do another. Seems to mostly work, and possibly only other unique thing is that maybe the ones above 1.3 only qualify for my change if they are below 56 Hz vertical refresh rates. So that's something I've been trying to wrap my brain around the last day or so, seems like it's a pixel aspect ratio vs. screen aspect ratio thing and not sure if lrmc might be a culprit and I'm fighting it or this information isn't in mame for the games and makes it hard to get exact display output that matches all parameters and fits perfect/refreshes perfectly. This of course isn't practical for normal arcade monitors to do all the games that way, but for the d9800 this seems to be an issue because you can actually match most and so it starts to get somewhat tricky because unlike the AVGA card or in Windows you don't just have a set of 30 modelines and know the games are going to have boarders sometimes and so leave extra which seems to make up for these odd aspect ratio games.
--- End quote ---
I am not sure if I follow you here, but... I wouldn't care about pixel aspect at all. Think that arcade games picture was stretched using monitor potenciometers to cover the 4:3 full screen, regardless they had 192, 224, 240, 256 or whatever vertical resolution, so speaking of pixel aspect there doesn't make sense, unless you intend to add artificial side bordes to keep the picture 4:3 without adjusting monitor controls (something I would understand if you use a TV with no service mode, but not with an arcade monitor). So if DBZ asks you for 416x224, just make that exact resolution, then adjust your monitor's v-amp to cover the screen, it works for me this way. For vertical games it's a different story.
--- End quote ---
Yeah that is a thought I had too, it's definitely going to be possible eventually to either avoid lrmc, and we could also support any modeline generator too. I like the idea of trying to get the modeline generation put into perl code so it's easy to modify and more people could alter it easier.
Yeah I'd seen that thread about the radeon directfb support, odd thing is that it seems this ArcadeVGA 3 radeon isn't compatible with the linux kernels radeonfb framebuffer because the RV630 isn't supported I guess. It doesn't allow the KMS stuff in newers kernels either, because it doesn't know the atom bios signature. I assume it's because it's modified, it isn't really the same as those other radeon cards to the linux code.
This pixel aspect thing is also odd because the way I figured out the formula I'm using for virtua racer was to look at what the -verbose output of mame for the GL shader was saying about the pitch values I guess. It came up with 520x400 I think or something instead of the 496x384 it is said to be normally. So I came up with that value through doing some calculating and seeing it was the difference of the 1.3 aspect ratio from the 1.29 reported times the height, and then the game aspect ratio of 1.29 times that new height. Somehow that calculates it out and I think it works on other games, for dbz I can do a similar calculation and it works for the mortal kombat too and possibly others. I'm still testing, figuring, but here's the basic formula which for some reason seems to mostly work... (Game aspect vs. monitor aspect as 1.3333333)
--- Code: --- } elsif ($GASPECT > $MASPECT) {
my $ADIFF = $GASPECT - $MASPECT;
$o_width = $o_width + ($o_height / 3);
$o_height = $o_width / $MASPECT;
$o_width = sprintf("%.0f", $o_width);
$o_height = sprintf("%.0f", $o_height);
} elsif ($GASPECT >= 1.25 && $GASPECT < $MASPECT) {
my $ADIFF = $MASPECT - $GASPECT;
$o_height = $o_height + ($ADIFF * $o_height);
$o_width = $GASPECT * $o_height;
$o_width = sprintf("%.0f", $o_width);
$o_height = sprintf("%.0f", $o_height);
}
--- End code ---
I really hope it's something else, since it does seem odd to have to deal with the aspect ratio at all, but so far seems like this really is necessary for some reason with the modelines. Actually I'm surprised that it seems to be working somewhat for the most part, and making these games look good now, I didn't think it'd actually be able to universally work but so far it might just be doing that with the code above. I don't totally understand why dividing by 3 for that one calculation works, but that was the way to get the right value and it seems to be working also on other games too. I think it might be something about the 4/3 ratio, but I just saw that it seemed to make the height/width come out to display the game without side boarders and not stretched at all vertically. I also have keepaspect at 0 and unevenstretch at 0 too, which of course with those the screen will fit any resolution but alter things, another odd thing I've seen with the arcadeVGA sight instructions where they tell you to turn those on but I can't see how that would be a good idea unless the game is just too big and you have to fit it into a smaller resolution.
Edit:
Yeah I now see issues with doing this, hmmm, seems like it may be a side effect of lrmc possibly causing the issue with some games that I am trying to fix through this. Will have to look at what it's doing and see.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version