Yes, this also happens in fullscreen.

Currently I use these settings:

fullscreen=false
fulldouble=false
fullresolution=desktop
windowresolution=desktop
output=surfacepp

aspect=false
scaler=none

I've been playing with the settings, applying different scalers, changing aspect, trying different resolutions and pixel-perfect modes, it's still the same.

Console output in windowed mode:

1Annas-MacBook-Pro:dosbox-svn anna$ ./dosbox -conf ccs
2DOSBox version SVN
3Copyright 2002-2017 DOSBox Team, published under GNU GPL.
4---
5CONFIG:Loading primary settings from config file ccs
6MIDI: Opened device:mt32
7Available area: 1424x858
8Scaling: 640x400 (2.00) --[1.0 x 2.0]-->  640x800  (2.00)
9Available area: 1424x858
10Scaling: 640x480 (1.00) --[1.0 x 1.0]-->  640x480  (1.00)

Console output in fullscreen mode:

1Annas-MacBook-Pro:dosbox-svn anna$ ./dosbox -conf ccs
2DOSBox version SVN
3Copyright 2002-2017 DOSBox Team, published under GNU GPL.
4---
5CONFIG:Loading primary settings from config file ccs
6MIDI: Opened device:mt32
7Available area: 1440x900
8Scaling: 640x400 (2.00) --[1.0 x 2.0]-->  640x800  (2.00)
9Available area: 1440x900
10Scaling: 640x480 (1.00) --[1.0 x 1.0]-->  640x480  (1.00)

What build do you use? Could we perhaps ask its author whether my patch works well for him? Or is it your own build?

Ant_222 wrote:

What build do you use? Could we perhaps ask its author whether my patch works well for him? Or is it your own build?

Yes, it's my own build. I've used the latest version of the patch and the latest dosbox source code from svn. It was built with Clang (not sure if it's important).

Sorry, accidentally quoted my previous post while trying to edit it.

You did not turn on surface-collapse-dbl, did you? Could you please try compiling plain vanilla DOSBox with my patch only? Also, if you happen to have a Windows machine, it would be great if you would compile the same source on Windows to test whether the problem OS-dependent, or compiler-dependent.

Ant_222 wrote:

You did not turn on surface-collapse-dbl, did you?

No, I didn't.

Ant_222 wrote:

Could you please try compiling plain vanilla DOSBox with my patch only? Also, if you happen to have a Windows machine, it would be great if you would compile the same source on Windows to test whether the problem OS-dependent, or compiler-dependent.

Here’s what I did: I've compiled dosbox r4025 with the latest version of the pixel-perfect patch (alpha 12) and no other patches, using GCC instead of Clang, on the same hardware, under the same OS (OS X Yosemite), the result is exactly the same. I've also tried alpha 10 version of the patch, still no luck.

Thank you. I will try to recompile it again from the patch. Does the standard output type surface work in the patched version?

Ant_222 wrote:

Does the standard output type surface work in the patched version?

Yes, surface works like a charm.

OK. As I understand the problem with PixelPerfect is present in all graphical modes, including the initial text mode, but, out of curiosity, what game is it?

It's Callahan's Crosstime Saloon.

I tried your patch ant. While it doesn't appear to solve my most annoying problems; fullscreen opengl rez changes showing the desktop and insisting on stretching, i've since found that at least the stretching in fullscreen mode is due to the mesa drivers (protip: xrandr --output LVDS --set "scaling mode" "Full aspect" will disable this, unfortunately not per application).

It's a bit annoying because opengl is the only way to have acceptable glide emulation.

Anyway, i found something strange but good while testing it. Tomb Raider 1 voodoo rush videos in:
[sdl]
fullresolution=original
output=openglnb

are usually so slow you can see the raster of the video frame drawing. With your patch, they're fullspeed, even if the output is not your new one. I think dosbox has some kind of inefficiency on code your patch touches that it fixes. I'd love if you could get upstream to fix it.

edit: seems to be caused - at least in this game - by my cpu speed being pitiful (1.2ghz), so the 'max' is small enough the game doesn't get full speed FMVs all the time (unlike if i use a large fixed value, say 50000, and slow down the main gameplay that way). Doesn't really explain why FMVs in the game are much faster with your patch though, there is something super inefficient there.

double post

Solanacean, I have a few possible culprits in mind and will ask you to test modified versions of patch as time permits. I intend a) to enforce the locking of the surface before output, b) to save memory dumps of both the original and upscaled image to the HDD to see where the error is introduced, and c) to upscale the whole image at every frame rather than only the updated rectangles.

Serious Callers Only wrote:

I tried your patch ant. While it doesn't appear to solve my most annoying problems; fullscreen opengl rez changes showing the desktop and insisting on stretching, i've since found that at least the stretching in fullscreen mode is due to the mesa drivers (protip: xrandr --output LVDS --set "scaling mode" "Full aspect" will disable this, unfortunately not per application).

My patch should not affect the opengl mode.

Anyway, i found something strange but good while testing it. Tomb Raider 1 voodoo rush videos in: […]
Show full quote

Anyway, i found something strange but good while testing it. Tomb Raider 1 voodoo rush videos in:

Copy code to clipboard

1[sdl]
2fullresolution=original
3output=openglnb

are usually so slow you can see the raster of the video frame drawing. With your patch, they're fullspeed, even if the output is not your new one. I think dosbox has some kind of inefficiency on code your patch touches that it fixes. I'd love if you could get upstream to fix it.

That is strange, for I have tried not to affect the existing output modes in any way. Everything pertaining to OpenGL my patch extracts into the functions starting with the og prefix in src/gui/sdlmain.cpp. They all contain copy-pasted code from the huge and messy switch statements of the SVN version. I have glanced at this code and did not find any changes that could have caused this unexpected improvement :-(

EDIT: With regard to the error Solanacean has, can you please confirm that the new output modes work correctly for you?

Ant_222, I'll be happy to test them out. Thank you for all your hard work, it is much appreciated.

Ant_222 wrote:

I have glanced at this code and did not find any changes that could have caused this unexpected improvement 🙁

Eh... no big deal - as i mentioned, this doesn't happen if the game has enough cycles. Before i was using 'cycles=max' and saw this discrepancy with your patch applied and without; because my 'max' wasn't exactly 'enough' for the game, but if I manually set a high value (50000-70000), the videos play fine and gameplay (although the actual frame rate slows down, but in-game fps is maxed at 30). I just thought it funny that a refactoring could have such a extreme performance effect and wanted to check back with you if it's some bug on upstream.

Solanacean wrote:

I'll be happy to test them out. Thank you for all your hard work, it is much appreciated.

Since I am not proficient in making patches, can you please test my patch with the modified function ssPsEndUpdate() from sdlmain.cpp. Just copy it from the attachment paste into sdlmain.cpp.

Ant_222 wrote:

Since I am not proficient in making patches, can you please test my patch with the modified function ssPsEndUpdate() from sdlmain.cpp. Just copy it from the attachment paste into sdlmain.cpp.

Done. It glitches even more severely with the modified function.

Very well. Updating the full screen shows the true nature of the glitch. The blue channel is totally off. I will send you another debug version.

EDIT:The bug is in my patch and it is probably due to the difference in endianness between our machines. Is yours big- or little-endiean?

Solanacean, please replace the function ssPsEndUpdate in sdlmain.cpp with the one attached and test again.

Ant_222 wrote:

The bug is in my patch and it is probably due to the difference in endianness between our machines. Is yours big- or little-endiean?

It's little-endian. All modern macs are, the transition from PowerPC (which was big-endian) to Intel happened a long time ago.