crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come)

[Riverstorm]

@caver01 said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

I think it is an approximation to simplify the ratio to get 1.7 like you noted. 384/224 is about 1.7, and 5.1/3 is exactly 1.7.

Ok, that makes sense. Even rounded out it still carries a zero out to the thousandths.

How does Dank's example work when it's using the same width x height. Is this a really "skewed" PAR to pull off a 16:9?

something like street fighter 2 has a resolution of 384x224, which is a wide image - close to 16:9. however it was on a regular 4:3 CRT just like most other arcade games, so should be 4:3 via the script/emulators.

[caver01]

@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

Wow, almost smack dab in the middle. That's where you start expanding the script to make exceptions for thresholds beyond a certain percentage or pixel count. Hmmm...black borders or strreeetch!

Actually, the subjective decision is, black borders, stretch one way, stretch the other way, or simply live with a little bit of rainbow lines.

For me, I might live with some distortion, as I hate the rainbow lines, but I also like curvature which has its own problems with moire patterns and a lot of this careful scaling goes out the window.

Most vertical games for my setup end up in tate mode for me which introduces the same problems, just a different target display. It all becomes subjective on my box.

[caver01]

@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

How does Dank's example work when it's using the same width x height. Is this a really "skewed" PAR to pull off a 16:9?

I think the current era of widescreen TVs have done more to confuse people about how a game like Street Fighter II is supposed to look. In his example, this is a game whose PAR is not at all square. It was programmed at a seemingly widescreen AR, yet people forget that the target display for these games was always a 4:3 CRT monitor. That meant that a technician setting up the actual cabinet would probably turn a tuning knob to stretch the game to fit into the 4:3 screen, even though the pixels would change shape. In doing so, however, the character proportions are restored. In other words, the artwork in the game would be put back to "normal", since it was created with distortion to begin with knowing it would be tuned back to 4:3.

Research might reveal why a game like this was created with such a wide AR, but I would expect there are good reasons for doing so. It might be memory limitations, or an opportunity to maximize resolution in at least one dimension over another. Who knows. It's actually not unlike a cinematographer using an anamorphic lens to capture a wide image to the full size of a 35mm negative, even though it will be projected in a different AR. What we have in SF2 is a distorted game as programmed, designed to be stretched back to 4:3. The fact that the programmed distortion is close to a widescreen TV AR is a coincidence.

A game like Blasteroids is even more severe if I remember correctly.

[dankcushions]

my script gets as close as it can to the DAR always. so for sf2 it doesn’t care about the aspect ratio of the pixels (~16:9), only the aspect ratio of the screen (4:3).

check out my zip downloads in original post - the cfgs for sf2 will be as close to 4:3 as it can get. no one wants a fat Ryu.

[Riverstorm]

@andrewh said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

pixelSquareness = ((gameWidth/gameHeight)/aspectRatio)

In @AndrewH script he has these lines:

pixelSquareness = ((gameWidth/gameHeight)/aspectRatio)

pixelSquareness = (384 / 224) / 1.7 = 1.00

I think it is an approximation to simplify the ratio to get 1.7 like you noted. 384/224 is about 1.7, and 5.1/3 is exactly 1.7.

Is it coincidental that this work out to 1? It seems (gamewidth/gameheight) & aspectratio need to be from two different sources or the division will always be 1 which I thought the point was 1941 doesn't use square pixels.

I don't know if I am using incorrect numbers by dividing 5.1/3 but I don't see where the exact ratio 5.1:3 is coming from and the math (probably incorrectly) shows it to be a square pixel if I understand it correctly.

1941, 384, 224,V,R, 810, 1080, 576, 768, 3, 4, 60

no one wants a fat Ryu.

For sure, in the black suit we have Rotund Ryu! :)

[caver01]

@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

In @AndrewH script he has these lines:

pixelSquareness = ((gameWidth/gameHeight)/aspectRatio)

I don't think aspectRatio here is the calculated value you have. It has to be either the target AR which is should be 4:3 or the AR of the scaled viewport that uses x-axis integer scale and Y display height. Otherwise, yeah, it would always be 1.

[Riverstorm]

@caver01 said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

It has to be either the target AR which is should be 4:3 or the AR of the scaled viewport that uses x-axis integer scale and Y display height.

Maybe @AndrewH can clarify where that value comes from. I don't think it would be the latter as it's needed to calculate gamewidth or gameheight depending on the orientation.

[AndrewH]

How are you calculating the ratio 5.1:3?

So, @Riverstorm sorry about any confusion caused.

384/224 = 1.7143 (or a ratio of 1.7143:1)

That's the same as (1.7143 *3) : (1 *3) , or 5.143:3 (rounded to 5.1 for the sake of the post)
I just wanted to represent it as a <something>:3 ratio, to show how it compared to the screen aspect ratio, which is 4:3

Your working through the example is not exactly correct - the aspectRatio value is taken from the DB entry - the 10th and 11th entries respectively are the Game Screen Aspect Ratio (just titled aspectRatio in the script). So, it should be more like this (for 1600 x 1200 screen) ;

1941, 384, 224,V,R, 810, 1080, 576, 768, 3, 4, 60

pixelSquareness = (224 / 384) / (3 / 4)  = 0.77778   # We've swapped width and height because it's a vertical game

gameHeight = int(384 * 0.77778) = 298    # This is the pixel height if we had a real 4:3 ratio.  You can also calculate it just by multiplying 224 by 4/3

vScaling = 1200/298 = 4.02                # How many times taller is the screen than the game (with corrected pixel size)?
hScaling = 1600/224 = 7.143             # How many times wider is the screen than the game?

intScaleFactor = 4                        # Take the integer value of the lower scale value

viewportWidth = 224 * 4 = 896
viewportHeight = 1200

viewportX = 352
viewportY = 0

[AndrewH]

@caver01 said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

In @AndrewH script he has these lines:

pixelSquareness = ((gameWidth/gameHeight)/aspectRatio)

I don't think aspectRatio here is the calculated value you have. It has to be either the target AR which is should be 4:3 or the AR of the scaled viewport that uses x-axis integer scale and Y display height. Otherwise, yeah, it would always be 1.

Yes - it's the Aspect Ratio from the DB file, which is the 10th and 11th entries on the line (they're indexed from 0, which is why it's [9] and [10] in the code.

aspectRatio = int(gameInfo[9]) / int(gameInfo[10])

[caver01]

@AndrewH I thought so. It seems you happened to find a few examples where Dank's script overlooked a better viewport because sizing up one more was still within the 25% tolerance. I probably just restated when you wrote originally. There may be some sweet spot tolerance levels to avoid this situation, but I think it will depend on the games and the resolutions of our displays.

[Riverstorm]

@AndrewH Ah, thanks for the clarification. One question if I am understanding what you're doing is pixels are added or subtracted depending on the pixelsquareness to compensate for the PAR into the final resolution? To me that's the only way say for example a 16:9 PAR (not resolution) fits a 4:3 DAR and still looks correct? Not sure how to word it.

I'm trying to wrap my head around how modern displays being square pixels but still compensate for odd PAR's and the image still looks correct unless the emulator is somehow making additional "corrections".

[AndrewH]

@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

@AndrewH Ah, thanks for the clarification. One question if I am understanding what you're doing is pixels are added or subtracted depending on the pixelsquareness to compensate for the PAR into the final resolution? To me that's the only way say for example a 16:9 PAR (not resolution) fits a 4:3 DAR and still looks correct? Not sure how to word it.

Yes - pretty much.

For vertical games, the goal is to keep the width unchanged (since this is the one we want integer scaling on), and recalculate the height in order to 'correct' the PAR to fit the DAR of 3:4 )

For horizontal games, the goal is to keep the height unchanged and recalculate the width before proceeding to work out the scale factor to be applied.

I'm trying to wrap my head around how modern displays being square pixels but still compensate for odd PAR's and the image still looks correct unless the emulator is somehow making additional "corrections".

I presume there are some similar calculations going on in the background unless overridden by these .cfg files.

Speaking of modern displays having square pixels - they almost all do, apart from 1280 x 1024. That's a ratio of 5:4, but on a 4:3 screen.

[AndrewH]

In case anyone's still interested, here's a worked example for Street Fighter 2, which also has an odd PAR, as noted above:

From resolution_db

sf2,384,224,H,R,1440,1080,1196,896,4,3,60

pixelSquareness = (384 / 224) / (4 / 3)  = 1.285714   

gameWidth = int(384 / 1.285714) = 298    # This is the pixel width if we had a real 4:3 ratio.  You can also calculate it just by multiplying 224 by 4/3

vScaling = 1200/224 = 5.357                # How many times taller is the screen than the game (with corrected pixel size)?
hScaling = 1600/298 = 5.369                # How many times wider is the screen than the game?

intScaleFactor = 5                        # Take the integer value of the lower scale value

viewportWidth = int(298 * 5.369) = 1596   =~ 1600    # Round up to 1600, since it's less than 10 pixels smaller than the screen width
viewportHeight = 224 * 5 = 1120

viewportX = 0
viewportY = 40

In this example the pixelSquareness works out as the reciprocal of that for 1941. So the recalculated game width ends up the same as the recalculated game height for 1941.

[caver01]

@andrewh said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

apart from 1280 x 1024. That's a ratio of 5:4, but on a 4:3 screen.

Of course, this is what I run on my system! But I have not measured the physical dimensions. Is it 4:3? If so the pixels are wider than they are tall. Mine is a Sony, and I have seen specs like: "1280 x 1024 (5:4/Square Aspect Ratio)" which makes me think my display is not physically 4:3, but true to resolution with a 1:1 PAR.

[AndrewH]

@caver01 said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

@andrewh said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

apart from 1280 x 1024. That's a ratio of 5:4, but on a 4:3 screen.

Of course, this is what I run on my system! But I have not measured the physical dimensions. Is it 4:3? If so the pixels are wider than they are tall. Mine is a Sony, and I have seen specs like: "1280 x 1024 (5:4/Square Aspect Ratio)" which makes me think my display is not physically 4:3, but true to resolution with a 1:1 PAR.

You're right - it is a 5:4 screen, not 4:3 as I'd wrongly assumed. I've got a Dell 1907 in my bartop, which I've just measured as around 377 x 303mm, which also works out as 5:4.

So, thankfully, the pixels are square and no further messing about with figures is needed :-)

[Riverstorm]

Ok, I think I am square now! ;)

Can you explain one last thing. I don't quite understand the comment below. If it was a real 4:3 monitor wouldn't the dimensions be 224 x 384 scaled with whole numbers because you're actually running a real 4:3 monitor? Why the change from 384 to 298?

This is the pixel height if we had a real 4:3 ratio. Why 298?

Also any you guys explain what happens when not using custom configs? This seems like logical thing to do but I take it something different happens but still fills the screen. I've been using Dank's configs since I made the jump to mame2003.

[caver01]

@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

Also any you guys explain what happens when not using custom configs? This seems like logical thing to do but I take it something different happens but still fills the screen. I've been using Dank's configs since I made the jump to mame2003.

Scroll back up to the first message in this thread. Not using the configs with the CRT-PI shader and you can get rainbow lines because it is not integer scaling in the dimension it needs to in order to make the shader look nicer. It's not a bad problem, just distracting. I live with it actually, because I like fullscreen and curvature. I guess I don't notice it that much, but having the config option is really clever.

[AndrewH]

@riverstorm said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

Ok, I think I am square now! ;)

Can you explain one last thing. I don't quite understand the comment below. If it was a real 4:3 monitor wouldn't the dimensions be 224 x 384 scaled with whole numbers because you're actually running a real 4:3 monitor? Why the change from 384 to 298?

This is the pixel height if we had a real 4:3 ratio. Why 298?

It's because the pixels in the original game would not have been square. But on modern displays, the pixels are square. So if we don't account for the non-squareness of the pixels, we'll end up with a game that's stretched.

To test this, you can do the following;

Edit your 1941.cfg file and put in the following values;

custom_viewport_width = "448"
custom_viewport_height = "768"
custom_viewport_x = "0"
custom_viewport_y = "0"

Never mind that it's small and off-centre, this is just for testing purposes. You should see that the game appears vertically stretched when we do a simple 2x scaling on both axes. If instead you take the height as 298 rather than 384 and do the same 2x scaling, you'll see that it's correctly proportioned;

custom_viewport_width = "448"
custom_viewport_height = "596"
custom_viewport_x = "0"
custom_viewport_y = "0"

So, we're not really scaling the game vertically by 2x - we're scaling it vertically by 1.55 (384 x 1.55 = 596), and that corrects for the difference in 'squareness' of the pixels between the game and the modern screen.

[Riverstorm]

@andrewh said in crt-pi shader users - reduce scaling artifacts with these configs in lr-mame2003, lr-fbalpha, lr-nestopia (and more to come):

So, we're not really scaling the game vertically by 2x - we're scaling it vertically by 1.55 (384 x 1.55 = 596), and that corrects for the difference in 'squareness' of the pixels between the game and the modern screen.

Ah, nice ok, so the calculations are compensating for odd PARs. I didn't fully understand it but I think I'm on the train now. I appreciate you taking the time to explain that with the examples helped quite a lot. Kudo's to Dank for building the script. There's a bit of complexity there figuring all that out.

Not using the configs with the CRT-PI shader and you can get rainbow lines because it is not integer scaling in the dimension it needs to in order to make the shader look nicer.

So it basically it fills the screen disregarding any type of integer scaling which would makes sense for MAME. Being one of the most extensive and longest running projects on so many display types (traditional and modern) to not make assumptions on if to scale output and to what resolution.

There's a small difference. My script will always keep the viewport within the bounds of the display, whereas Dank's may in some circumstances allow it to overspill a little in order to use more screenspace.

Are you saying some games will be clipped (off the edge of the screen) vertically or horizontally?

[dankcushions]

my script will never overspill the edge of the screen. i thought about letting that happen to a certain tolerance but arcade games tend to have important stuff right to the edge of the image, since the cabinet CRT would be calibrated to each game, compared to console games which had to deal with varying consumer tv overscan capabilities.