VIDEO Patch for pixel-perfect scaling (SDL1)

[Aideka]

Your screenshot looks great, KainXVIII. The problem must be in my ancient PC.

From your other post, where you mention that you have 1680x1050 resolution on your screen, it might explain the video not showing in the correct ratio.

[Ant_222]

Your screenshot looks great, KainXVIII. The problem must be in my ancient PC.

From your other post, where you mention that you have 1680x1050 resolution on your screen, it might explain the video not showing in the correct ratio.

Could be that, but I thought in that case I would have at least 720p, while the only available mode for me is 360p.

Please, notice that I have attached the diff patch to the initial post.

[Ant_222]

That at 100% zoom set in the browser your video has dimensions other than a multiple of the original and is blurry.

Hmm, are you sure that video quality is set to 1080p/60fps? And of course youtube encoder will add some blur (but not that much)

I wanted to post this link on Reddit but noticed that your screenshot is only 1529x796, while the image of Flashback is 684x599 pixels, which again is not even approximately a multiple of the original dimensions. Could you please check it again for me?

[KainXVIII]

Well, obviously you can't judge by youtube screenshots.

[Ant_222]

If the authors are not pleased with the relatively large amount of changes that I have introduced in the patch, I will remark that I refactored all the switch statements over the SCREEN_TYPES enumeration into a single point of dispatch simply to understand the code. The pixel-perfect scaling algorithm I implemented after that. Now I can revert the former and keep the latter, although I think that my work is only beneficial, because several switch statements over the same type reduce cohesion and cause the code responsible for handing each constant to be widely scattered. Let me know whether I should modify the patch in the said or another way to make it acceptable for release. My current plan is:

1. Support for windowed mode
1a. Use more elegant control of clip and consequently remove the manual centering from the scaling algorithm.
2. Extract portions of sdlmain.cpp into new files: ppscaling.cpp and screens.cpp. This will also require to rewrite the SDL_Block structure without anonymous substructures and to remove it into a separate .h file.

Then the source will be ready for implementing pixel-perfect scaling in a way independent of SCREEN_TYPES, if need be.

Edit: And then—for implementing generally the lossy interpolative scaling that many people seem to favor but must use hard-coded normal scalers.

Edit: I am leaving for a vacation this evening and shall not be available until the 1st of September.

[Ant_222]

Well, obviously you can't judge by youtube screenshots.

Maybe if you set 100% zoom in the browser and activate fullscreen mode in youtube, the video will be shown in its native 1080p (edit:on a 1080p monitor)?

[KainXVIII]

Well, obviously you can't judge by youtube screenshots.

Maybe if you set 100% zoom in the browser and activate fullscreen mode in youtube, the video will be shown in its native 1080p?

Maybe

[Ant_222]

Youtube needs a pixel-perfect patch.

[Ant_222]

Seems like nothing happened during my vacation, which is rather disconcerting. What can I do to make my patch acceptable?

[KainXVIII]

Is it me or image looks like slightly squished (like when aspect ratio=false in normal dosbox builds)

[Ant_222]

Is it me or image looks like slightly squished (like when aspect ratio=false in normal dosbox builds)

This is a 320x200 image scaled to 5x5 without aspect-ratio correction. Have you noticed in readme.txt that the latest "pixel-perfect" build respects the ratio setting, so you should probably set it to true? That failing, tell me the game.

Edit: Notice that with some games, such as Lure of the Temptress, you should set aspect to false.

[KainXVIII]

Is it me or image looks like slightly squished (like when aspect ratio=false in normal dosbox builds)

This is a 320x200 image scaled to 5x5 without aspect-ratio correction. Have you noticed in readme.txt that the latest "pixel-perfect" build respects the ratio setting, so you should probably set it to true? That failing, tell me the game.

Ha-ha, whoops, my bad! Its Jagged Alliance btw, now it looks perfect (if you don't mind black bars)

[Ant_222]

Its Jagged Alliance btw

It's a shame I haven't played this masterpiece, but X-Com is my favorite in the genre, and I wonder why on Earth and in the galaxyv it does not support hot-seat mode, especially considering that it was designed by the same guy as the Rebelstar series.

now it looks perfect

Almost perfect: upscaled to 4x5 instead of the ideal 5x6. It is the best you can get at 1920x1080.

(if you don't mind black bars) :cool:

Not at all, it is rather interpolaton artefacts that gall me and destroy pixel art in general.

[Ant_222]

Uploading a little modification that implementents, independently of the hard-coded normal scalers, the lossy interpolative scaling technique that is in favour with many gamers (see here, here, and here):

1. upscale the image in a pixel-perfect manner so that its dimensions exceed those of the display,
2. let the built-in bilinear interpolation downscale it back to the target dimensions and aspect ratio.

To activate it, simply use the overlay output in fullscreen and with scaler=none (see readme.txt).

The source needs some clean-up so I will attach it to the title post later. I still need advice on the preferred interface to these new scaling modes from the config file.

[VileRancour]

That seems to work alright, but I do have some questions:

- the pixel-perfect option only respects aspect correction *if* the resulting image fits in the desktop resolution - otherwise it falls back to an uncorrected aspect. Is that correct?
- is there a good reason for making this work with overlay, and overlay only? Because I'm seeing a couple of problems with that:

1. The result depends quite a bit on the environment (hardware, drivers, OS). In my case, the new ('overlay') method doesn't apply built-in(?) bilinear interpolation when the image is scaled back down to the target dimensions. Rather it's nearest-neighbor, so the result is identical to openglnb with its uneven pixels.
2. Apparently not all surfaces can be scaled this way. With machine=vgaonly (which IIRC renders at a different color depth than e.g. svga_s3) there is no upscaling at all.

I applaud the idea, since this is something I had been thinking about for a while, but never got around to looking into it. Due to these two things however, this doesn't deprecate normal4x/5x for me.

P.S.- please consider dedicating a new output= string value to the second method instead of reusing the existing "overlay", since modifying existing behavior is less likely to see a patch in mainline. Say "overlaynpp" ('near-pixel-perfect') or whatever.

[KainXVIII]

Uploading a little modification that implementents, independently of the hard-coded normal scalers, the lossy interpolative scaling technique that is in favour with many gamers (see here, here, and here):

1. upscale the image in a pixel-perfect manner so that its dimensions exceed those of the display,
2. let the built-in bilinear interpolation downscale it back to the target dimensions and aspect ratio.

To activate it, simply use the overlay output in fullscreen and with scaler=none (see readme.txt).

The source needs some clean-up so I will attach it to the title post later. I still need advice on the preferred interface to these new scaling modes from the config file.

Thanks, interesting update, but it gives me tiny vertical line on the right side of screen (is it normal?)

[Ant_222]

the pixel-perfect option only respects aspect correction *if* the resulting image fits in the desktop resolution - otherwise it falls back to an uncorrected aspect. Is that correct?

What were the resolutions of the game and of your desktop? It is simply impossible to have pixel-perfect aspect correction if the native desktop resolution is not high enough. For example—the standard 640x400 textmode on a 1680x1050 monitor can only be upscaled by a factor of two without aspect correction.

is there a good reason for making this work with overlay, and overlay only?

No. It is just that the code for overlay turns to be the simplest to modify, because it does not use optimized partial output via a sequence of rectangles but always blits the whole area. It is also important that it exists on all platforms, as distinct from ddraw, and in all environments, as distinct from opengl.

Because I'm seeing a couple of problems with that:

1. The result depends quite a bit on the environment (hardware, drivers, OS). In my case, the new ('overlay') method doesn't apply built-in(?) bilinear interpolation when the image is scaled back down to the target dimensions. Rather it's nearest-neighbor, so the result is identical to openglnb with its uneven pixels.

Could you please post an unmodified screenshot of this in the .gif or .png format? Are there any platform-independent surfaces where one can rely on bilinear scaling? If not, it must be implemented manually.

2. Apparently not all surfaces can be scaled this way. With machine=vgaonly (which IIRC renders at a different color depth than e.g. svga_s3) there is no upscaling at all.

Indeed. Although my algorithm does not depend on machine, DOSBox seems quietly to fall back to surface with vgaonly. Does anybody know why? I shall have to investigate.

P.S.- please consider dedicating a new output= string value to the second method instead of reusing the existing "overlay", since modifying existing behavior is less likely to see a patch in mainline. Say "overlaynpp" ('near-pixel-perfect') or whatever.

Yes, that is why I have requested advice on this from those responsible for accepting patches, but meseems we should determine whether we can get away with a single output type, for the structure of the corresponding config options will depend on that. If not overaly, it will have to be surface with a manually implemented bilinear downscaling.

Thank you very much for testing, VileRancour.

[Ant_222]

Thanks, interesting update, but it gives me tiny vertical line on the right side of screen (is it normal?)

Not at all. Is that where your taskbar menu is located? I also have this problem half the times. Switching to windowed mode and back to fullscreen sometimes helps. I have tried manually to fill with black pixels both the overlay and the underlying surface, but to no avail. I was going to ask for help with this after sorting out more important difficulties.

Edit: The problem seems present only when overlay automatically downscales a large image to fit into a clip smaller than the desktop. It might go away if we switch to surface.

[VileRancour]

What were the resolutions of the game and of your desktop? It is simply impossible to have pixel-perfect aspect correction if the native desktop resolution is not high enough. For example—the standard 640x400 textmode on a 1680x1050 monitor can only be upscaled by a factor of two without aspect correction.

320x200 and 1280x1024 respectively. I'm well aware that I'd need 1600x1200 for pixel-perfect scaling with aspect correction, just wanted to make sure that I'm seeing a deliberate fallback (i.e. that it wasn't just ignoring aspect= altogether, or anything like that).

Could you please post an unmodified screenshot of this in the .gif or .png format? Are there any platform-independent surfaces where one can rely on bilinear scaling? If not, it must be implemented manually.

Sure, here:

overlay.png

I dimly recall that there's some obscure application-specific NVidia driver setting that may or may not fix this, but I'll have to experiment later.
(you'll also note the funny DIR output, but I'm sure that's due to some oddity with libstdc++/libgcc rather than anything to do with scaling )

Indeed. Although my algorithm does not depend on machine, DOSBox seems quietly to fall back to surface with vgaonly. Does anybody know why? I shall have to investigate.

I believe it's the different bit depth, see vga_draw.cpp (line 1466). machine=vga renders at 16bpp which apparently doesn't play nice with overlay surfaces.

Yes, that is why I have requested advice on this from those responsible for accepting patches, but meseems we should determine whether we can get away with a single output type, for the structure of the corresponding config options will depend on that. If not overaly, it will have to be surface with a manually implemented bilinear downscaling.

The situation with SDL and different video drivers in different environments is such that, unfortunately, you can't seem to get a rendering method to work anywhere near the same in all cases. This has bugged me forever and I still have no idea what can be done to fix that, other than using software scalers.

The idea I had been thinking of way back was a 'smart' scaling method similar to yours, but generalized to arbitrary target resolutions (so that it'd work just as well in a window as in full screen), but naturally that'd be a bit more involved. Another unfortunate issue is that full-screen mode itself seems to be the root of most inconsistencies and problems with video rendering, at least as far as SDL is concerned. A "borderless window"-style fake full-screen mode seems to work well for most games these days, and I'm sure it'd do wonders for DOSBox too...

[Ant_222]

What were the resolutions of the game and of your desktop? It is simply impossible to have pixel-perfect aspect correction if the native desktop resolution is not high enough. For example—the standard 640x400 textmode on a 1680x1050 monitor can only be upscaled by a factor of two without aspect correction.

320x200 and 1280x1024 respectively. I'm well aware that I'd need 1600x1200 for pixel-perfect scaling with aspect correction, just wanted to make sure that I'm seeing a deliberate fallback (i.e. that it wasn't just ignoring aspect= altogether, or anything like that).

Then it should be corrected:

Code: Select all

320x200 * 4x5 = 1280x1000

If it is not the case for you I have a bug.

May I ask you to post a screenshot demonstrating the problem?