VOGONS

Common searches


VIDEO Patch for pixel-perfect scaling (SDL1)

Topic actions

Reply 720 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Soothe wrote on 2020-01-10, 14:16:

Wait SNES emulators?
Even stuff like bsnes / higan isn't doing it correctly?
Have you ever tried using something like RetroArch?

I used only ZSNES. Don't know about the other ones.

Reply 721 of 727, by 7F20

User metadata
Rank Newbie
Rank
Newbie

Retroarch supports integer scaling in arbitrary x-y directions. Cores for retroarch are, in most cases, libretro-specific and not main branches. (including dosbox) As long as you output at the right resolution, you get 1:1. It can get complicated tho because, from what I understand, different systems have different actual output resolutions which vary from their internal digital resolutions (which are encoded at 720x240 as per Rec. 601. https://www.itu.int/dms_pubrec/itu-r/rec/bt/R … 03-I!!PDF-E.pdf) That means that it all depends on what the core is doing with the rom and how much scaling is being done to emulate NTSC conversion or not.

Reply 722 of 727, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

Here I am again 😀

I've tested various combinations of outputs & scalers, each with aspect corretion on & off.
My goal was to get a better understanding of the various algorithms' effects on a raw VGA 13h 320x200 frame.
It might already have been common knowledge for the most part, nevertheless I did find some interesting results.

I've used both vanilla SVN r4301 and ECE r4301 for windows (both supplied by yesterplay on his website).
I've chosen to use a picture viewer called GAZE which can be configured to set the wanted display mode.
The picture used has been made in paint by me and saved as a 8bit bitmap (you'll find it attached to this post).

My laptop's display was set to its native FHD resolution.
All dosbox settings were left at their default values, with the exception of the following:
machine = svga_s3
scaler = <cycled between various values>
output = <cycled between various values>
aspect = <cycled between true and false>
glfullvsync = false
fullscreen = false
fullborderless = false
fulldouble = false
fullresolution = original
windowresolution = <cycled between 1280x960 and 1600x1200>

For each test I've captured a screenshot of my whole screen, in order to let you evaluate also the content of dosbox's console output
All screenshots are attached to this post.
I'll present my interpretation of the results, hoping for your feedback.

--== VANILLA "SURFACE" OUTPUT ==--
  • the "scaler" setting determines how big the dosbox window will be
  • the "windowresolution" setting will NOT limit the size of the window (and neither will the host's display resolution)
  • in SVN the aspect ratio correction is performed by adding (duplicating) existing lines (=> see "1x+surface+aspect.png")
  • in ECE the aspect ratio correction DO NOT take place (=> see "1x+surface+aspect.png")
--== VANILLA HARDWARE-ACCELERATED OUTPUT DEVICES (overlay, ddraw, opengl) ==--
  • the "scaler" setting determines how big the frame processed by the output device will be
  • the "windowresolution" setting determines the size of the window (wich might be smaller than the frame resulting from the scaler)
  • the upscaling from "scaler output resolution" to "windowresolution" is performed using bilinear filtering (exception: opengl without aspect correction => see "1x+opengl.png")
  • the downscaling from "scaler output resolution" to "windowresolution" (when needed) is performed using bilinear filtering
  • the aspect ratio correction is being performed during the upscaling, using bilinear filtering
--== PIXEL PERFECT OUTPUT DEVICES (surfacepp, openglpp) ==--
  • the "scaler" setting is not taken into account
  • the "windowresolution" is being used as a hint when calculating the integer scaling factor
  • the upscaling is performed using integer multipliers
  • the downscaling is never needed, since the upscaled frame will never be bigger thant the "windowresolution" setting
  • the ar correction, when limted to a 1600x1200 window, results in the accurate "5:6 pixel, 4:3 screen" proportions (after a 5xHor+6xVer scaling to 1600x1200 => see "1x+surfacepp+aspect.png" in the 1600x1200 zip)
  • the ar correction, when limted to a 1280x960 window, results in the weird "3:4 pixel, 6:5 screen" proportions (after a 3xHor+4xVer scaling to 960x800 => see "1x+surfacepp+aspect.png" in the 1280x960 zip)
--== ADDENDUM ==--

You might have noticed that in all tests the white (255,255,255) background has become warmer (255,251,243)
The only exception being the "overlay" test cases.
I wonder why?

--== REPLY TO JMARSH ==--
jmarsh wrote on 2020-01-09, 23:24:
Delfino Furioso wrote on 2020-01-09, 22:33:

I still see its usefulness, though: performing "pp upscaling + linear downscaling" should in theory give better results than the "linear upscaling" that the standard opengl output implements

Regular DOSBox can already do the same thing using "scaler=normal?x forced" to upscale beyond the output resolution and "output=opengl" for linear downscaling.

indeed! how does the aspect ratio correction works, though?

it is my understanding that it is always performed via linear scaling and that no "5xHor+6xVer" integer scaling is actually implemented

so, when using a fixed 4:3 windowresolution:
input: 320x200 => normal4x scaling => 1280x800 => opengl linear up scaling to windowresolution => 1280x960
input: 320x200 => normal5x scaling => 1600x1000 => opengl linear down scaling to windowresolution => 1280x960

instead, when leaving it to the output device to decide the final resolution (as when using windowresolution=desktop or a 16:9 fullresolution on a FHD laptop):
input: 320x200 => normal4x scaling => 1280x800 => opengl linear up scaling to the biggest 4:3 resolution which will fit the 1920x1080 panel => 1440x1080
input: 320x200 => normal5x scaling => 1600x1000 => opengl linear up scaling to the biggest 4:3 resolution which will fit the 1920x1080 panel => 1440x1080
input: 320x200 => normal6x scaling => 1920x1440 => opengl linear up scaling to the biggest 4:3 resolution which will fit the 1920x1080 panel => 1440x1080

--== REPLY TO ANT222 ==--
Ant_222 wrote on 2020-01-10, 13:06:
Delfino Furioso wrote on 2020-01-10, 12:53:

this image tries to exemplify the new approach I am interested in
https://i.postimg.cc/HxqTsnbD/openglnp.png

No—that shows pixel-perfect scaling with aspect ratio correction.
My patch already works that way if the output resolution is large enough.

the key here is "if the output resolution is large enough"
as seen with my tests: when this requirement is not met, your patch will either 1) not perform scaling and/or aspect ratio correction, 2) perform weird aspect ratio conversions

my proposal was to always upscale using the 5xHor+6xVer multipliers, disregarding the available screen estate, and then let the opengl acceleration do the necessary linear downscale
that's why I've called this a "openglnp" output of sort

At the end, what I'm looking for is explained here
https://www.gamasutra.com/blogs/FelipePepe/20 … spect_ratio.php

And I've thought that a combination of the upscaling code from the pp patch (with resolution limit removed) and the downscaling code of the vanilla opengl would be the solution
I've proposed this in this thread following the kcroft intervention about reimplementing this patch in the SDL2 port of dosbox

thank you all for your attention! 😀

Attachments

Last edited by Delfino Furioso on 2020-01-18, 06:18. Edited 1 time in total.

Reply 723 of 727, by KainXVIII

User metadata
Rank Member
Rank
Member

Interesting post about Pixellate shader (i know its not possible in Dosbox right now, maybe only in Retroarch core?), what do you think about it?
https://www.resetera.com/threads/how-do-you-l … /#post-16387673

Reply 724 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Delfino Furioso wrote on 2020-01-17, 15:49:

I've tested various combinations of outputs & scalers, each with aspect corretion on & off.

That is a lot of tests. I don't have time to study and comment on them all.

Delfino Furioso wrote on 2020-01-17, 15:49:

For each test I've captured a screenshot of my whole screen, in order to let you evaluate also the content of dosbox's console output

Good, but the DOSBox window partially obscures the colsole window. It would have much easier if you had presented your results in tabular form, e.g.:

Available ASP  x   y   Result   PAR
1280x960 Y 3.0 4.0 960x800 1.33
1280x960 N 4.0 4.0 960x800 1.00
. . . . . . . . . . . . . . . . . .
Delfino Furioso wrote on 2020-01-17, 15:49:

You might have noticed that in all tests the white (255,255,255) background has become warmer (255,251,243)
The only exception being the "overlay" test cases.
I wonder why?

So do I. You better ask it in a separate thread, about stock DOSBox.

Delfino Furioso wrote on 2020-01-17, 15:49:

how does the aspect ratio correction works, though?
it is my understanding that it is always performed via linear scaling and that no "5xHor+6xVer" integer scaling is actually implemented

In stock DOSBox? For SW surfaces it via nearest-neighbor interpolation along the vertical axis. For HW surfaces, the interpolative scaler takes care of it.

Delfino Furioso wrote on 2020-01-17, 15:49:

the key here is "if the output resolution is large enough"
as seen with my tests: when this requirement is not met, your patch will either 1) not perform scaling and/or aspect ratio correction...,

Right.

2)perform weird aspect ratio conversions

Define weird. I say my patch uses the best possible integer approximation of the required scaling factors. For example:

320x200 8:5 5:6 --[3x4]--> 960x800 6:5 3:4

What better integer scales can you propose? If the result looks too narrow, turn off aspect-ratio correction and enjoy square pixels:

320x200 8:5 5:6 --[4x4]--> 1280x800 8:5 1:1
Delfino Furioso wrote on 2020-01-17, 15:49:

my proposal was to always upscale using the 5xHor+6xVer multipliers, disregarding the available screen estate, and then let the opengl acceleration do the necessary linear downscale
that's why I've called this a "openglnp" output of sort

Understood, but I am not very much interested in this approach. But since it is possible, I will consider implementing it when I have time.

Delfino Furioso wrote on 2020-01-17, 15:49:

At the end, what I'm looking for is explained here
https://www.gamasutra.com/blogs/FelipePepe/20 … spect_ratio.php

I had read that article by Felipe Pepe. He writes about that method: It's an impossible request at heart, so we can only choose what gets closer. In my opinion, the sharpness and regularity of pixels are the most important criteria of upscaling pixel-art. No pixel artist will let you blur his precious hand-set pixels. And most of old MS-DOS games are pixel-art.

Last edited by Ant_222 on 2020-01-18, 13:24. Edited 1 time in total.

Reply 725 of 727, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
KainXVIII wrote on 2020-01-17, 22:28:

Interesting post about Pixellate shader (i know its not possible in Dosbox right now, maybe only in Retroarch core?), what do you think about it?
https://www.resetera.com/threads/how-do-you-l … /#post-16387673

Looks good to me, if a bit too blurry. Since there have been very different CRTs, such shaders should have adjustable parameters.

Edit 1: I looked at the wrong post. That Pixellate shader is exactly what Delfino Furioso wants!

Edit 2: Observe, however, that with the right output area, the Pixellate shader will perform pixel-perfect scaling with no blurring, just as my patch does.

Reply 726 of 727, by tyrells

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote on 2020-01-18, 13:17:
Looks good to me, if a bit too blurry. Since there have been very different CRTs, such shaders should have adjustable parameters […]
Show full quote
KainXVIII wrote on 2020-01-17, 22:28:

Interesting post about Pixellate shader (i know its not possible in Dosbox right now, maybe only in Retroarch core?), what do you think about it?
https://www.resetera.com/threads/how-do-you-l … /#post-16387673

Looks good to me, if a bit too blurry. Since there have been very different CRTs, such shaders should have adjustable parameters.

Edit 1: I looked at the wrong post. That Pixellate shader is exactly what Delfino Furioso wants!

Edit 2: Observe, however, that with the right output area, the Pixellate shader will perform pixel-perfect scaling with no blurring, just as my patch does.

Just a note, I've ported the Pixellate shader to DOSBox SVN, it can be found here: https://github.com/tyrells/dosbox-svn-shaders. Some screenshots of the shader in action can be seen in the following forum post: some more shaders for SVN r4319 and later.