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

[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.

[caver01]

@riverstorm

@AndrewH 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?

This confused me a bit too. I didn't think the original script from Dankcushions would actually crop the video, but that it still uses the display max to "squeeze" the non-integer dimension it back into view. This is no worse than being under by some pixels and stretching to the display limit, it is just the opposite distortion. The key is finding which one looks better: over/compressed or under/stretched.

It looked to me that one example could allow over and compressed because it fell within the tolerance, when an under/stretch was distorted less.

[caver01]

Seems like the best script would be one that measures the distortion with each integer scale and selects the one that distorts the least. No threshold necessary.

[dankcushions]

maybe it overspills the x axis with 4:3 displays since i never tested for that ;) with the widescreen hdtv i made it for it has plenty of room on the X axis!

[dankcushions]

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

Seems like the best script would be one that measures the distortion with each integer scale and selects the one that distorts the least. No threshold necessary.

i don’t agree. that’s how mine used to work but i changed it to pick the wider one (within a certain low tolerance) as it looks better to stretch than to squeeze on a widescreen display (up to a point, hence the tolerance variable). if you set tolerance to 0 then it won’t do that.

[caver01]

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

i don’t agree. that’s how mine used to work but i changed it to pick the wider one (within a certain low tolerance) as it looks better to stretch than to squeeze on a widescreen display (up to a point, hence the tolerance variable). if you set tolerance to 0 then it won’t do that.

That does sound close to perfect then, as it takes into account some subjectivity while my idea (your original idea) is very rigid. However, the example above where the lower version is literally just 4 pixels smaller than perfect--it seems like it should have picked the lower, as it would be almost visually perfect, yet according to @AndrewH it picked the upper. Is the tolerance compared against the lower or the upper?

[dankcushions]

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

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

i don’t agree. that’s how mine used to work but i changed it to pick the wider one (within a certain low tolerance) as it looks better to stretch than to squeeze on a widescreen display (up to a point, hence the tolerance variable). if you set tolerance to 0 then it won’t do that.

That does sound close to perfect then, as it takes into account some subjectivity while my idea (your original idea) is very rigid. However, the example above where the lower version is literally just 4 pixels smaller than perfect--it seems like it should have picked the lower, as it would be almost visually perfect, yet according to @AndrewH it picked the upper. Is the tolerance compared against the lower or the upper?

you'll have to show me the/an example in my own generated .cfgs from the original post. some of the examples above were generated via an older version of python, and/or a lower resolution 4:3 screen which my script needs a lowered tolerance value to work with. IMO you shouldn't bother with scanline shaders on sub-HD screens anyway!

some of the examples were generated with an edited version of the script!!

i have now definitely spent more time explaining this script than writing it ;)

[Riverstorm]

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

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

That was my thought. There's nothing worse than playing a game and the top half of the score is "clipped".

i have now definitely spent more time explaining this script than writing it ;)

I have to say I've learned quite a bit from the whole discussion but continuing to beat on 1941. This statement below would actually be false and not true.

There's then a check to see whether the new scale is within the tolerance

>if ((widerAspect - aspectRatio)/aspectRatio * 100) <= tolerance:
    viewportWidth = int(gameWidth * (scaleX + 1))

Using the figures above :
(0.9333-0.7466)/0.7466 * 100 = 25
So, the horizontal scale value of 5 gives a result that's bang on the tolerance, and therefore used, even though this gives an aspect ratio that's much further from the original.

The actual value will be 25.006 (continuing on). That value would not be <= due to the fractional part so 896 should still be used?

Working with whole numbers 896 is exactly 25% less then 1120 which is exactly 224 pixels which is the original width of the game? Whether that's a coincidence or an actual percentage for tolerance I don't know.

[AndrewH]

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

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.

It does, I'm afraid - for non-widescreen aspect ratios (i.e. 4:3 and 5:4).

Below is a slightly modified version of your script - the only change is that it also creates a .csv file in the directory it is run in, which has the following columns;
Name,X,Y,Orientation,Aspect1,Aspect2,ViewportWidth,ViewportHeight,HorizontalOffset,VerticalOffset
All of the games, with their original and scaled sizes will be listed.

If it's run with the following command line, 361 of the 4646 games have a negative vertical offset - meaning they exceed the screen area.
python3 crt_pi_configs.py mame2003 1600 1200

Running for 1280 x 1024 gives 104 games with negative vertical offset.

Setting the tolerance to 0 doesn't reduce the number of games with negative offsets.

But running it for 1920 x 1080, 1280 x 720, or 1366 x 768 gives no games with negative vertical offset.

# creates cfg files for crt-pi
# params are:
# * core (eg mame2003 or fbalpha)
# * screen width (eg 1920) OR curvature
# * screen height (eg 1080)
# example usage:
# python crt_pi_configs.py mame2003 1920 1080
# python crt_pi_configs.py fbalpha 1920 1080
# python crt_pi_configs.py consoles 1920 1080
# python -c "import crt_pi_configs; crt_pi_configs.createZip(False,1920,1080)"

import sys
import os
import shutil


def generateConfigs(arg1, arg2, arg3):
    console = False
    if "mame2003" in arg1:
        fileName = "resolution_db/mame2003.txt"
        coreName = "MAME 2003"
    elif "fbalpha" in arg1:
        fileName = "resolution_db/fbalpha.txt"
        coreName = "FB Alpha"
    elif "consoles" in arg1:
        fileName = "resolution_db/consoles.txt"
        console = True

    if "curvature" in arg2:
        curvature = True
    else:
        curvature = False
        screenWidth = int(arg2)
        screenHeight = int(arg3)
        screenAspectRatio = screenWidth / screenHeight
        tolerance = 25
        resolution = str(screenWidth) + "x" + str(screenHeight)

    resolutionDbFile = open(fileName, "r" )
    print("opened file {}".format(fileName))
    
    outputFile = open(resolution + ".csv", "w")
    outputFile.write("Name,X,Y,Orientation,Aspect1,Aspect2,ViewportWidth,ViewportHeight,HorizontalOffset,VerticalOffset\n")

    for gameInfo in resolutionDbFile:
    	# strip line breaks
        gameInfo = gameInfo.rstrip()
        
        # parse info
        gameInfo = gameInfo.split(",")
        gameName = gameInfo[0]
        gameOrientation = gameInfo[3]
        gameWidth = int(gameInfo[1])
        gameHeight = int(gameInfo[2])
        aspectRatio = int(gameInfo[9]) / int(gameInfo[10])
        gameType = gameInfo[4]
        #integerWidth = int(gameInfo[7])
        #integerHeight = int(gameInfo[8])

        if console:
            coreName = gameName

        cfgFileName = gameName + ".cfg"

        # Create directory for cfgs, if it doesn"t already exist
        if curvature:
            path = "curvature" + "/" + coreName
        else:
            path = resolution + "/" + coreName
        if not os.path.isdir(path):
            os.makedirs (path)

        # create cfg file
        print("creating {}/{}".format(path,cfgFileName))
        newCfgFile = open(path + "/" + cfgFileName, "w")

        if "V" in gameType:
            # Vector games shouldn"t use shaders, so clear it out
            newCfgFile.write("# Auto-generated vector .cfg\n")
            newCfgFile.write("# Place in /opt/retropie/configs/all/retroarch/config/{}/\n".format(coreName))
            newCfgFile.write("video_shader_enable = \"false\"\n")

        else:
            if "V" in gameOrientation:
                if curvature:
                    shader = "crt-pi-curvature-vertical.glslp"
                else:
                    shader = "crt-pi-vertical.glslp"
                # flip vertical games
                gameWidth = int(gameInfo[2])
                gameHeight = int(gameInfo[1])

            elif "H" in gameOrientation:
                if curvature:
                    shader = "crt-pi-curvature.glslp"
                else:
                    shader = "crt-pi.glslp"

            newCfgFile.write("# Auto-generated {} .cfg\n".format(shader))
            newCfgFile.write("# Place in /opt/retropie/configs/all/retroarch/config/{}/\n".format(coreName))
            newCfgFile.write("video_shader_enable = \"true\"\n")
            newCfgFile.write("video_shader = \"/opt/retropie/configs/all/retroarch/shaders/{}\"\n".format(shader))

            if not curvature:
                # if not perfectly integer scaled, we will get scaling artefacts, so let"s fix that
                if screenAspectRatio > aspectRatio:
                    # games with an aspect ratio smaller than your screen should be scaled to fit vertically
                    newCfgFile.write("# To avoid horizontal rainbow artefacts, use integer scaling for the width\n")

                    # build list of potential aspect ratios with different integer scales
                    aspectRatios = []
                    for scaleX in range(1, 99):
                        aspectRatios.append((scaleX * gameWidth) / screenHeight)

                    # find closest integer scale to desired ratio
                    aspectRatios.reverse()
                    scaleX = 98-aspectRatios.index(min(aspectRatios, key=lambda x:abs(x-aspectRatio)))

                    viewportWidth = int(gameWidth * scaleX)
                    if console:
                        # consoles have overscan, so adjust viewportHeight to "Title Safe Area"
                        if "Nestopia" in coreName:
                            overscanV = 8
                        else:
                            overscanV = 0

                        # build list of potential aspect ratios with different integer scales
                        aspectRatios = []
                        for scaleY in range(1, 99):
                            aspectRatios.append(viewportWidth / (scaleY * gameHeight))

                        # find closest integer scale to desired ratio
                        aspectRatios.reverse()
                        scaleY = 98-aspectRatios.index(min(aspectRatios, key=lambda x:abs(x-aspectRatio)))

                        viewportHeight = screenHeight + (overscanV * scaleY)
                    else:
                        viewportHeight = screenHeight

                    # we prefer it to be wider than narrower, so do that, according to tolerance
                    newAspect = viewportWidth / viewportHeight
                    if newAspect < aspectRatio:
                        widerAspect = (gameWidth * (scaleX + 1)) / screenHeight
                        if ((widerAspect - aspectRatio)/aspectRatio * 100) <= tolerance:
                            viewportWidth = int(gameWidth * (scaleX + 1))

                    # centralise the image
                    viewportX = int((screenWidth - viewportWidth) / 2)
                    viewportY = int((screenHeight - viewportHeight) / 2)

                else:
                    # games with an aspect ratio larger than your screen should be scaled to fit horizontally
                    newCfgFile.write("# To avoid horizontal rainbow artefacts, use integer scaling for the height\n")
                    
                    # build list of potential aspect ratios with different integer scales
                    aspectRatios = []
                    for scaleX in range(1, 99):
                        aspectRatios.append(screenWidth / (scaleX * gameHeight))

                    # find closest integer scale to desired ratio
                    aspectRatios.reverse()
                    scaleY = 98-aspectRatios.index(min(aspectRatios, key=lambda x:abs(x-aspectRatio)))

                    viewportWidth = screenWidth
                    viewportHeight = int(gameHeight * scaleY)
                    
                    # centralise the image
                    viewportX = 0
                    viewportY = int((screenHeight - viewportHeight) / 2)

                newCfgFile.write("aspect_ratio_index = \"22\"\n")
                newCfgFile.write("custom_viewport_width = \"{}\"\n".format(viewportWidth))
                newCfgFile.write("custom_viewport_height = \"{}\"\n".format(viewportHeight))
                newCfgFile.write("custom_viewport_x = \"{}\"\n".format(viewportX))
                newCfgFile.write("custom_viewport_y = \"{}\"\n".format(viewportY))

                outputFile.write("{},{},{},{},{},{},{},{},{},{}\n".format(gameInfo[0],gameInfo[1],gameInfo[2],gameInfo[3],gameInfo[9],gameInfo[10],viewportWidth,viewportHeight,viewportX,viewportY))

        newCfgFile.close()

    resolutionDbFile.close()
    outputFile.close()

def createZip(curvature=False, screenWidth=0, screenHeight=0):
    if curvature:
        outputFileName = "crt-pi-curvature_configs"
        path = "curvature"
    else:
        resolution = str(screenWidth) + "x" + str(screenHeight)
        outputFileName = "crt-pi_configs_" + resolution
        path = resolution
    outputFileName = outputFileName.replace(" ", "")
    outputFileName = outputFileName.lower()

    print("Creating zipfile {}".format(outputFileName))
    shutil.make_archive(outputFileName, "zip", path)

    # now delete config dirs
    print("Deleting temp directory: {}".format(path))
    shutil.rmtree(path)


if __name__ == "__main__":
    generateConfigs(sys.argv[1], sys.argv[2], sys.argv[3])

[AndrewH]

Using the figures above :
(0.9333-0.7466)/0.7466 * 100 = 25
So, the horizontal scale value of 5 gives a result that's bang on the tolerance, and therefore used, even though this gives an aspect ratio that's much further from the original.

The actual value will be 25.006 (continuing on). That value would not be <= due to the fractional part so 896 should still be used?

There's some rounding going on with those figures - they're there for display purposes only :-)

Working with whole numbers 896 is exactly 25% less then 1120 which is exactly 224 pixels which is the original width of the game? Whether that's a coincidence or an actual percentage for tolerance I don't know.

That's the crux of the problem - the aspect ratio using a width of 896 is slightly smaller than the original, and by coincidence the next value up is 25% bigger, which is bang on the tolerance that's set in the script by default, so it gets used even though it's quite far from the original aspect ratio.

[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):

There's some rounding going on with those figures - they're there for display purposes only :-)

That was kind of the point. By rounding it changed the statement from false to true? 25.006 is not <= 25 so the check is actually false and it would use the proper value of 896 which disregards the point for that example.

[dankcushions]

@andrewh

But running it for 1920 x 1080, 1280 x 720, or 1366 x 768 gives no games with negative vertical offset.

right - i didn’t test or design it for non-widescreen displays. if anyone wants to fix that please send a PR on git. i had a limited goal for the script and i reached that, but if anyone wants to add anything to it, that’s cool!

i don’t even use shaders anymore!

[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):

That's the crux of the problem - the aspect ratio using a width of 896 is slightly smaller than the original, and by coincidence the next value up is 25% bigger, which is bang on the tolerance that's set in the script by default, so it gets used even though it's quite far from the original aspect ratio.

Setting the tolerance to 0 doesn't reduce the number of games with negative offsets.

Can you explain the issue a little more? If tolerance of 25 or 0 yields the same results. It doesn't sound like the tolerance check is what's failing?

[Riverstorm]

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

i had a limited goal for the script and i reached that

That will teach them for using old school monitors and true CRTs for retro gaming! Traditional vs contemporary! :)

It's about 13% of the games that will be off, hopefully none of the major ones. I imagine Andrew has the issue so well defined he can, well has, already hacked the script and fixed the issue.

[dankcushions]

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

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

i had a limited goal for the script and i reached that

That will teach them for using old school monitors and true CRTs for retro gaming! Traditional vs contemporary! :)

It's about 13% of the games that will be off, hopefully none of the major ones. I imagine Andrew has the issue so well defined he can, well has, already hacked the script and fixed the issue.

it's not CRTs - if you're using a CRT you should be using native 240p or whatever so you get natural scanlines. you don't need a shader!

~4:3 monitors, sure. there appears to be an issue there. PRs welcome!

[Riverstorm]

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

~4:3 monitors, sure. there appears to be an issue there.

4:3 and 4:5 monitors so far.

PRs welcome!

Just doing a quick look through the script. That looks like a full blown programming language. You wrote that whole thing yourself? I'm impressed. I think that it would take me several weeks looking up & fighting with syntax of commands let alone concepts of the script. Writing & knowing the code intimately I take it you figure the issue is harder to solve then a quick 1 or 2 line tweak.

There's a lot of programming concepts that most (non-programmers) wouldn't understand or even make sense that require some study to understand. Maybe a quick reference guide for commands & syntax might help or I guess nowadays Google handy on the left. It's slow going when first learning a language but having any programming experience sure expedites the process as the fundamentals are the same it's just knowing the syntax.

It doesn't affect me at all so I am happy how it is too! It sounds like Caver don't use the script either so it depends if Andrew feels like forking and fixing! ;)

Actually I think Andrew would get to the heart of the issue quicker if it's worth fixing and is a hacking maniac but if he needs help with anything I will do what I can. It's been a while since I did any true programming like COBOL, RPG, Fortran, BASIC and some C when I was with the public school systems & then UPS like 20 odd years ago (mostly stuff no-one uses anymore) but the script doesn't look to bad.

[caver01]

@riverstorm I looked at the script too and I think I see where the potential issue is. There is a conditional—the place where it says that we like to expand wider more than we like to be narrower. It is here that it does the tolerance comparison that @AndrewH cited above. The first problem is that it needs an additional condition—one that checks to see if the recalculated viewport width (gameWidth * (scaleX +1)) would exceed screenWidth before proceeding. That would solve the viewport cropping.

The second issue is that it simply favors any version of the AR that is wider (within tolerance, of course), even though the narrower factor might come within a few pixels of a perfect aspect ratio. It seems like the tolerance should be compared against the narrow version, not the wide one. And yet, I still think there is an element of subjectivity here. I might even be willing to add some black bars to the border (again, within a certain tolerance) if it let me avoid heavy distortion.

I think the real benefit here was that @dankcushions realized that you can eliminate shader artifacts by forcing integer scaling in one dimension only. We always knew that full integer scaling would solve both AR and shader issues, but being able to live with some distorition in one dimension to take advantage of more screen area was a fantastic insight. But as always with our build projects, one size rarely fits all.

[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):

@riverstorm I looked at the script too and I think I see where the potential issue is. There is a conditional—the place where it says that we like to expand wider more than we like to be narrower. It is here that it does the tolerance comparison that @AndrewH cited above. The first problem is that it needs an additional condition—one that checks to see if the recalculated viewport width (gameWidth * (scaleX +1)) would exceed screenWidth before proceeding. That would solve the viewport cropping.

The second issue is that it simply favors any version of the AR that is wider (within tolerance, of course), even though the narrower factor might come within a few pixels of a perfect aspect ratio. It seems like the tolerance should be compared against the narrow version, not the wide one. And yet, I still think there is an element of subjectivity here. I might even be willing to add some black bars to the border (again, within a certain tolerance) if it let me avoid heavy distortion.

I think the real benefit here was that @dankcushions realized that you can eliminate shader artifacts by forcing integer scaling in one dimension only. We always knew that full integer scaling would solve both AR and shader issues, but being able to live with some distorition in one dimension to take advantage of more screen area was a fantastic insight. But as always with our build projects, one size rarely fits all.

I agree this is an incredible insight doing single axis scaling to correct the rainbow effects. I don't mean to be to open or blunt as I tend to be.

They way I understand it after this discussion is there's a few pieces of key information. The original DAR (resolution), the aspect ratio, orientation & target DAR (resolution).

It seems the PAR can be calculated from the resolution and aspect ratio. Similar to a TV. The PAR is used to calculate a "modified" height/width that is used to fit the target DAR. Without taking the original PAR into account some games (that aren't 1:1) are going to be off visually on a modern display with square pixels.

A quick look through the script it doesn't look like the PAR isn't taken into account at all? It's calculating scaling from 1 to 99 in both dimensions and then goes through comparing all of them looking for the best aspect ratio within the tolerance. It's very well written.

The use of the key function (lambda), data structures ( aspectRatios = []), reverse method (aspectRatios.reverse()), absolute function, etc. just seems like this is an incredibly efficient and well written script I was just wondering if it was a collaboration with someone that knows a bit of programming or just natural talent.

If @AndrewH maybe shares an example or two of negative offsets I think that will help.

[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):

If @AndrewH maybe shares an example or two of negative offsets I think that will help.

I do plan to put some more work into this, ultimately with the goal of making a proper contribution to the script. But I'm kinda learning Python as I go here.

Of the 361 games that go beyond the vertical screen area (for 1600 x 1200 screen), 346 of them are horizontal and 15 are vertical. The 15 vertical would be an easy fix, but the horizontal ones need to use the next scaling factor below what's currently being computed by Dank's method, and I'm not sure how to do that at the moment.

Here are some examples where, even with a tolerance of 0, the viewport size is set beyond the screen area;

Tolerance : 	0								
Name	X	Y	Orientation	Aspect1	Aspect2	ViewportWidth	ViewportHeight	HorizontalOffset	VerticalOffset
ace	336	304	H	4	3	1600	1216	0	-8
aceattac	320	224	V	4	3	1600	1280	0	-40
acedrvrw	640	480	H	4	3	1600	1440	0	-120
afighter	320	224	V	4	3	1600	1280	0	-40
airco22b	640	480	H	4	3	1600	1440	0	-120
aircombj	496	480	H	4	3	1600	1440	0	-120
aircombu	496	480	H	4	3	1600	1440	0	-120
alpinerc	640	480	H	4	3	1600	1440	0	-120
alpinerd	640	480	H	4	3	1600	1440	0	-120
amerdart	322	241	H	4	3	1600	1205	0	-2
aquarium	320	256	H	4	3	1600	1280	0	-40
aquarush	640	480	H	4	3	1600	1440	0	-120
archriv2	512	480	H	4	3	1600	1440	0	-120
archrivl	512	480	H	4	3	1600	1440	0	-120
ashnojoe	288	208	H	4	3	1600	1248	0	-24
athena	288	216	H	4	3	1600	1296	0	-48
battlera	1088	242	H	4	3	1600	1210	0	-5
bchopper	384	256	H	4	3	1600	1280	0	-40
bcrusher	240	256	H	4	3	1600	1280	0	-40
beaminv	248	216	V	4	3	1600	1240	0	-20
beastrzb	640	480	H	4	3	1600	1440	0	-120

[AndrewH]

@dankcushions, I've done a (fair) bit more work and created an alternative version of your script - was wondering whether you'd consider including it in your git project.
Main features;

• Checks for Python 3 and exits if not found
• Creates a .csv 'log' file showing the viewport size and position created for each game (handy to check for odd values)
• Includes additional information in the header of each .cfg generated, with details of game name, original resolution, aspect ratio, and whether either of the two new options detailed below were enabled. Also includes the target screen resolution.
• Adds two new optional command line arguments which can be used individually or together;
  • w - widen vertical games scaling factor by 1
  • a - use only integer scaling on both axes
• It also uses the approach that I had outlined previously (calculating the scale factors directly, rather than indexing them)

I've tested it pretty extensively using the more common resolutions - both widescreen and non-, and I'm happy enough with the output and stability.

crt_pi_configs_alt.py

# creates cfg files for crt-pi
# params are:
# * core (eg mame2003 or fbalpha)
# * screen width (eg 1920) OR curvature
# * screen height (eg 1080)
# * optional flags (w: widen, a: accurate) - use either or both, with no space between
#       widen : Increase horizontal scaling of vertical games by 1
#       accurate : Use only integer scaling for both horizontal and vertical dimensions
# example usage:
# python crt_pi_configs_alt.py mame2003 1920 1080
# python crt_pi_configs_alt.py fbalpha 1920 1080
# python crt_pi_configs_alt.py consoles 1920 1080
# python -c "import crt_pi_configs_alt; crt_pi_configs_alt.createZip(False,1920,1080)"

import sys
import os
import shutil

def generateConfigs(arg1, arg2, arg3, arg4):
    console = False
    if "mame2003" in arg1:
        fileName = "resolution_db/mame2003.txt"
        coreName = "MAME 2003"
    elif "fbalpha" in arg1:
        fileName = "resolution_db/fbalpha.txt"
        coreName = "FB Alpha"
    elif "consoles" in arg1:
        fileName = "resolution_db/consoles.txt"
        coreName = "Console"
        console = True

    if "w" in arg4:
        widen = "true"
        print("Widening of vertical games enabled")
    else:
        widen = "false"
    
    if "a" in arg4:
        accurate = "true"
        print("Accurate scaling enabled (may lead to black borders)")
    else:
        accurate = "false"
        
    if "curvature" in arg2:
        curvature = True
    else:
        curvature = False
        screenWidth = int(arg2)
        screenHeight = int(arg3)
        screenAspectRatio = screenWidth / screenHeight
        resolution = str(screenWidth) + "x" + str(screenHeight)
        outputLogFile = open(coreName + "-" + resolution + arg4 + ".csv", "w")
        outputLogFile.write("Widen : ,{}\n".format(widen))
        outputLogFile.write("Accurate : ,{}\n".format(accurate))
        outputLogFile.write("Name,X,Y,Orientation,Aspect1,Aspect2,ViewportWidth,ViewportHeight,HorizontalOffset,VerticalOffset\n")


    resolutionDbFile = open(fileName, "r" )
    print("opened database file {}".format(fileName))
    if not curvature:
        print("created log file {}".format(outputLogFile.name))
    # print('[', end='', flush=True)
    sys.stdout.write('[')
    sys.stdout.flush()
    gameCount = 0

    for gameInfo in resolutionDbFile:
        gameCount = gameCount+1
    	# strip line breaks
        gameInfo = gameInfo.rstrip()
        
        # parse info
        gameInfo = gameInfo.split(",")
        gameName = gameInfo[0]
        gameOrientation = gameInfo[3]
        gameWidth = int(gameInfo[1])
        gameHeight = int(gameInfo[2])
        aspectRatio = int(gameInfo[9]) / int(gameInfo[10])
        gameType = gameInfo[4]
        #integerWidth = int(gameInfo[7])
        #integerHeight = int(gameInfo[8])

        if console:
            coreName = gameName

        cfgFileName = gameName + ".cfg"

        # Create directory for cfgs, if it doesn"t already exist
        if curvature:
            path = "curvature" + "/" + coreName
        else:
            path = resolution + "/" + coreName
        if not os.path.isdir(path):
            os.makedirs (path)

        # create cfg file
        # print("creating {}/{}".format(path,cfgFileName))
        if (gameCount%100 == 0):
            # print('.', end='', flush=True)
            sys.stdout.write('.')
            sys.stdout.flush()
        newCfgFile = open(path + "/" + cfgFileName, "w")

        if "V" in gameType:
            # Vector games shouldn"t use shaders, so clear it out
            newCfgFile.write("# Auto-generated vector .cfg\n")
            newCfgFile.write("# Place in /opt/retropie/configs/all/retroarch/config/{}/\n".format(coreName))
            newCfgFile.write("video_shader_enable = \"false\"\n")

        else:
            if "V" in gameOrientation:
                if curvature:
                    shader = "crt-pi-curvature-vertical.glslp"
                else:
                    shader = "crt-pi-vertical.glslp"
                # flip vertical games
                gameWidth = int(gameInfo[2])
                gameHeight = int(gameInfo[1])
                # Calculate pixel 'squareness' and adjust gameHeight figure to make them square (keeping Width as-was to avoid scaling artifacts)
                pixelSquareness = ((gameWidth/gameHeight)/aspectRatio)
                gameHeight = int(gameHeight * pixelSquareness)

            elif "H" in gameOrientation:
                if curvature:
                    shader = "crt-pi-curvature.glslp"
                else:
                    shader = "crt-pi.glslp"
                # Calculate pixel 'squareness' and adjust gameWidth figure to make them square (keeping Height as-was)
                pixelSquareness = ((gameWidth/gameHeight)/aspectRatio)
                gameWidth = int(gameWidth / pixelSquareness)

            newCfgFile.write("# Auto-generated {} .cfg\n".format(shader))
            newCfgFile.write("# Game : {} , Width : {}, Height : {}, Aspect : {}:{}, Widen : {}, Accurate : {}\n".format(gameName, gameWidth, gameHeight, int(gameInfo[9]), int(gameInfo[10]), widen, accurate))
            if not curvature:
                newCfgFile.write("# Screen Width : {}, Screen Height : {}\n".format(screenWidth, screenHeight))
            newCfgFile.write("# Place in /opt/retropie/configs/all/retroarch/config/{}/\n".format(coreName))
            newCfgFile.write("video_shader_enable = \"true\"\n")
            newCfgFile.write("video_shader = \"/opt/retropie/configs/all/retroarch/shaders/{}\"\n".format(shader))

            if not curvature:
                # Check scale factor in horizontal and vertical directions
                vScaling = screenHeight/gameHeight
                hScaling = screenWidth/gameWidth
            	
                # Keep whichever scaling factor is smaller.  Also get the integer of that scaling factor.
                if vScaling < hScaling:
                    intScaleFactor = int(vScaling)
                    scaleFactor = vScaling
                else:
                    intScaleFactor = int(hScaling)
                    scaleFactor = hScaling

                # For vertical format games, width multiplies by an integer scale factor, height can multiply by the actual scale factor.
                # For horizontal games height multiplies by the integer scale factor, and width multiplies by the actual scale factor, 
                # but gets rounded up to the screen width if close enough.
                if "V" in gameOrientation:
                    if widen == "true":
                        viewportWidth = gameWidth * (intScaleFactor + 1)
                    else:
                        viewportWidth = gameWidth * intScaleFactor
                    if accurate == "true":
                        viewportHeight = gameHeight * intScaleFactor
                    else:
                        viewportHeight = screenHeight
                    newCfgFile.write("# To avoid horizontal rainbow artefacts, use integer scaling for the width\n")

                else:
                    if accurate == "true":
                        viewportWidth = gameWidth * intScaleFactor
                    else:
                        viewportWidth = int(gameWidth * scaleFactor)
                        if screenWidth - viewportWidth < 10:
                            viewportWidth = screenWidth
                    
                    viewportHeight = gameHeight * intScaleFactor
                    newCfgFile.write("# To avoid horizontal rainbow artefacts, use integer scaling for the height\n")

                viewportX = int((screenWidth - viewportWidth) / 2)
                viewportY = int((screenHeight - viewportHeight) / 2)                
                
                newCfgFile.write("aspect_ratio_index = \"22\"\n")
                newCfgFile.write("custom_viewport_width = \"{}\"\n".format(viewportWidth))
                newCfgFile.write("custom_viewport_height = \"{}\"\n".format(viewportHeight))
                newCfgFile.write("custom_viewport_x = \"{}\"\n".format(viewportX))
                newCfgFile.write("custom_viewport_y = \"{}\"\n".format(viewportY))
                
                outputLogFile.write("{},{},{},{},{},{},{},{},{},{}\n".format(gameInfo[0],gameInfo[1],gameInfo[2],gameInfo[3],gameInfo[9],gameInfo[10],viewportWidth,viewportHeight,viewportX,viewportY))

        newCfgFile.close()

    resolutionDbFile.close()
    if not curvature:
        outputLogFile.close()
    print("]\n")
    print("Done!")


def createZip(curvature=False, screenWidth=0, screenHeight=0):
    if curvature:
        outputFileName = "crt-pi-curvature_configs"
        path = "curvature"
    else:
        resolution = str(screenWidth) + "x" + str(screenHeight)
        outputFileName = "crt-pi_configs_" + resolution
        path = resolution
    outputFileName = outputFileName.replace(" ", "")
    outputFileName = outputFileName.lower()

    print("Creating zipfile {}".format(outputFileName))
    shutil.make_archive(outputFileName, "zip", path)

    # now delete config dirs
    print("Deleting temp directory: {}".format(path))
    shutil.rmtree(path)


if __name__ == "__main__":
    if sys.version_info[0] < 3:
        print ("\n\n*** This script must be run using Python 3 ***\n\n")
        exit()
    if len(sys.argv) < 5:
        adjust = ""
    else:
        adjust = sys.argv[4]
    generateConfigs(sys.argv[1], sys.argv[2], sys.argv[3], adjust)