Ant_222 wrote:

Bad news: both the screenshots use nearest-neighbor interpolation and have irregular pixel magnification, which means that the S […]
Show full quote

KainXVIII wrote:

@ant_222, here you go, btw, screenshots from latest ScummVM build (aspect correction on, 1080p)

Bad news: both the screenshots use nearest-neighbor interpolation and have irregular pixel magnification, which means that the ScummVM developers not only have failed to implement pixel-perfect scaling, but also are deceiving their users by calling nearest-neighbor interpolation to the correct aspect ratio "pixel-perfect":

Copy code to clipboard

1320x200 --[4.0x4.8]--> 1280x960

—only the horizontal scale is integral, whereas the vertical one is a fractional. It makes no sense.

Edit: To clarify—the rows in the "pixel-perfect scaling" screenshot are magnified with alternating scales of 4 and 5 in a ratio of 1 to 4: 4, 5, 5, 5, 5, 4, 5, 5, 5, 5, ... yielding an average vertical scale of 24/5, or 4.8.

Wouldn't pixel-perfect scaling of 320x200 using square pixel flat panels result in wrong aspect ratios? The resolution may be 4:4.8 but it was displayed on a 4:3 monitor.. ScummVM may be doing the right kind of scaling then adjusting it to correct aspect ratio?

appiah4 wrote:

Wouldn't pixel-perfect scaling of 320x200 using square pixel flat panels result in wrong aspect ratios?

It is possible but not necessary. My patch, for example, will try to keep the right aspect ratio or at least to minimise the error. It can use 4:5 scaling (with a 4% error is aspect ratio) or 5:6 scaling (with an exact aspect ratio).

appiah4 wrote:

The resolution may be 4:4.8 but it was displayed on a 4:3 monitor..

It is not a resolution, but the horizontal and vertical scaling factors.

appiah4 wrote:

ScummVM may be doing the right kind of scaling then adjusting it to correct aspect ratio?

If so, it should not call this mode "pixel-perfect". In my experience and opinion, small errors in the aspect ratio are hardly noticeable, whereas irregular pixels and other scaling artefacts always look nasty.

Ant_222 wrote:

If so, it should not call this mode "pixel-perfect". In my experience and opinion, small errors in the aspect ratio are hardly noticeable, whereas irregular pixels and other scaling artefacts always look nasty.

That is your opinion. I find wrong aspect ratio to be terribly jarring, for example. Playing a 8:5 (320x200) pixel ratio game designed for a 4:3 aspect ratio CRT monitor implies 5:4 pixels. Pixel-perfect 5:4 aspect ratio displayed on a fixed square pixel panel means everything would look 6,66% taller, basically.

You may prefer that look, but it'd basically be showing you anything BUT how it should normally look. I prefer ScummVM's method, as it shows me an accurate representation of how it should actually look, which is the goal here.

appiah4 wrote:

That is your opinion.

The misleading use of the term pixel-perfect for something that is not so, is not a matter of opinion. The term pixel-perfect refers to sharp, regular pixels of identical size undistorted by any interpolation.

appiah4 wrote:

I find wrong aspect ratio to be terribly jarring, for example. Playing a 8:5 (320x200) pixel ratio game designed for a 4:3 aspect ratio CRT monitor implies 5:4 pixels.

No, it implies 5:6 pixels:

1320x200 (8:5) --[5x6]--> 1600x1200 (4:3)

appiah4 wrote:

Pixel-perfect 5:4 aspect ratio displayed on a fixed square pixel panel means everything would look 6,66% taller, basically.

That depends on how you display it. My patch can approximate the target PAR (pixel aspect ratio) by displaying each pixel as a 4:5 or 5:6 rectangle. In the latter case there is no distortion at all.

appiah4 wrote:

You may prefer that look, but it'd basically be showing you anything BUT how it should normally look. I prefer ScummVM's method, as it shows me an accurate representation of how it should actually look, which is the goal here.

Your concept of how it should actually look is rather fuzzy. Notice that we are talking about two kinds of error: a) the error of aspect ratio and b) the error of interpolation. Neither corresponds to how it should actually look. You just seem to prefer blurry and irregular pixels to a small error in the aspect ratio, whereas the general opinion among retro-gaming enthusiasts is that any interference with the fine structure of the image is a crime against pixel-art.

Edit: CRT emulation on high-resolution LCD displays is another matter because it keeps the pixels regular. The artefacts of CRT emulation are not side-effects of keeping the right aspect ratio but rather intentional and accurate enhancements.

Ant_222 wrote:

Bad news: both the screenshots use nearest-neighbor interpolation and have irregular pixel magnification, which means that the S […]
Show full quote

KainXVIII wrote:

@ant_222, here you go, btw, screenshots from latest ScummVM build (aspect correction on, 1080p)

Bad news: both the screenshots use nearest-neighbor interpolation and have irregular pixel magnification, which means that the ScummVM developers not only have failed to implement pixel-perfect scaling, but also are deceiving their users by calling nearest-neighbor interpolation to the correct aspect ratio "pixel-perfect":

Copy code to clipboard

1320x200 --[4.0x4.8]--> 1280x960

—only the horizontal scale is integral, whereas the vertical one is a fractional. It makes no sense.

Edit: To clarify—the rows in the "pixel-perfect" screenshot are magnified with alternating scales of 4 and 5 in a ratio of 1 to 4: 4, 5, 5, 5, 5, 4, 5, 5, 5, 5, ... yielding an average vertical scale of 24/5, or 4.8.

Interesting, still looks good to me (screenshots were taken in opengl graphics mode)
Here is screenshot in Normal (no scaling) graphics mode.

I need to pick another game though, preferably EGA with heavy dithering where all scaling artifacts can be seen clearly 😎

KainXVIII wrote:

Interesting, still looks good to me (screenshots were taken in opengl graphics mode)
Here is screenshot in Normal (no scaling) graphics mode.

Снимок экрана (173).png

It has some extremely rude glitches in the vertical direction. Just compare it with the original. Look, for example, at the "Options" gemstone in the lower-left corner. Its 45-digree sides are raggedy in your screenshot.

Ant_222 wrote:

KainXVIII wrote:

Interesting, still looks good to me (screenshots were taken in opengl graphics mode)
Here is screenshot in Normal (no scaling) graphics mode.

Снимок экрана (173).png

It has some extremely rude glitches in the vertical direction. Just compare it with the original. Look, for example, at the "Options" gemstone in the lower-left corner. Its 45-digree sides are raggedy in your screenshot.

Yes, OpenGl mode looks much better.

Ant_222 wrote:

I am very glad you like it, but don't know of any OS X build with my patch. Currently I see three ways to pixel-perfect display […]
Show full quote

citrixscu wrote:

Are there any builds for OSX that has this patch included? It’s awesome on Windows.

I am very glad you like it, but don't know of any OS X build with my patch. Currently I see three ways to pixel-perfect display in DOSBox:

1. A pixel shader for pixel-perfect scaling,
2. BladeSk's patch, and
3. My patch.

I suggest that you contact the maintainer of an OS X build with a proposal to implement one of the listed solutions. I can help with the generic algorithm of aspect-ratio approximation because some people don't make it right the fist time.

Also there was/is someone who implemented hq2x for SDL1 https://www.syntax-k.de/projekte/sdl-opengl-hq/ , SDL sources are way over my head, but would it be possible to implement this in SDL itself and leave dosbox alone ?
The current version of SDL is VERY stale, would be good to know if dosbox is transitioning to SDL2 at all before touching SDL, just to make sure.
As I understand the lib it only scales surface?/overlay output and falls back to normal opengl if opengl output is detected, I dont know how easy it is to replace SDL libs in other OSes than linux , have to try this one out and see if its still working.

ZakMcKracken,

No, I don't think that such a specific scaler is within the scope of the generic library that is SDL. It should be implemented in DOSBox, preferably as a pixel shader.

Upgrading to the latest SDL seems to me a task of medium difficulty. By the way, the new SDL supports hardware-accelerated pixel-perfect scaling via the SDL_RenderSetScale function, but the new openglpp mode in my patch already resolves any performance problems with the current SDL 1.2. .

As I understand the lib it only scales surface?/overlay output and falls back to normal opengl if opengl output is detected

I don't understand this sentence or question. As far as I know, SDL does not implement this fall-back logic, nor does it support the scaling of software surfaces. The normalNx scalers in stock DOSBox and the surface-based modes added by my patch are all performed in the CPU in a single thread.

The availability of the latest SDL not a problem. Migrating DOSBox to it, however, is. But this subject is off-topic here...

Yes, normal SDL does not scale , this is a custom patched SDL that scales non opengl surfaces according to the authors site using similar algorithms to hq2x, thats why threw the question in the room if your scaling could be implemented in SDL itself.

Strange situation about Spellcasting 101 and its EGA resolution(640x350), i somehow prefer openglnb mode aspect ratio despite garbled pixels 😕
Openglnb

vs Openglpp

console

KainXVIII wrote:

Strange situation about Spellcasting 101 and its EGA resolution (640x350), i somehow prefer openglnb mode aspect ratio despite garbled pixels

The situation is not favourable for the patch: the game's resolution is relatively large(640x350), the pixel aspect ratio (1.37) highly incommensurable, and your display resolution (1920x1080) not very large. The traditional question is—what would you expect the patch to do?

Edit: I was wrong about the high incommensurability of the original PAR. A 1920x1400 display will allow for excellent pixel-perfect scaling:

11.37 ~ 4/3
2640x350 --[3x4]--> 1920x1400

I am attempting to get pixel perfect scaling via dosbox on Raspberry Pi 4. I run it on a arcade monitor (CRT) at 240p via an analog connection.

Regular dosbox runs as intended, but the scaling options yield poor results.

Wondering if anyone here has any experience to apply this patch on a raspberry pi. I found the .diff file, but I don't know the procedure or potential results.

As a point of reference, I installed dosbox ECE, but it will not launch because it seems to require that I have a minimum of 640x480. It also will not launch opengl, I think because opengl only will launch from xorg, and xorg isn't really usable in 320*240.

Ant_222 wrote:

The patch scales the input image to the size of the window (if in windowed mode) or to the current resolution as reported by SDL (when if fullscreen mode). See if you can you that, but I don't think pixel-perfect scaling makes much sense on a low-res CRT monitor..

Actually, the lo-res makes dosbox aspect correction especially noticable. When playing games that have text in them, you can see clearly that normal2x doubles only every 5th line or something, and it shifts the doubled line in an inconsistent direction. This results in really terrible looking numbers and letters that aren't even consistently wrong on the same screen. For example, the number "2" will sometimes double the top line, sometimes the bottom, and sometimes the doubled line will end up in the middle, making it look like a "Z."

7F20 wrote:

Wondering if anyone here has any experience to apply this patch on a raspberry pi. I found the .diff file, but I don't know the procedure or potential results.

I have no experice with RPi and use the build procedure described here with no optional features. Applying the patch is as simple as calling

1patch -p0 < file.diff

from the source root.

As a point of reference, I installed dosbox ECE, but it will not launch because it seems to require that I have a minimum of 640x480.

Interesting. Could it be because of the custom splash screen?—ask here.

It also will not launch opengl, I think because opengl only will launch from xorg, and xorg isn't really usable in 320*240.

I have read in this thread that late RPi's can support OpenGL whereas earlier ones cannot.

Actually, the lo-res makes dosbox aspect correction especially noticable. When playing games that have text in them, you can see clearly that normal2x doubles only every 5th line or something, and it shifts the doubled line in an inconsistent direction. This results in really terrible looking numbers and letters that aren't even consistently wrong on the same screen. For example, the number "2" will sometimes double the top line, sometimes the bottom, and sometimes the doubled line will end up in the middle, making it look like a "Z."

Yes, it is the nearest-neighbor vertical scaling built into the stock DOSBox. normal2x should have no effect in your case because there is not enough space, and what you see is nearest-neighbor interpolation of 200 into 240, which relate as 4 to 5. Try setting aspect=false in the config file.

Since your screen is only 240x320, you don't need any scaling whatsoever, so my patch is unlikely to help...

Ant_222 wrote:

Applying the patch is as simple as calling […]
Show full quote

Applying the patch is as simple as calling

Copy code to clipboard

1patch -p0 < file.diff

from the source root.

Thank you.

Interesting. Could it be because of the custom splash screen?

That is very interesting. That actually might solve my whole problem.

Since your screen is only 240x320, you don't need any scaling whatsoever, so my patch is unlikely to help...

So... the theory with this goes (at least as I understand it) that you upscale to 1600x1200 and then output to 320x240. That way you get integer scaling in both directions. I was under the impression from reading various other comments that this was possible using ECE dosbox. Perhaps I'm actually barking up the wrong tree altogether.

7F20 wrote:

So... the theory with this goes (at least as I understand it) that you upscale to 1600x1200 and then output to 320x240.

No, I don't do that. The only possible integer scaling of 320x200 into 320x240 is with unity scales, that is no scaling at all. My patch will display that image at one-to-one scale, pixel-for-pixel, as 320x200 with 20-pixel black bars at top and bottom.

That way you get integer scaling in both directions.

No, it is impossible and my patch does not do any such thing. It can upscale the game image to 1600x1200 only if the original image dimensions are multiples of these and the output area (window or full screen) can accomodate it.

I was under the impression from reading various other comments that this was possible using ECE dosbox. Perhaps I'm actually barking up the wrong tree altogether.

What is it—running on RPi? Again, you may ask it in the ECE thread.

By the way, can you perform aspect-ratio correction using the analog control on your CRT display that stretches or compresses the image in the vertical direction?

Ant_222 wrote:

By the way, can you perform aspect-ratio correction using the analog control on your CRT display that stretches or compresses the image in the vertical direction?

Short answer is yes. Long answer is that there are no external controls to do so. I am quite used to opening up and repairing CRTs, but this set is troublesome and time-consuming to get to VSIZE. It would necessitate 30-45 min for each change and that would have to occur for every resolution. As much as I want a perfect VGA image, I also use it for DVDs and consoles. (and other non 320x200 PC games) I believe that some 2000's pro video monitors have external VSIZE, but it's not terribly common before that on 15kHz monitors. Devices made to be dedicated CGA monitors often had them for these reasons. My monitor is CGA, and has RGBI inputs, but they just expected the user to choose a input and calibrate the whole thing around it. In fact, Composite, svideo, RGBHV, and RGBI all have different screen centers. I generally use extron devices to switch between centers.

Sorry I couldn't figure out the patch. 🙁

I assume that you patch relies on the monitor to stretch the vertical in a 320x200 signal back out to the CGA height?

7F20 wrote:

Sorry I couldn't figure out the patch. :(

I assume that you patch relies on the monitor to stretch the vertical in a 320x200 signal back out to the CGA height?

My patch its intended mostly for modern LCDs with a fixed native resolution and square pixles. It cannot rely on the monitor for anything and upscales the orignal raster image with integer scaling factors. It is the responsibility of the renderer and monitor to display the upscaled image correctly. My patch is useless with a 320x240 monitor unless the program you run is 160x120 or smaller. I am not even sure such programs exist for MS-DOS...

Ant_222, the recent updates to SVN once again broke compatibility with your patch, it doesn't apply without errors any longer.

Yesterplay80 wrote on 2020-01-06, 18:17:

Ant_222, the recent updates to SVN once again broke compatibility with your patch, it doesn't apply without errors any longer.

I missed this post again. Will look into it as time permits.