Reply 720 of 733, by Ant_222
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.
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.
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.
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.
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?
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
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.pngNo—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! 😀
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
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.
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.
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 […]
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-16387673Looks 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.
To people trying the above glshader, you'll get better results if you turn off the scaler (with 'none') before using a glscaler (not only this one).
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...
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?
I think he's referring to this and the following post in that same thread
Re: some new shaders for SVN r4319 and later
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 […]
At the end, what I'm looking for is explained here
https://www.gamasutra.com/blogs/FelipePepe/20 … spect_ratio.phpAnd 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,
I'm afraid I can't help you with this, since it's way beyond my line of expertise... sorry
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.