VOGONS

Common searches


VIDEO Patch for pixel-perfect scaling (SDL1)

Topic actions

Reply 720 of 733, 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 733, 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 733, 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 733, 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 733, 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 733, 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 733, 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.

Reply 728 of 733, by 7F20

User metadata
Rank Newbie
Rank
Newbie
tyrells wrote on 2020-03-30, 18:38:

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.

How would one go about using one of these shaders in DosBox SVN inside of Lakka? Usually, I would turn on a shader in the Retroarch menu, but the instructions on your github show setting them in the dosbox config file. Sometimes all those settings layers start to get confusing...

Reply 729 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
tyrells wrote on 2020-03-30, 18:38:

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.

I see no screenshots in that post. Did you mean another?

Reply 731 of 733, by 7F20

User metadata
Rank Newbie
Rank
Newbie
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 […]
Show full quote

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

Delfino,

I am interested in this approach for Dosbox 320x200 to 320x240 on a 15kHz CRT.
Would this be straightforward to implement in the SVN build for linux that one can compile on a Raspberry Pi?

My goal is to have a reasonable upscaled and then downscaled 320x400 title like say Dark Forces or Eye of The Beholder that fills up the whole screen.

Currently, the best that can be done is ~3840x200 with a squished horizontal image. This is with targeted horizontal super-resolutions. (which limits the horizontal artifacting due to non-linear scaling. (which is necessary because of the compromise between non-square pixels and aspect ratio)

It looks good, but it requires black borders around what is typically a 20" CRT monitor. The typical scenario with this is broadcast monitors which are generally 19-20" diagonally. So having this kind of option might provide an interesting alternative that people would be into trying.

Also, I haven't much used shaders (as most people generally avoid them for CRTs) so I am wondering if there is something really basic that I'm missing about this as a solution (like the way dosbox treats scaling and resolution) and if so, you might be so kind as to point out why I'm barking up the wrong tree.

Thanks,

Reply 733 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Delfino Furioso wrote on 2020-06-24, 12:51:

I think he's referring to this and the following post in that same thread
Re: some new shaders for SVN r4319 and later

Thanks. Then I fear that both sharp.png and pixellate.png are blurry and not literally pixel-perfect.