VIDEO Patch for pixel-perfect scaling (SDL1)

[Ant_222]

Thank you very much, Yesterplay80. I have found out the same thing last evening. In addition to the conditional compilation directive, something has changed that made some hunks apply with an offset, which I will try to fix as well. It would be trivial if I knew SVN better and could use its full power by storing my patch in it.

[Yesterplay80]

Thank you very much, Yesterplay80. I have found out the same thing last evening. In addition to the conditional compilation directive, something has changed that made some hunks apply with an offset, which I will try to fix as well. It would be trivial if I knew SVN better and could use its full power by storing my patch in it.

The offset is already fixed in the file I provided, it applies cleanly with r4063 now.

[Ant_222]

The offset is already fixed in the file I provided, it applies cleanly with r4063 now.

Excellent! Can you teach me how to do it? The only way I see is to get a non-conflicting revision (e.g. 4055), apply the patch (with offset but without conflicts), update conditional compilation in sdlmain.cpp with C_DDRAW, then get the latest (conflicting) revision, apply the patch (with conflicts), replace sdlmain.cpp with the modified version from the previous revision and make a fixed patch using svn -diff. But there ought to be a simpler method. Did you use some graphical merge utility?

[Yesterplay80]

Actually it really is just digging in the dirt: I checked out a fresh SVN, applied the patch, reversed it, corrected the offsets and then compared the hunks that failed with the changes the diff file tries to make and corrected those. I just used a text editor (notepad++ to be exact).

[DosDaddy]

Hello there. Here's a couple things I'm having trouble with:

viewtopic.php?p=633110#p633110
viewtopic.php?p=633140#p633140

(Turns out I originally posted in the wrong thread)

Thanks for this neat patch and hope something can be done about these.

[Ant_222]

DosDaddy, I will look into it this evening or tomorrow. With what games do you experience the tearing?

[DosDaddy]

I'm afraid all of them. Blood and Monster Bash to name just a couple.

[Ant_222]

I will try these games. Since neither I nor other users seem to have this problem, I suspect your drivers or graphical subsystem. Does the plain-jane surface look right on your machine? The code does not write directly to the screen, as you suggested, but to a an SDL buffer, which is the blitted to the screen in a single function call.

[DosDaddy]

Yep, it very much does. The only way for me to get "smooth", normal tearing (1 tearing line) is utilizing the original resolution + fulldouble when going fullscreen without any scaling or aspect ratio correction whatsoever, which leaves the accommodation of the output image to the display driver and the monitor (not a very elegant solution of course).

Imagine multiple tearing lines on the same screen; that's exactly what I get, so it's all juddery and jumpy.

We're talking an intel G41 Express on top of WinXP, everything up to date.

[Ant_222]

At the original resolution it may simply have less work to do and consequently produces less tearing. I think it surfacepp at the original resolution will behave the same.

[DosDaddy]

That's indeed correct, no prob using the original resolution.

Now, there's this source port called "Chocolate Doom" that tries to do something similar to what this patch does (similar as far as the intended end result is concerned, of course) and I don't get this type of tearing at all, meaning the "more work to do" part of the equation could still potentially be improved. It's being done with SDL2, though, so I'm not getting my hopes up

[Ant_222]

DosDaddy,

Imagine multiple tearing lines on the same screen; that's exactly what I get, so it's all juddery and jumpy. We're talking an intel G41 Express on top of WinXP, everything up to date.

Are you certain your drivers are recognised and working, and that the Hardware manager shows no malfunctioning devices?

DOSBox ECE r4035 runs Monster Bash smoothly on my PC using surfacepp in fullscreen mode. It is an AMD A4-3400 APU with Radeon (onboard) graphics, under Windows XP, and my display resolution is 1680x1050, so the game runs at 1280x1000. I will see if I can add some logging to check what is going on on your side, but right now I should blame either SDL or your configuration. I don't have low-level control on how SDL puts the image to the screen, so it may be that SDL somehow dislikes your software-hardware configuration.

Now, there's this source port called "Chocolate Doom" that tries to do something similar to what this patch does (similar as far as the intended end result is concerned, of course) and I don't get this type of tearing at all, meaning the "more work to do" part of the equation could still potentially be improved.

Well, I don't get any tearing with my patch either, and by more work to do I meant that high load aggravates the bug or problem, which must be there in the first place. When my patch begins to stutter on my PC, it does so gracefully and without many tearing lines.

It's being done with SDL2, though, so I'm not getting my hopes up

That's a different kettle of cod. It has, for example, native support for hardware-accelerated integer scaling with independent horizontal and vertical scaling factors—just what the pixel-perfect mode needs!

[Ant_222]

Is there a way to change the default aspect ratio ECE will correct a non-square pixel 3:2 image to?

It is the first time I hear of a 3:2 aspect ratio in MS-DOS. What game uses it? Edit: Ok, 720x480 is 3:2.

The value currently in place seems a bit overkill, effectually leaving you with a 320x267 image when AR-correcting for 320x200, whereas mode 13h on a CRT would have almost always resulted in a 4:3 output back in the day (320x240).

If I do not misunderstand you, then correcting from 200 to 240 and to 267 implies non-integer scaling factors: 1.2 and 1.33 respectively—something that the Pixel-perfect patch is designed never to do so as to avoid interpolation artefacts. Can you specify a game and post a screenshot (or textshot) of the console output, where the patch shows its scaling parameters?

In order to get an ideal 4:3 image with a 320:200 game, the Pixel-perfect patch needs an area of at least 1600x1200 pixels. With my monitor of 1680:1050 I get an almost-perfect correction to

Code: Select all

320:200 ->[4x5]-> 1280:1000 = 1.28 (vs. the ideal 1.33).

Ideally this setting should be configurable to the satisfaction of the user, but a simple, hard-coded, alternative 4:3 mode would be enough for this dog.

I fear I do not fully understand you. With aspect=true the current version of the patch corrects the image as closely to 4:3 as possible. If you clarify your proposal with specific (numeric) examples, then I will consider it.

[DosDaddy]

If I do not misunderstand you, then correcting from 200 to 240 and to 267 implies non-integer scaling factors: 1.2 and 1.33 respectively—something that the Pixel-perfect patch is designed never to do so as to avoid interpolation artefacts. Can you specify a game and post a screenshot (or textshot) of the console output, where the patch shows its scaling parameters?

Sure. A game...hmmm, pretty much every game (forgive me if I'm being overly obtuse here, but it really looks like that from my side of the river). Make it Shadow Warrior this time just for the sake of argument.

Attached is the requested screenshot. Notice the native resolution is 1440x900 and I'm going from windowed to fullscreen and back.

In order to get an ideal 4:3 image with a 320:200 game, the Pixel-perfect patch needs an area of at least 1600x1200 pixels. With my monitor of 1680:1050 I get an almost-perfect correction to

Code: Select all

320:200 ->[4x5]-> 1280:1000 = 1.28 (vs. the ideal 1.33).

Here's the thing: a 320x200 picture AR-corrects to 4:3 perfection at 1600x1200, but proportionally downscale that 1600x1200 to 320x... and you get 320x240, not 320x267.

320x240 = 1.3333333333
320x267 = 1.1985018727

There's a noticeable difference in the outcome.

[Ant_222]

Notice the native resolution is 1440x900 and I'm going from windowed to fullscreen and back.

I see:

Code: Select all

Available area: 1424x858

rather than 1440x900. I suppose the smaller figure is the size of your window, because in fullscreen the available area should be 1440x900, but I did not find it in the screenshot...

Here's the thing: a 320x200 picture AR-corrects to 4:3 perfection at 1600x1200, but proportionally downscale that 1600x1200 to 320x... and you get 320x240

That's right, but you do not have 1600x1200, so the patch cannot reproduce the aspect ratio perfectly. Notice that it must use integer scaling factors in order to keep the image pixel-perfect. It therefore chose 3 and 4 as horizontal and vertical scales respectively, which resulted in a pixel aspect ratio (PAR) of 4:3 or 1.33, vs. the target (perfect) PAR of 6:5, or 1.2. What should you expect (or desire) my patch to do instead? If you would prefer to have square pixels (unity PAR), just disable aspect-ratio correction in the config file.

[DosDaddy]

I suppose the smaller figure is the size of your window, because in fullscreen the available area should be 1440x900, but I did not find it in the screenshot...

Don't mind the windowed mode. I just mentioned it so you could relate more reliably to information on the screenshot. I always use fullscreen if the software allows it; I detest having anything windows show up in my dos fov.

That's right, but you do not have 1600x1200, so the patch cannot reproduce the aspect ratio perfectly. Notice that it must use integer scaling factors in order to keep the image pixel-perfect. It therefore chose 3 and 4 as horizontal and vertical scales respectively, which resulted in a pixel aspect ratio (PAR) of 4:3 or 1.33, vs. the target (perfect) PAR of 6:5, or 1.2. What should you expect (or desire) my patch to do instead? If you would prefer to have square pixels (unity PAR), just disable aspect-ratio correction in the config file.

I think I figured out the problem here; you're looking at this from a purely theoretical perspective, and I perhaps from a slightly more practical one. Technically, though, since it's not possible to apply pixel-perfect 4:3 aspect ratio correction to 320x200 without at least 1600x1200, anything short of that will inevitably result in an uneven (imperfect) distribution of pixels, causing some rows to look thicker than others, and there's no fixing that at lower resolutions irrespective of the mathematical accuracy of the scaling factors involved.

Ultimately, though, what I'm looking to get out of 320x200 is 960x720 rather than 960x800, as it so happens to be right now, but it's likely that this patch is designed to work strictly under certain parameters (integer everything) and this alternative mode of correction may not be viable/desirable or simply beyond the scope of the project.

[Ant_222]

DosDaddy,

I think I figured out the problem here; you're looking at this from a purely theoretical perspective, and I perhaps from a slightly more practical one. Technically, though, since it's not possible to apply pixel-perfect 4:3 aspect ratio correction to 320x200 without at least 1600x1200, anything short of that will inevitably result in an uneven (imperfect) distribution of pixels, causing some rows to look thicker than others, and there's no fixing that at lower resolutions irrespective of the mathematical accuracy of the scaling factors involved.

Nearest-neighbor interpolation (openglnb and surfacenb)) will give you that "uneven distribution of pixels." Pixel-perfect mode, however, avoids it like the plague and keeps the pixels crisp and clear in all circumstances.

Ultimately, though, what I'm looking to get out of 320x200 is 960x720 rather than 960x800, as it so happens to be right now, but it's likely that this patch is designed to work strictly under certain parameters (integer everything) and this alternative mode of correction may not be viable/desirable or simply beyond the scope of the project.

This is not possible in pixel-perfect mode because the ratio of 720 to 200 is not an integer. But go ahead and try one of the nearest-neighbor modes! They will give you the perfect aspect ratio at the expense of regular pixels.

[DosDaddy]

Alright, sorry about the delay, but I finally got around testing this on other computers and the results pretty much confirm what you had already suggested; my CPU's just aren't up to the task. Chocolate Doom's scaling works as fast as it does because everything's handled in hardware via SDL2, but there's no escaping that even the venerable P4 670, though still very usable, can't keep up with that much passing of time.

It's a shame, though, because your scaler does something that a lot of emulators desperately need and actually does it quite well

[Ant_222]

Alright, sorry about the delay, but I finally got around testing this on other computers and the results pretty much confirm what you had already suggested; my CPU's just aren't up to the task.

Have you excluded possible problems with the graphics driver and/or SDL1's interaction with it? If you can compile C programs, you might try my non-graphical scaling benchmark with different optimisation levels to isolate your CPU performance with regard to pixel-perfect scaling and compare it with those of several other users, including me.

Chocolate Doom's scaling works as fast as it does because everything's handled in hardware via SDL2, but there's no escaping that even the venerable P4 670, though still very usable, can't keep up with that much passing of time.

I think that the P4 670 should be faster than my AMD A4-4300, whereas I failed to reproduce your performance problem. Strange...

It's a shame, though, because your scaler does something that a lot of emulators desperately need and actually does it quite well :/

Thank you for the feedback. The scaling algorithm itself is very simple and primitive, but it was quite difficult for me to integrate it into DOSBox. I feel chary of doing the same for some unofficial SDL2 fork because I fear that all my work will be lost because of incompatibility with some major modification to the official DOSBox. I am mickle glad and grateful that my original patch lives on.

[DosDaddy]

Ok, sorry again about the delay, but I didn't get a chance to play around with the scaler on the target hardware till just a few of days ago.

I could potentially try the benchmark tool, but I'm not running a full-featured IDE (I tried CodeBlocks for a while but I didn't quite like it) or a compiler that would be all that useful in regards to optimizations (casual TinyC user here) so not exactly sure about that

A temporary and definitely less elegant alternative I came up with was to design a custom PowerStrip display mode using the "resolution-in-a-resolution" tool, bypassing the software scaler altogether, but there are only so many fringe timings this monitor can handle, so it is of rather limited value.

Right now I'm using a GeForce 6200-powered P4 with hopelessly outdated drivers (and that for retro compatibility's sake), so we're dealing with yet another unusual, derogated and ultimately pointless combination of hardware/software your scaler probably does not account for, and for good reason.