VOGONS

Common searches


First post, by sy2002

User metadata
Rank Newbie
Rank
Newbie

EDIT: I added "and Linux" to the headline, as jmarsh reports a similar problem on Linux

Hi all,

I observed the following problem with 0.74-2 and with the latest SVN build on macOS Mojave (10.14.3) on a 2018 MacBook Pro. The problem is not observed on 0.74-1 (the special Mac version):

=> A thin red line is at the very bottom of the screen. And a thin red line is on the very right of the screen.

I use

fullresolution=2880x1800 (which is the native resolution of my display)
windowresolution=1024x768
output=opengl

If I switched to fullresolution=original, the problem is gone in fullscreen, but then, e.g. Wolfenstein3D looks very small. (I have scaler=none, because I want the opengl hardware scalers.)

Strange thing... ...any ideas?

Last edited by sy2002 on 2019-05-05, 00:46. Edited 1 time in total.

Reply 3 of 15, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

attached are the changes between 74-1 and 2 for the rendering.

Maybe cleaning the opengl buffer on each frame would fix it. (which is needed for opengl systems with 3 buffers and when interacting with the steam overlay).
(patch seems to be present in a lot of the steam released dosbox powered games)

Attachments

  • Filename
    opengl-clear.diff
    File size
    459 Bytes
    Downloads
    36 downloads
    File comment
    clearing
    File license
    Fair use/fair dealing exception
  • Filename
    2-main-render.diff
    File size
    28.9 KiB
    Downloads
    36 downloads
    File comment
    changes between 0.74-1 and 0.74-2 with regards to rendering
    File license
    Fair use/fair dealing exception

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 15, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

For me, if I disable the use of the pixel_buffer_object extension (or use openglnb instead of opengl) the problem goes away. So definitely seems like the filtering is sampling garbage pixels... but both the pbo and texture are the same width&height so I can't identify where they're coming from.

EDIT: I see now the texture is initialized with dimensions that are a power of 2. That's likely the problem then, the texture pixels outside the viewable area are never cleared and the bilinear sampling reads them when the right/bottom edges are rendered.
The easiest way to fix this would be to initialize the texture with the real width/height instead of padding to a power of two, pretty much all hardware supports it now since it was a core requirement for OpenGL 2.0. For extra safety you could check for the "GL_ARB_texture_non_power_of_two" extension, but I think there might be some implementations that don't bother to report it since it's been a core requirement for so long.
Alternatively one row and column of pixels just beyond width/height could be cleared to black when the texture is created (if linear filtering is active) for a cheap fix.

Reply 7 of 15, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Would opengl-clear work as "quick" fix ? non-2 textures are regardless of that not a bad idea.

Water flows down the stream
How to ask questions the smart way!

Reply 9 of 15, by kode54

User metadata
Rank Member
Rank
Member
jmarsh wrote:

Technically that should be done for the left/top co-ordinates too for the scaling to be correct.

Ah, yeah, you’re right.

This is because texture coordinates are relative to the top left of each texel cell, so 0.5 px would be centered.

Reply 10 of 15, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I can't really reproduce it on linux or windows, so that makes trying to fix it difficult.

Is a fullresolution of 2880x1800 really needed as I don't have a screen of that resolution.

Water flows down the stream
How to ask questions the smart way!

Reply 11 of 15, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Any non-power-of-two resolution should be enough.
I haven't seen it on windows, and it doesn't happen on linux for me unless the PBO extension is used (using nvidia's driver).
Might be possible to force it by setting the entire texture to a bright color when it's first initialized, then looking for that colour on the right/bottom edges (instead of the random stuff that we're seeing).

Reply 12 of 15, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Got to check if that extension is used on linux for me.
edit: it is used, but I am using intel

I was thinking would changing GL_CLAMP to GL_CLAMP_TO_BORDER help it? as that deals with textures.

Water flows down the stream
How to ask questions the smart way!

Reply 13 of 15, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
Qbix wrote:

I was thinking would changing GL_CLAMP to GL_CLAMP_TO_BORDER help it? as that deals with textures.

That only affects pixels returned for texture co-ordinates that point outside of the texture.

Reply 15 of 15, by hermit

User metadata
Rank Newbie
Rank
Newbie

I have a similar problem with the game "indiana jones last crusade action game"
at the third level, the image of the character is distorted
solutions? use dosbox-svn with Retropie
https://i.ibb.co/HtSX29C/indy-002.png
thanks