VIDEO Patch for pixel-perfect scaling (SDL1)

[Solanacean]

Solanacean, please replace the function ssPsEndUpdate in sdlmain.cpp with the one attached and test again.

Unfortunately, the glitch is still there.

[Ant_222]

If so, can you please delete the conditional compilation and test with

Code: Select all

pix_out.pixels += 1;

.
EDIT: The bug is caused by this offset in the reading of pixel values:

Code: Select all

A B G R
b g r

i.e. alpha channel (random value) is read as blue, blue as green, and green as red. This is why the screenshots have no blue color except in (semi)random blue stripes and why white is shown as yellow (g+r). Once you help me to confirm that this is the actual problem, I will find a way to treat pixels in a format-independent way.

[Solanacean]

If so, can you please delete the conditional compilation and test with

Code: Select all

pix_out.pixels += 1;

.

Now it crashes with a segmentation fault.

[Ant_222]

Can you try it with

Code: Select all

machine=ega

?

[Solanacean]

Can you try it with

Code: Select all

machine=ega

?

The build with the conditional compilation directives commented out: no blue strips.

[Ant_222]

Thank you very much. It is very late now, so I must to bed. Tomorrow I shall give a code to output the properties of sdl.surface->format: Rshift and Bshift. There must be some difference in the RGB(A) layout between our machines. If you can look at them yourself, then please do. This is a global variable available from ssPsEndUpdate() and initialized by the time it executes.

[Ant_222]

The build with the conditional compilation directives commented out: no blue strips.

I have reproduced this by exactly the opposite modification (decrement by one). Please, try again with the attached function.

[Solanacean]

The build with the conditional compilation directives commented out: no blue strips.

I have reproduced this by exactly the opposite modification (decrement by one). Please, try again with the attached function.

[Ant_222]

Ok. I must learn about the layout of pixels in RAM.

[Ant_222]

Can you please replace 3 with 4 in the rgb_32_fmt structures as shown in formats.cpp and restore the function ssPsEndUpdate.cpp to its original state (attached), and try again. No need to test several devices, just test with ega.

EDIT:This should help with surfacepp and surfacenb, which copy pixels as memory blocks, but not with [i]surfacenp/i], which extracts individual channel values for interpolation.

[Solanacean]

Can you please replace 3 with 4 in the rgb_32_fmt structures as shown in formats.cpp and restore the function ssPsEndUpdate.cpp to its original state (attached), and try again. No need to test several devices, just test with ega.

EDIT:This should help with surfacepp and surfacenb, which copy pixels as memory blocks, but not with [i]surfacenp/i], which extracts individual channel values for interpolation.

You're awesome! Everything looks fine now!

[Ant_222]

You're awesome! :happy: Everything looks fine now!

Thanks, but surfacenp doesn't work and the other two modes are potentially slower because instead of copying three bytes I know copy four. All in all, this is only a temporary fix.

[lukeman3000]

Available area is the maximum size of the output image. In windowed mode it is the window dimensions and in full-screen mode it is your full-screen resolution. Both are specified in the DOSBox config file. 320x200 is the resolution of the graphical mode of the game being emulated and 1.20 is its PAR, as reported by DOSBox. [4.0 x 5.0] shows the horizontal and vertical scaling factors that my patch applies. The final entry contains the resulting image resolution, 1280x1000:

Code: Select all

320 * 4.0 = 1280
200 * 5.0 = 1000

and PAR:

Code: Select all

5.0 / 4.0 = 1.25

Each pixel of the game is represented as a 4x5 rectangle and therefore has a PAR of 1.25. Since 1.25 is within 4.1% of 1.20, the aspect ratio of the scaled image is nearly perfect, and the difference is barely perceptible. If the available area were at least 1600x1200, then you would have a perfect PAR:

Code: Select all

320 * 5.0 = 1600
200 * 6.0 = 1200
5.0 / 4.0 = 1.2 ( = source PAR)

Hi Ant -

I revisited this thread tonight to reacquaint myself with the pixel perfect patch; I just wanted to say thanks for your excellent and detailed explanations; they have been very interesting to read.

I do have a couple more questions, something that I missed the first time around. In the quote above, you state

Since 1.25 is within 4.1% of 1.20, the aspect ratio of the scaled image is nearly perfect, and the difference is barely perceptible.

1. When you say it's within 4.1%, I assume you're doing the following: (1.25 - 1.20) / 1.25 = 0.04 or 4%. Correct?

2. You say "since 1.25 is within 4.1% of 1.20" -- why, specifically, do you say 4.1%? Is this an arbitrary percentage, or does it have some meaning?

3. On an unrelated topic, I notice that launching games with surfacepp takes considerably longer (a few seconds) than if I'm using one of the other render modes. Is there any chance that as you continue to develop the patch, this time may decrease? And will using this patch potentially make it difficult to play newer, more demanding games, or does the delay only occur when launching the game and does not affect the game's performance once it's being played?

4. Also, finally, I seem to be running into some issues with pixel perfect. For example, with Space Quest V, stdout.txt says the following:

Code: Select all

Available area: 2560x1440
Scaling: 640x400 (1.20) --[3.0 x 3.0]--> 1920x1200 (1.00)

This is running in full screen mode. So, if I'm doing this right, I'm looking at a difference of about 16% (1.20 compared to 1.0), which doesn't seem that great. I thought that running in full screen was essentially guaranteed to net me a perfect pixel aspect ratio? So if not, should I still be using surfacepp in these kinds of cases, or should I consider a different render mode, and if so, for what reason?

[Ant_222]

I do have a couple more questions, something that I missed the first time around. In the quote above, you state

Since 1.25 is within 4.1% of 1.20, the aspect ratio of the scaled image is nearly perfect, and the difference is barely perceptible.

1. When you say it's within 4.1%, I assume you're doing the following: (1.25 - 1.20) / 1.25 = 0.04 or 4%. Correct?

No. Since the correct value is 1.20, the ratio should be inverted:

Code: Select all

(1.25 - 1.20) / 1.20 = 1/24 ~ 4.1%

2. You say "since 1.25 is within 4.1% of 1.20" -- why, specifically, do you say 4.1%? Is this an arbitrary percentage, or does it have some meaning?

This is the exact percentage of error for that case, so the value is not arbitrary. This error, of one part in twenty-four, is so small as to be hardly noticeable.

On an unrelated topic, I notice that launching games with surfacepp takes considerably longer (a few seconds) than if I'm using one of the other render modes. Is there any chance that as you continue to develop the patch, this time may decrease?

Hard to say because I don't yet know whence this slow-down comes. It might be due to an inefficient initial filling of the screen with black pixels. I am on vacation now and have no access to the PC with my build environment.

And will using this patch potentially make it difficult to play newer, more demanding games, or does the delay only occur when launching the game and does not affect the game's performance once it's being played?

Yes, it may, for the current algorithm does not use either GPU or multithreading. In DOSBox 2.0 it could be implemented using the GPU and should be (theoretically) fast enough for most games is not for all. You can test the performance of the current version and post the results here.

4. Also, finally, I seem to be running into some issues with pixel perfect. For example, with Space Quest V, stdout.txt says the following:

Code: Select all

Available area: 2560x1440
Scaling: 640x400 (1.20) --[3.0 x 3.0]--> 1920x1200 (1.00)

This is running in full screen mode. So, if I'm doing this right, I'm looking at a difference of about 16% (1.20 compared to 1.0), which doesn't seem that great.

This behavior is correct. In order to play Space Quest V in the original aspect ration you would need a resolution of at least:

Code: Select all

3200 by 2400
1.20 = 6/5
640*5 = 3200
400*6 = 2400

I thought that running in full screen was essentially guaranteed to net me a perfect pixel aspect ratio?

No, as shown above. Fullscreen will give you the largest available area and therefore the best possible rendering on your system. It may not always be ideal.

So if not, should I still be using surfacepp in these kinds of cases, or should I consider a different render mode, and if so, for what reason?

This is largely a subjective question. Try to compare how it feels in pixel-perfect mode and with in one of the modes that preserve aspect ratio, and choose whichever you like best.

I am strongly in favor of pixel-perfect display and use it unless aspect error is so large that it outweighs the disharmony of blurry or irregular pixels.

[lukeman3000]

Thank you. What aspect error might be large enough for you to consider using a different render mode - 10%, 20%?

[Ant_222]

Thank you. What aspect error might be large enough for you to consider using a different render mode - 10%, 20%?

I have never consciously analysed it. It might even vary with games. Suffice it to note that before I had made the patch, I prefered playing Alone in the Dark in pixel-perfect mode without aspect correction (surface, normal3x) rather than with the correct aspect ratio but with distorted pixels (opengl, openglnb, overlay). This gives an error of 17%. It is large but not as annoying as the alternatives I had. Of course, with the patch AITD looks gorgeous on anything starting from 1280x1000 (for the nearly-perfect 4:5 correction).

[lukeman3000]

Thank you. What aspect error might be large enough for you to consider using a different render mode - 10%, 20%?

I have never consciously analysed it. It might even vary with games. Suffice it to note that before I had made the patch, I prefered playing Alone in the Dark in pixel-perfect mode without aspect correction (surface, normal3x) rather than with the correct aspect ratio but with distorted pixels (opengl, openglnb, overlay). This gives an error of 17%. It is large but not as annoying as the alternatives I had. Of course, with the patch AITD looks gorgeous on anything starting from 1280x1000 (for the nearly-perfect 4:5 correction).

I see. With SQV, I'm looking at an aspect error of about 20%... Guess I'll just have to compare the image from a couple different render modes and see which one I prefer.

[lukeman3000]

Ant, another question:

When playing with resolution and surfacepp, I get two very different results from a seemingly small difference in PAR (about 5.8%).

The calculator in each image shows the difference between the game's native PAR and the rendered PAR (e.g., ((1.2 - 1.0) / 1.2)*100 = 16%. So, 16% vs 10.8% is about 5.8%, and yet the aspect ratio of the two images seem to have a much greater difference than 5.8%... What am I missing here? Or is that 5.8% making that much of a difference?

Is it such that I'm comparing two different things? In other words, pixel aspect ratio and aspect ratio aren't intrinsically linked, so even though the difference in PAR is only 5.8%, for some reason the difference in aspect ratio is much greater.. ?

[Ant_222]

Ant, another question:

When playing with resolution and surfacepp, I get two very different results from a seemingly small difference in PAR (about 5.8%).

The calculator in each image shows the difference between the game's native PAR and the rendered PAR (e.g., ((1.2 - 1.0) / 1.2)*100 = 16%. So, 16% vs 10.8% is about 5.8%, and yet the aspect ratio of the two images seem to have a much greater difference than 5.8%... What am I missing here? Or is that 5.8% making that much of a difference?

In the first case the patch had an available area of 1152 x 864 which allowed for an imperfect aspect-ratio correction of 3:4 instead of the perfect 5:6. This resulted in the following error:

Code: Select all

(4/3-6/5) / (6/5) = 1/9 ~ 11%

In the second case the smaller available area of 1024x768 was insufficient for any correction whatsoever, so the patch displayed the game with unity PAR and with an aspect-ratio error of

Code: Select all

(1 - 6/5) / (6/5) = - 1/6 ~ - 16%

This value is negative because the actual PAR is smaller than the correct one. If you subtract the errors respecting their signs, you will have:

Code: Select all

11% - (-16%) = 27%

which is a large difference (of almost one third).

Is it such that I'm comparing two different things? In other words, pixel aspect ratio and aspect ratio aren't intrinsically linked, so even though the difference in PAR is only 5.8%, for some reason the difference in aspect ratio is much greater.. ?

They are linked via resolution:

Code: Select all

AR = (1/PAR) * Width/Height

Original: 320/200 * (1/(6/5)) = 4/3 ~ 1.33  (CRT)
Case I:   320/200 * (1/1)     = 8/5 = 1.60  (wide)
Case II:  320/200 * (1/(4/3)) = 6/5 = 1.20  (tall)

(But 1.20 is closer to 1.33 than 1.60)

Your mistake was in ignoring the sign of the error.

[Ant_222]

Does anybody use surfacenp or surfacenb? The latter is already implemented in openglnb, so the question is whether opengl is available on the majority of systems. surfacenp is very slow and becomes indistinguishable from surfacenb/openglnb as the the output resolution increases. Would anybody miss these modes if I removed them?