I use surfacenp sometimes, surfacenb - never, i think.

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 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!

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 😊 ), unlike surfacenp 😵 But still good news if it will work even faster!

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 😊 ), unlike surfacenp 😵 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

Maybe, my resolution is only 1080p.

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 ( […]
Show full quote

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

Copy code to clipboard

1render: surfacepp
2renderfallback: surfacenb
3renderfallbackres: 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 wrote:

Thank you for your feedback. […]
Show full quote

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 ( […]
Show full quote

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

Copy code to clipboard

1render: surfacepp
2renderfallback: surfacenb
3renderfallbackres: 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.

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).

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.

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 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 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.

1g++ -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
2pixelscale.cpp:593:69: error: ISO C++ forbids declaration of 'loopx_nb' with no type [-fpermissive]
3 ( info* si, ps_rect *area, uchar* src, uchar* mid_row, rowstart* rs )
4                                                                     ^
5pixelscale.cpp:612:1: error: ISO C++ forbids declaration of 'loopx_np' with no type [-fpermissive]
6 )
7 ^
8make[3]: *** [pixelscale.o] Error 1
9make[2]: *** [all-recursive] Error 1
10make[1]: *** [all-recursive] Error 1
11make: *** [all] Error 2

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:

1static void loopx_nb
2static void loopx_np

I will fix it my source when I come home.

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?

1CONFIG:Loading primary settings from config file dsun.conf
2MIDI: Opened device:coreaudio
3Available area: 1440x900
4Color data offset: 1
5Scaling: 640x400 (1.00) --[2.2 x 2.2]--> 1440x900  (1.00)
6Available area: 1440x900
7Color data offset: 1
8Scaling: 320x200 (1.00) --[4.5 x 4.5]--> 1440x900  (1.00)
9Available area: 1424x858
10Color data offset: 1
11Scaling: 320x200 (1.00) --[4.3 x 4.3]--> 1373x858  (1.00)

Not sure if it's worth mentioning, but if I minimize the window and then bring it back, I get this:

Solanacean wrote:

Both modes are now completely glitch free! One thing though, is 320x200 game supposed to scale like this with output=surfacenp? […]
Show full quote

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

Copy code to clipboard

1CONFIG:Loading primary settings from config file dsun.conf
2MIDI: Opened device:coreaudio
3Available area: 1440x900
4Color data offset: 1
5Scaling: 640x400 (1.00) --[2.2 x 2.2]--> 1440x900  (1.00)
6Available area: 1440x900
7Color data offset: 1
8Scaling: 320x200 (1.00) --[4.5 x 4.5]--> 1440x900  (1.00)
9Available area: 1424x858
10Color data offset: 1
11Scaling: 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 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.

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 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?