VOGONS


Patch for OpenGL fullscreen bug

Topic actions

First post, by hakonrk

User metadata
Rank Newbie
Rank
Newbie

I finally had enough of a longstanding bug that happened with OpenGL in fullscreen (only when using output = opengl, not when using openglnb). I would get a pixel-wide bright line on the bottom and right sides of the screen, as if the texture was just a little bit smaller than the graphics card expected, making it display uninitialized bytes at the edges. Not sure if this is a common problem, but it did happen on my system (DOSBox 0.74, Fedora 14 (x86_64), NVIDIA GTX280 card), so here's a patch just in case:

--- src/gui/sdlmain.cpp.orig	2010-05-10 19:43:54.000000000 +0200
+++ src/gui/sdlmain.cpp 2011-02-18 09:24:58.809565276 +0100
@@ -622,8 +622,8 @@
glMatrixMode (GL_MODELVIEW);
glLoadIdentity ();

- GLfloat tex_width=((GLfloat)(width)/(GLfloat)texsize);
- GLfloat tex_height=((GLfloat)(height)/(GLfloat)texsize);
+ GLfloat tex_width=((GLfloat)(width-1)/(GLfloat)texsize);
+ GLfloat tex_height=((GLfloat)(height-1)/(GLfloat)texsize);

if (glIsList(sdl.opengl.displaylist)) glDeleteLists(sdl.opengl.displaylist, 1);
sdl.opengl.displaylist = glGenLists(1);

Reply 1 of 39, by cfoesch

User metadata
Rank Newbie
Rank
Newbie

It seems a little odd to me that the solution to "it's not wide enough" would be to subtract one from the width... not really doubting you, but it seems counter intuitive...

Reply 2 of 39, by hakonrk

User metadata
Rank Newbie
Rank
Newbie
cfoesch wrote:

It seems a little odd to me that the solution to "it's not wide enough" would be to subtract one from the width... not really doubting you, but it seems counter intuitive...

width and height refer to the source image, not the output, right? If so, it makes sense to me that subtracting one pixel from them would work.

Just tried adding one to the width/height instead of subtracting; the result is that the the white border lines become twice as thick.

Reply 4 of 39, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Need to check how it looks on os x, never noticed the white line but I seldom run dosbox fullscreen

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 5 of 39, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Wonder how to fix this 😁

The S3 onboard savage or its drivers might play a role here; however other OpenGL stuff works (such as kekkos 3dfx output)

Texture too big?

Attachments

  • output_opengl.png
    Filename
    output_opengl.png
    File size
    70.96 KiB
    Views
    15792 views
    File license
    Fair use/fair dealing exception

1+1=10

Reply 6 of 39, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Hey man, nice shot;)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 7 of 39, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

IMO the original code is correct. Maybe you can visually-debug this a bit further,
like using the old code and feeding custom patterns to glTexSubImage2D during the
rendering, or changing GL_CLAMP to something different to check edge behaviour.

Reply 8 of 39, by FrodeSFS

User metadata
Rank Newbie
Rank
Newbie

As has been pointed out, the original code is correct. Your patch may seem to fix the problem (but really cuts off part of DOS screen).

The underlying reason for the problem is using a texture that is larger than the dos screen, using sub textures to update, and then draw only the relevant part of the texture to the display. This, combined with linear filtering, causes "color bleed" from texture pixels outside the dos screen (these pixels are "random garbage", and causes the lines you see).

What I have done in my own DOSBox build is this:
- when dosbox changes resolution, I create a "bitmap" in memory (well, just a char buffer), initializes is to all zeroes (with memset), and uploads to the dosbox opengl texture using glTexture2D - causing the entire texture (including the parts outside the DOS screen) to be set to black, overwriting the garbage that would otherwise be stored there. This effectively removes the display artifacts you are seeing.

(Another option is to convert dosbox code to using texture rectangle. Since the texture then can be the exact size of the DOS screen, the color bleed effect will also disappear).

Reply 9 of 39, by VileR

User metadata
Rank Oldbie
Rank
Oldbie

I've noticed similar behavior when output=overlay, except that the "line" is black rather than white. The only effect being that the bottom row of (emulated) pixels isn't full height.

(DosBOX 0.74, winXP/32, nVidia GeForce 7300 SE)

Reply 10 of 39, by snakesqzns

User metadata
Rank Newbie
Rank
Newbie

I have a similar issue (in 0.74-1 *and* SVN head) when using output=opengl|openglnb, aspect=true, and running fullscreen. What should be two black bars on the right and left of the screen are instead artifacts. Usually, these artifacts are easily recognizable as graphics from previously run games.

This leads me to believe that there's a buffer somewhere that isn't being cleared. I've tried replacing all buffer calls to malloc with calloc that I could find, but nothing seems to work. The issue may be related to some doublebuffering, as every other screen update looks okay (i.e., frame 1 - artifacted borders, frame 2- black borders, frame 3- same artifacts again). However, turning off doublebuffering settings within dosbox have no effect.

I'm sort of thinking this might be and SDL bug... It looks like SDL enables double buffering whenever SDL_OPENGL is set...

I really hope to get this issue resolved soon -- it's the only thing holding me back from releasing a GLSL patch for Dosbox.

Shown here using the bsnes OpenGL.CRT shader: screenshotdosboxcvscpus.png

Note that the artifacting I described above only shows up on the right and bottom when using this shader.[/img]

Reply 11 of 39, by VileR

User metadata
Rank Oldbie
Rank
Oldbie
snakesqzns wrote:

Shown here using the bsnes OpenGL.CRT shader:

(image)

dear snakesqzns;

I don't know where/how you came up with this, but IT LOOKS ABSOLUTELY FANTASTIC. THIS NEEDS TO HAPPEN.

please, if any coders here can help this man, do it, for the love of the retro gods.
THINK OF THE CHILDREN!

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 13 of 39, by snakesqzns

User metadata
Rank Newbie
Rank
Newbie

I was just going to link to http://www.si-gamer.net/gulikoza/, then I noticed it was you!

This is the GLSL shader being used in that screenshot: https://gitorious.org/bsnes/bsnes/blobs/5e828 … s.OpenGL.shader

You can try converting it to HLSL and use gulikoza's Dosbox.

Reply 14 of 39, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

You've said OpenGL.CRT shader 😕. caligari's scanlines does not seem to have barrel distortion.
In any case, you did not open the linked thread, yes? 😁

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

Reply 15 of 39, by snakesqzns

User metadata
Rank Newbie
Rank
Newbie

Guess I had a seizure or something.

The shader in the screenshot is indeed OpengGL.CRT (https://gitorious.org/bsnes/bsnes/blobs/5e828 … T.OpenGL.shader).

I did see your linked thread btw.

Reply 16 of 39, by dosmax

User metadata
Rank Newbie
Rank
Newbie

This shader is the best CRT simulation so far. No doubt. But I think there is still some room for enhancements. Besides barrel distortion, in reality there are two effects that define the special look of a CRT display. The first one are the scanlines. These are defined by the image resolution (translating to the number of rows the cathode ray travels from top to bottom). The second one is the dot pitch of the monitor, which is totally independent from the input image resolution but is instead defined by the monitors shadow mask.

An ideal shader would first apply a scanline effect to the original image resolution, then upscale the image to a resolution that resembles the monitors dot pitch and after that apply a second part of the shader, simulating the monitors shadow mask itself.

From the looks of it, the current shader does instead seem to apply both effects with the input resolution, whith doesn't look completely convincing especially in lower resolutions like 320x200.

Separating both effects would most likely lead to a very different shader, but there might be a much simpler way, that, despite not being entirely 'correct', also would lead to more convincing results for lower resolutions: upscaling smaller input images to, lets say 640x480, 800x600 or something like that and applying the current shader to this upscaled image most likely will improve the overall impression for lower resolutions alot.

I would love to try this myself, but someone with shader programming experience (which I unfortunately do not have) would surely be much faster.

BTW1.: the scanline effect looks a bit too strong with this shader for my taste. At least I can't remember any real sreen that showed completely black space between scanlines. If visible at all, this should be a more subtle effect. But that will most likely strongly depend on the age and/or type of the simulated monitor.

BTW2.: To get physically correct scanlines one would have to do something entirely different and more complicated than darkening every other line of the image, since the width of the scanline gap varies, depending on the luminosity of the current pixel (respectively the current intensity of the cathode rays), which can be observed in the attached secreenshot quite nicely. Brighter pixels 'bleed' more heavily into neighboring ones than darker pixels. EDIT: The shader already does take that into account

BTW3.: A 'realistic' dot pitch resolution might be anything in the range of ~640x480 to ~1600x1200, again depending on the age of the simulated monitor.

Attached is an image that quite nicely shows that on real CRTs the effects caused by scanlines and the monitors shadows mask are independent form each other.

Attachments

Reply 17 of 39, by leileilol

User metadata
Rank l33t++
Rank
l33t++
snakesqzns wrote:

Note that the artifacting I described above only shows up on the right and bottom when using this shader.[/img]

Happens in BSNES for me as well

hey, i'd kill to get this effect in my own quake engine! 😀

apsosig.png
long live PCem

Reply 19 of 39, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

There's one for D3D, but it does not work properly since dosbox stopped rendering every frame. It actually seems to be very easy, but dosbox would need a switch to render full 60fps (or whatever the current emulated refresh is).

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