VIDEO Patch for pixel-perfect scaling (SDL1)

Here you can discuss the development of patches.

Re: Patch for pixel-perfect scaling

Postby KainXVIII » 2017-8-12 @ 15:43

I use surfacenp sometimes, surfacenb - never, i think.
User avatar
KainXVIII
Member
 
Posts: 216
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-12 @ 15:51

KainXVIII wrote:I use surfacenp sometimes, surfacenb - never, i think.
Noted. Do you see the difference between ~np and ~nb at your resolution?

It turns out that I can make surfacepp 30% faster if I re-implement it as a separate function instead of the generic scaling routine that I have now. I can still do it and keep the existing modes, although it will be more work. Edit: 50% faster.
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-8-12 @ 16:56

Ant_222 wrote:
KainXVIII wrote:I use surfacenp sometimes, surfacenb - never, i think.
Noted. Do you see the difference between ~np and ~nb at your resolution?

It turns out that I can make surfacepp 30% faster if I re-implement it as a separate function instead of the generic scaling routine that I have now. I can still do it and keep the existing modes, although it will be more work. Edit: 50% faster.

Personally, I like surfacenb for when I want window sizes smaller than what works well with surfacepp (like 800x600'ish). So I still see surfacenb as useful (and prefer it over np because of the sharper image).

Making surfacepp 50% faster would be awesome!
lukeman3000
Member
 
Posts: 188
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby KainXVIII » 2017-8-12 @ 18:47

Ant_222 wrote:
KainXVIII wrote:I use surfacenp sometimes, surfacenb - never, i think.
Noted. Do you see the difference between ~np and ~nb at your resolution?

Definitely noticeable differences (especially on EGA Sierra games with lot of dithering). Dunno about optimizing surfacepp, its already fast enough on my pc (maybe apart from switching to fullscreen and out, it can be a little faster for my preferences :blush: ), unlike surfacenp :dead: But still good news if it will work even faster!
User avatar
KainXVIII
Member
 
Posts: 216
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-8-12 @ 19:25

KainXVIII wrote:
Ant_222 wrote:
KainXVIII wrote:I use surfacenp sometimes, surfacenb - never, i think.
Noted. Do you see the difference between ~np and ~nb at your resolution?

Definitely noticeable differences (especially on EGA Sierra games with lot of dithering). Dunno about optimizing surfacepp, its already fast enough on my pc (maybe apart from switching to fullscreen and out, it can be a little faster for my preferences :blush: ), unlike surfacenp :dead: But still good news if it will work even faster!

surfacepp is definitely slower than other rendering modes like openglnb for example. Any kind of improvement would be great. Maybe the amount of slowdown is resoltion dependent, as I'm using 2560x1440?

I know I've mentioned this before, but I think it'd be cool if you could specify a "fallback" render mode when using surfacepp (such as surfacenb) which activates when the resolution is below threshold (which could be defined in the parameters). So something like

render: surfacepp
renderfallback: surfacenb
renderfallbackres: 1280x1024
lukeman3000
Member
 
Posts: 188
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby KainXVIII » 2017-8-12 @ 21:02

Maybe, my resolution is only 1080p.
User avatar
KainXVIII
Member
 
Posts: 216
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-13 @ 11:36

Thank you for your feedback.
lukeman3000 wrote:surfacepp is definitely slower than other rendering modes like openglnb for example. Any kind of improvement would be great. Maybe the amount of slowdown is resoltion dependent, as I'm using 2560x1440?
It certainly is. My software scaler slows down in quadratic(!) proportion to the resolution because it handles an approximately constant amount of megapixels per second. The only solution is to make the scaler hardware-accelerated, but that will require SDL 2.0, which is used in unofficial branches only. If anybody knows how to use pixel shaders with opengl in SDL 1.2, will they please help me with a pixel-perfect scaler for the opengl output mode?

Another way out would be to use CPU parallelization, for example via the OpenMP framework, but is not as good as pure hardware acceleration.
I know I've mentioned this before, but I think it'd be cool if you could specify a "fallback" render mode when using surfacepp (such as surfacenb) which activates when the resolution is below threshold (which could be defined in the parameters). So something like
Code: Select all
render: surfacepp
renderfallback: surfacenb
renderfallbackres: 1280x1024
That is possible but not top-priority now. The developers have told me they are very conservative about adding new parameters to the config file, and I fear that I have added too many already. If my (or analogous) patch is not included into the official SVN, my work will be more or less wasted. By the way, it is better to decide whether to fallback based on the aspect-ratio error, is it not?

You said you find surfacenp useful—why not use openglnb instead? Is it not available on your system?
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-8-14 @ 05:44

Ant_222 wrote:Thank you for your feedback.
lukeman3000 wrote:surfacepp is definitely slower than other rendering modes like openglnb for example. Any kind of improvement would be great. Maybe the amount of slowdown is resoltion dependent, as I'm using 2560x1440?
It certainly is. My software scaler slows down in quadratic(!) proportion to the resolution because it handles an approximately constant amount of megapixels per second. The only solution is to make the scaler hardware-accelerated, but that will require SDL 2.0, which is used in unofficial branches only. If anybody knows how to use pixel shaders with opengl in SDL 1.2, will they please help me with a pixel-perfect scaler for the opengl output mode?

Another way out would be to use CPU parallelization, for example via the OpenMP framework, but is not as good as pure hardware acceleration.
I know I've mentioned this before, but I think it'd be cool if you could specify a "fallback" render mode when using surfacepp (such as surfacenb) which activates when the resolution is below threshold (which could be defined in the parameters). So something like
Code: Select all
render: surfacepp
renderfallback: surfacenb
renderfallbackres: 1280x1024
That is possible but not top-priority now. The developers have told me they are very conservative about adding new parameters to the config file, and I fear that I have added too many already. If my (or analogous) patch is not included into the official SVN, my work will be more or less wasted. By the way, it is better to decide whether to fallback based on the aspect-ratio error, is it not?

You said you find surfacenp useful—why not use openglnb instead? Is it not available on your system?

I do have access to openglnb, so they're the same? If so then I guess it doesn't matter (for me) since I don't use surfacenp.

Good question, whether to fall back based on aspect ratio error or a pre-determined resolution? I'm not sure. Seems like they may be kind of one and the same, because my goal of being able to fall back based on a pre-set resolution was based on the avoidance of a high aspect ratio error.
lukeman3000
Member
 
Posts: 188
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby gulikoza » 2017-8-15 @ 16:13

Ant_222 wrote:If anybody knows how to use pixel shaders with opengl in SDL 1.2, will they please help me with a pixel-perfect scaler for the opengl output mode?


3Dfx code uses pixel (fragment) shaders...even generates them dynamically based on (emulated) hw state.
Check the code (search for glCreateShaderObjectARB).
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-24 @ 21:01

Solanacean, I now want to release a normal fix for the problem with the color layout instead of the crutches I made for you. Will you please test the attached patch? Checking surfacepp and surfacenp will be enough.
You do not have the required permissions to view the files attached to this post.
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby lukeman3000 » 2017-8-25 @ 04:57

Hey Ant,

Noticed an interesting issue with the patch. When playing King's Quest 1, whose native resolution is 320x200, if I want to scale it up to 960x800 then I have to set the window resolution in dosbox to 960x801.

However, if I want to scale up to 1280x1000, then I can set the window resolution to exactly that. Why do I have to add an extra line of resolution when using 960x800 in order for it to work? Otherwise, the aspect ratio is messed up, as seen here, because it scales to 960x600 for some reason.
lukeman3000
Member
 
Posts: 188
Joined: 2009-3-17 @ 00:59

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-25 @ 08:30

lukeman3000 wrote:Noticed an interesting issue with the patch. When playing King's Quest 1, whose native resolution is 320x200, if I want to scale it up to 960x800 then I have to set the window resolution in dosbox to 960x801
Probably because of rounding errors—I will look into it.
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Solanacean » 2017-8-25 @ 09:39

Ant_222 wrote:Solanacean, I now want to release a normal fix for the problem with the color layout instead of the crutches I made for you. Will you please test the attached patch? Checking surfacepp and surfacenp will be enough.

Unfortunately, it won't build.

Code: Select all
g++ -DHAVE_CONFIG_H -I. -I../..  -I../../include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE  -g -O2 -mno-ms-bitfields  -MT pixelscale.o -MD -MP -MF .deps/pixelscale.Tpo -c -o pixelscale.o pixelscale.cpp
pixelscale.cpp:593:69: error: ISO C++ forbids declaration of 'loopx_nb' with no type [-fpermissive]
 ( info* si, ps_rect *area, uchar* src, uchar* mid_row, rowstart* rs )
                                                                     ^
pixelscale.cpp:612:1: error: ISO C++ forbids declaration of 'loopx_np' with no type [-fpermissive]
 )
 ^
make[3]: *** [pixelscale.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Solanacean
Newbie
 
Posts: 21
Joined: 2017-4-03 @ 00:00
Location: Russia

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-25 @ 10:07

Solanacean wrote:Unfortunately, it won't build.
Your compiler settings are more strict than mine. Will you please add return type void to the functions loopx_np and loopx_np:
Code: Select all
static void loopx_nb
static void loopx_np
I will fix it my source when I come home.
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Solanacean » 2017-8-25 @ 10:52

Fantastic work, Ant_222. Both modes are now completely glitch free! One thing though, is 320x200 game supposed to scale like this with output=surfacenp?

Code: Select all
CONFIG:Loading primary settings from config file dsun.conf
MIDI: Opened device:coreaudio
Available area: 1440x900
Color data offset: 1
Scaling: 640x400 (1.00) --[2.2 x 2.2]--> 1440x900  (1.00)
Available area: 1440x900
Color data offset: 1
Scaling: 320x200 (1.00) --[4.5 x 4.5]--> 1440x900  (1.00)
Available area: 1424x858
Color data offset: 1
Scaling: 320x200 (1.00) --[4.3 x 4.3]--> 1373x858  (1.00)
Last edited by Solanacean on 2017-8-25 @ 11:03, edited 1 time in total.
Solanacean
Newbie
 
Posts: 21
Joined: 2017-4-03 @ 00:00
Location: Russia

Re: Patch for pixel-perfect scaling

Postby Solanacean » 2017-8-25 @ 11:00

Not sure if it's worth mentioning, but if I minimize the window and then bring it back, I get this:
You do not have the required permissions to view the files attached to this post.
Solanacean
Newbie
 
Posts: 21
Joined: 2017-4-03 @ 00:00
Location: Russia

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-25 @ 12:00

Solanacean wrote:Both modes are now completely glitch free! One thing though, is 320x200 game supposed to scale like this with output=surfacenp?
Code: Select all
CONFIG:Loading primary settings from config file dsun.conf
MIDI: Opened device:coreaudio
Available area: 1440x900
Color data offset: 1
Scaling: 640x400 (1.00) --[2.2 x 2.2]--> 1440x900  (1.00)
Available area: 1440x900
Color data offset: 1
Scaling: 320x200 (1.00) --[4.5 x 4.5]--> 1440x900  (1.00)
Available area: 1424x858
Color data offset: 1
Scaling: 320x200 (1.00) --[4.3 x 4.3]--> 1373x858  (1.00)
What is the problem exactly—that PAR = 1.0?
Not sure if it's worth mentioning, but if I minimize the window and then bring it back, I get this:
It is. Does it go away when the screen is updated or does it stay? I might need to add some initialization to the pixel array... Edit: when you are having the bug, does log consistently say that the color data offset is equal to one?
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

Re: Patch for pixel-perfect scaling

Postby Solanacean » 2017-8-25 @ 12:24

Ant_222 wrote:What is the problem exactly—that PAR = 1.0?

Well, I'm not sure there's one, that's why I'm asking. =) There are no black bars on the left and right sides, the image fits the screen completely - is it how it's supposed to be?

Ant_222 wrote:Does it go away when the screen is updated or does it stay?

It goes away completely after I switch to fullscreen, but if I don't, it stays like that. The attached screenshots show what it looks like before the screen is cleared with cls command (I assume that it should update the screen) and after.

Ant_222 wrote:when you are having the bug, does log consistently say that the color data offset is equal to one?

Yes, it does.
You do not have the required permissions to view the files attached to this post.
Last edited by Solanacean on 2017-8-25 @ 13:26, edited 1 time in total.
Solanacean
Newbie
 
Posts: 21
Joined: 2017-4-03 @ 00:00
Location: Russia

Re: Patch for pixel-perfect scaling

Postby Solanacean » 2017-8-25 @ 12:48

I've just checked - the same thing happens with output=surface.
output=opengl and output=openglnb are fine
With output=overlay the dosbox screen blinks for a second after I restore the minimized window, but apart from that, there doesn't seem to be any problem.
Solanacean
Newbie
 
Posts: 21
Joined: 2017-4-03 @ 00:00
Location: Russia

Re: Patch for pixel-perfect scaling

Postby Ant_222 » 2017-8-25 @ 12:52

Solanacean wrote:I've just checked - the same thing happens with output=surface.
output=opengl and output=openglnb are fine
With output=overlay the dosbox screen blinks for a second after I restore the minimized window, but apart from that, there doesn't seem to be any problem.
But there is no such problem with the Official SVN DosBOX?
Ant_222
Member
 
Posts: 330
Joined: 2010-7-24 @ 21:29

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest