Custom resolution/modeline for a single game(s) in Linux?

[emuola]

It's been almost a year now with my cab and I've been very satisfied with it However, I came back to one problem I had back then: The resolution of Up'nDown. Here's what I had for advice back then from Eboshidori:

You should try this :

Code: [Select]
Modeline "224x512"   15.75   224 313 361 480   512 516 519 546  +hsync +vsync

Here you have the resolution of the game with the exact same frame duration as in regular 15 KHz mode:

(480x546) / 15.75 = 16640 ms.

Horizontal frequency is 32.8125 KHz, your monitor should support it.

The complete frame is 546 lines, because if you display the 512 lines of the game within 525 lines (standard for VGA), it may be too short for the sync period. And we must extend the height of the original frame (260 lines) by a little coeficient that works well with the horizontal frequency, so at the end we keep the ratio that gave us the frame duration, and we work with an easy dotclock. Here I choose 1.05 :
520 * 1.05 = 546.

Same for the horizontal freq : the original rate of the game is 15625 Hz, so we first double it (31250) and then multiply it by 1.05.
The width of the frame is 480 pixels, so you can have a picture with a near 3/4 ratio, with black border (normally, it should be centered, but you'll need a few adjustements).


So, avoid interlaced display every time it's possible

Am I supposed to put that modeline in to upndown.ini in ~home/ini/? Or how can I define a custom modeline for a single game (mame) in Linux?

Running the GroovyArcade 64b, Ati X300 and m3129

[Calamity]

Am I supposed to put that modeline in to upndown.ini in ~home/ini/? Or how can I define a custom modeline for a single game (mame) in Linux?

Running the GroovyArcade 64b, Ati X300 and m3129

Correct, just copy the raw modeline into a game specific ini. Just pay attention to writting "modeline" not "Modeline".

However, if you're planning to use that modeline for vertical game on horizontal monitor, be aware it's going to be stretched to full screen, with the wrong aspect ratio.

[emuola]

Am I supposed to put that modeline in to upndown.ini in ~home/ini/? Or how can I define a custom modeline for a single game (mame) in Linux?

Running the GroovyArcade 64b, Ati X300 and m3129

Correct, just copy the raw modeline into a game specific ini. Just pay attention to writting "modeline" not "Modeline".

However, if you're planning to use that modeline for vertical game on horizontal monitor, be aware it's going to be stretched to full screen, with the wrong aspect ratio.

Thanks Calamity, been a while since I've been here Ok...  Naturally I'd like to have the correct aspect ratio... Is there a way to add that to the custom modeline?

Another thing: I decided to fiddle with the crt_ranges once more The reason is that with e.g. 256x240 games like Vs. Mario the right edge of the visible picture (meaning *not* the actual edge of the tube (appr 3 cm from the edge) the graphics "bulge" at the very visible edge of the screen while the screen scrolls to right. This is related to the right edge "squashing" I posted earlier. I tried to move the right edge to the left by increasing the right border. It seems it works pretty well but of course there's now quite a big "empty" area on the right -> a lot of "tube real estate" is not in use even with horizontal games.

Now for the stupid question: There's no point in moving the picture to the right with the monitor controls, right? (to correct the position after increasing the right border)? The bulging will still be there? I mean, if I don't like the bulging, I should just use less of the "tube real estate"?

An another thing related to the huge right border:

I should be able to adjust the granularity of the vertical games by adding

Code: [Select]

display_expand 1.15  in /ini/vertical.ini, right? It doesn't seem to work?

Yeah, I'm lost here

[Calamity]

Hi emuola,

Not sure what you mean by "bulge". A picture would be of great help.

But yes, a proper calibration is often an iterative process: crt_range -> pots -> crt_range -> pots -> ... good enough

In other words: the default adjustment of the pots is not always the "reference" point, they may be shifted initially.

Besides, you'll get better granularity on the horizontal by using "dotclock_min 8.0" in mame.ini.

No sure what you want to achieve with "display_expand".

[emuola]

Hi emuola,

Not sure what you mean by "bulge". A picture would be of great help.

But yes, a proper calibration is often an iterative process: crt_range -> pots -> crt_range -> pots -> ... good enough

In other words: the default adjustment of the pots is not always the "reference" point, they may be shifted initially.

Besides, you'll get better granularity on the horizontal by using "dotclock_min 8.0" in mame.ini.

No sure what you want to achieve with "display_expand".

Ok, here goes By bulging I mean this (sorry, not possible to illustrate without movement). So, I mean the "effect" like the edge of the visible picture acts like the edge of a tube (image gets squashed horizontally), when the screen scrolls to right the objects (e.g. the green towers here) kinda bulge/stretch when they appear. Sorry if I'm sounding completely wacky here

http://sdrv.ms/1bZCnuP

I changed the dotclock-min to 8.0 and now I get completely different switchres values at the info screen when launching a game. A couple of examples:

Super Mariio Bros, dotclock_min 0 gives 256 x 240p, dotclock_min 8.0 gives 512 x 240p
BombJack, dotclock_min 0 gives 400 x 256p, dotclock_min 8.0 gives 800 x 256p (maximum of my monitor is 640 x 480?!)

Is this normal? The image looks very good btw I was just wondering this resolution doubling here...

Thanks again Calamity

[cools]

Normal, and interesting if setting the dotclock min is recommended generally.

The bulging you've described sounds like a brightness problem

[Calamity]

Hi emuola,

We just set a minimum dotclock to force horizontal resolutions below a certain limit to be doubled (x2). This causes zero degradation to the picture and has the effect to double the accuracy on the calculations regarding horizontal porches, so the result is better horizontal centering (on average).

The issue where the picture gets compressed on the borders is a typical one of CRT monitors. But you should expect it to be symmetrical. If this is not the case, it may have to do with the horizontal linearity adjustment (in case the monitor has one).

But honestly I don't think that's a severe case, at least what I get from that video. You usually test this stuff with a grid pattern. I'd just shrink the right border to the max, even leaving a bit of overscan to the right, to fill the whole phosphor real state, and live with it.

[emuola]

Hi emuola,

We just set a minimum dotclock to force horizontal resolutions below a certain limit to be doubled (x2). This causes zero degradation to the picture and has the effect to double the accuracy on the calculations regarding horizontal porches, so the result is better horizontal centering (on average).

The issue where the picture gets compressed on the borders is a typical one of CRT monitors. But you should expect it to be symmetrical. If this is not the case, it may have to do with the horizontal linearity adjustment (in case the monitor has one).

But honestly I don't think that's a severe case, at least what I get from that video. You usually test this stuff with a grid pattern. I'd just shrink the right border to the max, even leaving a bit of overscan to the right, to fill the whole phosphor real state, and live with it.

Ok, thank again Calamity The dotclock_min=8.0 makes the screen center better, that's true  I'll try to make the image so that there's even a little overscan. If it requires adjusting the monitor, It'll take a few days, because I have to open my cab (remove the back) to be able to adjust the monitor settings (and removing the back means a lot of work). I'll report here as I progress in my quest for a perfect crt