Patch for pixel-perfect scaling [was:Full-screen mode]

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Patch for pixel-perfect scaling [was:Full-screen mode]

Postby Ant_222 » 2016-7-24 @ 20:25

Hello, all

I can't seem to find the code responsible for the stretching of the image to the display dimensions in full-screen mode, and neither do I see any invocations of SDL scaling functions. Where is does it happen?

The patch in included into the enhanced build by Yesterplay80.

Here is munt's MT32 patch modified by marooned_on_mars for compatibility with the pixel-perfect patch..

Edit: Uplodaing the Windows binary and the diff patch. The algorithm now respects the aspect setting.
Edit: This was required to play games whose native pixel aspect ratio is different from the one DOSBox assumes. Lure of the Temptress seems one of them.
Edit: If there be a place for credits in DOSBox, then let me thank Peter Karpov, known on Reddit as inversed, for the idea of the heruistic algorithm for the calculation of optimal scaling factors.
Edit: Fixed the patch. It had been generated incorrectly.
Edit: Fixed an error in the source which prevented compiling with Direct-Draw support enabled.
Edit: Fixed the patch. It was malformed.
Edit: Added a missing curly bracket.
Edit: Fixed a typo in code for DirectDraw output.
Edit: Uploaded a win32 build with the alpha 4 patch.
Edit: [2016-09-18] Uploaded the alpha 4 patch.
Edit: [2016-09-19] Fixed the alpha 4 patch
Edit: [2016-10-12] Uploaded the alpha 5 patch, which now extends the surface output type.
Edit: [2016-10-12] Added missing DLLs to the binary archive.
Edit: Uploaded the alpha 6 patch, which fixes a bug which broke the surface output type and has improved handling of the doubleheight and doublewidth flags.
Edit: [2016-10-13] Uploaded the alpha 7 patch, which fixes errors with the blitting output mode.
Edit: [2016-10-14] Uploaded the alpha 8 patch with performance improvements.
Edit: [2016-11-04] Uploaded the alpha 9 patch with new defaults and minor tweaks.
Edit: [2016-11-07] Alpha 10 is out. It fixes a typo which disabled the overlay output and corrects the upscaling of update rectangles.
Edit: [2016-11-19]Fixed errors in alpha10 when compiling on Linux with newer versions of gcc.
Edit: [2016-11-21]Added munt's MT32 patch fixed to be compatible with the pixel-perfect patch.
Edit: [2017-01-28]Uploaded alpha 12, which fixes an error in the calculation of the "perfect" scale. Special thanks to KainXVIII for extensive testing.
Attachments
pixel-perfect-alpha12-patch.zip
(21.8 KiB) Downloaded 28 times
pixel-perfect-alpha12-win32.zip
(1.23 MiB) Downloaded 26 times
pixel-perfect-alpha10-fixed-patch.zip
(21.86 KiB) Downloaded 30 times
pixel-perfect-alpha10-win32.zip
(1.23 MiB) Downloaded 54 times
Last edited by Ant_222 on 2017-1-28 @ 18:50, edited 33 times in total.
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby Qbix » 2016-7-24 @ 20:38

sdlmain.cpp and render.cpp are responsible for the stuff you want.

Good luck digging around.
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10248
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: Full-screen mode

Postby Ant_222 » 2016-7-24 @ 21:25

Thanks. I had already read those files, but it is hardware scaling that I am talking about, and I can't find where in the code it is performed or enabled. It depends on the type of the output surface, but where is this dependency expressed?
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby ripa » 2016-7-27 @ 20:39

For example, sdlmain.cpp GFX_EndUpdate:
Code: Select all
#if (HAVE_DDRAW_H) && defined(WIN32)
   case SCREEN_SURFACE_DDRAW:
      SDL_UnlockSurface(sdl.blit.surface);
      ret=IDirectDrawSurface3_Blt(
         sdl.surface->hwdata->dd_writebuf,&sdl.blit.rect,
         sdl.blit.surface->hwdata->dd_surface,0,
         DDBLT_WAIT, NULL);

DirectDraw does the HW scaling when source and destination surfaces have different dimensions.
ripa
Oldbie
 
Posts: 538
Joined: 2005-4-18 @ 00:53
Location: Finland

Re: Full-screen mode

Postby Ant_222 » 2016-7-27 @ 21:18

Thank you, ripa. That's what I mean by implicit. The same thing seems to take place with YUV overlays. I am trying to implement pixel-perfect integer scaling for full-screen mode, and I fear I shall have manually to convert the source image into an overlay or source surface with the dimensions equal to those of the target surface. That is going to be a relatively slow operation, but nothing better seems possible in SDL older than v. 2.
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby ripa » 2016-7-28 @ 23:14

There's output=openglnb which does not use filtering, so it's "pixel perfect", but if the destination dimensions aren't integer multiples of the source's, the pixels will be "uneven". There's also normal2x and normal3x software scalers which you can use in conjunction with output=surface which does not do scaling. So you'll be implementing something like normal4x (because there's already a patch for that somewhere)? Or normal3x2y or something like that (different x and y scaling factors)?
ripa
Oldbie
 
Posts: 538
Joined: 2005-4-18 @ 00:53
Location: Finland

Re: Full-screen mode

Postby Ant_222 » 2016-7-31 @ 18:07

In other words, openglnb is not pixel-perfect at non-integer scales, which is almost always the case in full-screen mode. The 'normal' scalers produce pixel-perfect image only with the 'surface' output device, and even then they don't always work (e.g. with double-height modes such as used in Romance of the Three Kingdoms). The very design of those scalers is wrong because new ones should be added manually as new resolutions appear. For example, "The Lure of the Temptress" running at 320x200 requires a 5x upscaling on my 1680x1050 display.

In my modification the best integer scale is calculated automatically, and I think I will manage to implement automatic pixel-perfect aspect correction as well. Here are screenshots from "Lure of the Temptress" and "Romance of the Three Kingdoms" running in fullscreen in the modified DOSBox with scaler=none and output=overlay.

I believe pixel-perfect scaling with aspect correction should be implemented in a general way as in my modification instead of hard-coding every one of them. Will such a patch be accepted?
Last edited by Ant_222 on 2016-7-31 @ 18:46, edited 1 time in total.
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby KainXVIII » 2016-7-31 @ 18:13

Nice work!
I still use old stable ykhwong build for pixel-perfect scaling (direct3d, bilinear.fx and normal5x scaler), maybe your method will be much better..
User avatar
KainXVIII
Member
 
Posts: 142
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Full-screen mode

Postby Ant_222 » 2016-7-31 @ 18:22

KainXVIII wrote:Nice work!
I still use old stable ykhwong build for pixel-perfect scaling (direct3d, bilinear.fx and normal5x scaler), maybe your method will be much better..


Thanks. It depends on how ykhwong implemented the scaling. Is it generic or does it have hard-coded integer scales? I didn't understand the "direct3d, bilinear.fx" part. Why are there different builds and patches scattered around but none of them included in the release?
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby Scali » 2016-7-31 @ 18:30

Ant_222 wrote:In other words, openglnb is not pixel-perfect at non-integer scales


Well, it's pretty much a given that if you don't scale with integers, you can't have pixel-perfect stretching, that's by definition :)
But I suppose you mean to say you want to have a 'nearest integer fit'.
How do you intend to handle differences in aspect ratio though? There are various different video modes in CGA/EGA/VGA/SVGA, and they can have different aspect ratios.
So in the cases where your fullscreen mode's aspect ratio does not match the aspect ratio of the emulated video mode, you can at best have a 'nearest integer fit' only in one direction, either X or Y.
Alternatively, you can have integer scaling for both, but you will distort the aspect ratio.

So how do you intend to handle that case?
Scali
l33t
 
Posts: 2337
Joined: 2014-12-13 @ 14:24

Re: Full-screen mode

Postby Ant_222 » 2016-7-31 @ 18:46

Scali wrote:Well, it's pretty much a given that if you don't scale with integers, you can't have pixel-perfect stretching, that's by definition :)
But I suppose you mean to say you want to have a 'nearest integer fit'.

I simply find the largest integer scale that keeps the image within the display. For example, if I need to scale a 320x200 image to my 1680x1050 monitor, I use a scale of 5 and get a 1600x1000 image with think black borders (as shown above).

Scali wrote:How do you intend to handle differences in aspect ratio though? There are various different video modes in CGA/EGA/VGA/SVGA, and they can have different aspect ratios.

You mean non-square pixels? I plan to approximate them by representing each pixel on the display as an m-by-n rectangle, where m and n are small natural numbers.

Scali wrote:So in the cases where your fullscreen mode's aspect ratio does not match the aspect ratio of the emulated video mode, you can at best have a 'nearest integer fit' only in one direction, either X or Y.
Alternatively, you can have integer scaling for both, but you will distort the aspect ratio.


That's right. The current version only supports uniform scaling, but I do plan to implement the nearest integer fit also. My algorithm already uses separate x and y scales, but I have yet to pass to it the necessary parameters to calculate them depending on the original aspect ratio.
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby KainXVIII » 2016-7-31 @ 19:27

Ant_222 wrote:
KainXVIII wrote:Nice work!
I still use old stable ykhwong build for pixel-perfect scaling (direct3d, bilinear.fx and normal5x scaler), maybe your method will be much better..


Thanks. It depends on how ykhwong implemented the scaling. Is it generic or does it have hard-coded integer scales? I didn't understand the "direct3d, bilinear.fx" part. Why are there different builds and patches scattered around but none of them included in the release?

Sorry, i don't know what method he uses, but its works
"direct3d, bilinear.fx" part

Its dosbox.conf settings for pixel perfect scaling which i use
output=direct3d
pixelshader=bilinear.fx
aspect=true
scaler=normal5x
User avatar
KainXVIII
Member
 
Posts: 142
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Full-screen mode

Postby Ant_222 » 2016-7-31 @ 19:29

KainXVIII, could you post screenshots of "Lure of the Temptress" and "Romance of the Three Kingdoms" running in full-screen on your DOSBox so that I might compare them with mine?
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby KainXVIII » 2016-7-31 @ 19:36

Ant_222 wrote:KainXVIII, could you post screenshots of "Lure of the Temptress" and "Romance of the Three Kingdoms" running in full-screen on your DOSBox so that I might compare them with mine?

Here LOT and SQ3 (ROTK is harder to get =) )
PS - maybe not so perfect as i think..
Attachments
lurafalse.png
sq3.png
lure.png
Last edited by KainXVIII on 2016-7-31 @ 19:43, edited 2 times in total.
User avatar
KainXVIII
Member
 
Posts: 142
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Full-screen mode

Postby Ant_222 » 2016-7-31 @ 19:40

Thank you, KainXVIII. That image is not pixel-perfect. Could you please make another screenshot with aspect=false?
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby KainXVIII » 2016-7-31 @ 19:43

Ant_222 wrote:Thank you, KainXVIII. That image is not pixel-perfect. Could you please make another screenshot with aspect=false?

Uploaded.
User avatar
KainXVIII
Member
 
Posts: 142
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Full-screen mode

Postby Ant_222 » 2016-7-31 @ 19:55

KainXVIII wrote:
Ant_222 wrote:KainXVIII, could you post screenshots of "Lure of the Temptress" and "Romance of the Three Kingdoms" running in full-screen on your DOSBox so that I might compare them with mine?

Here LOT and SQ3 (ROTK is harder to get =) )
PS - maybe not so perfect as i think..

Woops — Neither of them is pixel-perfect. Here's an 8x-magnified fragment of LOT. You can see that it is blurry.
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby KainXVIII » 2016-7-31 @ 20:07

Ant_222 wrote:
KainXVIII wrote:
Ant_222 wrote:KainXVIII, could you post screenshots of "Lure of the Temptress" and "Romance of the Three Kingdoms" running in full-screen on your DOSBox so that I might compare them with mine?

Here LOT and SQ3 (ROTK is harder to get =) )
PS - maybe not so perfect as i think..

Woops — Neither of them is pixel-perfect. Here's an 8x-magnified fragment of LOT. You can see that it is blurry.

Welp :depressed:
User avatar
KainXVIII
Member
 
Posts: 142
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Full-screen mode

Postby Ant_222 » 2016-7-31 @ 20:17

Fret not, I'm a-working on it.
Ant_222
Member
 
Posts: 217
Joined: 2010-7-24 @ 21:29

Re: Full-screen mode

Postby KainXVIII » 2016-7-31 @ 20:20

Ant_222 wrote:Fret not, I'm a-working on it.

Thanks, looking forward to it =)
User avatar
KainXVIII
Member
 
Posts: 142
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Next

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 2 guests