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.

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

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!

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

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

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?

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

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.

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.

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

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.

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?

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.

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.