VOGONS

Common searches


Reply 360 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie

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:

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

Console output in fullscreen mode:

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

Reply 362 of 733, by Solanacean

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

Reply 364 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 365 of 733, by Solanacean

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

Reply 367 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote:

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

Yes, surface works like a charm.

Attachments

Reply 370 of 733, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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.

Last edited by Serious Callers Only on 2017-07-16, 12:51. Edited 5 times in total.

Reply 372 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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:

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

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?

Reply 374 of 733, by Serious Callers Only

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

Reply 375 of 733, by Ant_222

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

Attachments

  • Filename
    ssPsEndUpdate.cpp
    File size
    750 Bytes
    Downloads
    61 downloads
    File license
    Fair use/fair dealing exception

Reply 376 of 733, by Solanacean

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

Attachments

Reply 377 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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?

Reply 378 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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

Attachments

  • Filename
    ssPsEndUpdate.cpp
    File size
    871 Bytes
    Downloads
    47 downloads
    File license
    Fair use/fair dealing exception

Reply 379 of 733, by Solanacean

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