VOGONS

Common searches


Reply 401 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 402 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member
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!

Reply 403 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
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!

Reply 404 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member
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

Reply 406 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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

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?

Reply 407 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member
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

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.

Reply 408 of 733, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie
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).

http://www.si-gamer.net/gulikoza

Reply 409 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Attachments

  • Filename
    RGBfix.patch
    File size
    84.06 KiB
    Downloads
    84 downloads
    File license
    Fair use/fair dealing exception

Reply 410 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member

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.

Reply 411 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 412 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
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.

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

Reply 413 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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:

static void loopx_nb
static void loopx_np

I will fix it my source when I come home.

Reply 414 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie

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?

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-08-25, 11:03. Edited 1 time in total.

Reply 415 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie

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

Attachments

Reply 416 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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?

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?

Reply 417 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
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.

Attachments

Last edited by Solanacean on 2017-08-25, 13:26. Edited 1 time in total.

Reply 418 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 419 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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?