Patch for OpenGL fullscreen bug

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Patch for OpenGL fullscreen bug

Postby hakonrk » 2011-2-18 @ 09:05

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:
Code: Select all
--- 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);
User avatar
hakonrk
Newbie
 
Posts: 30
Joined: 2004-2-13 @ 09:40

Re: Patch for OpenGL fullscreen bug

Postby cfoesch » 2011-2-18 @ 14:43

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...
User avatar
cfoesch
Newbie
 
Posts: 23
Joined: 2011-2-14 @ 16:00
Location: Albuquerque

Re: Patch for OpenGL fullscreen bug

Postby hakonrk » 2011-2-18 @ 14:50

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.
User avatar
hakonrk
Newbie
 
Posts: 30
Joined: 2004-2-13 @ 09:40

Re: Patch for OpenGL fullscreen bug

Postby cfoesch » 2011-2-18 @ 14:51

Ah yes, now it makes sense! :)
User avatar
cfoesch
Newbie
 
Posts: 23
Joined: 2011-2-14 @ 16:00
Location: Albuquerque

Re: Patch for OpenGL fullscreen bug

Postby Dominus » 2011-2-18 @ 15:45

Need to check how it looks on os x, never noticed the white line but I seldom run dosbox fullscreen
User avatar
Dominus
DOSBox Moderator
 
Posts: 7539
Joined: 2002-10-03 @ 09:54
Location: Vienna or Ludwigsburg

Re: Patch for OpenGL fullscreen bug

Postby h-a-l-9000 » 2011-2-18 @ 16:00

Wonder how to fix this :D

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
output_opengl.png (70.96 KiB) Viewed 14095 times
1+1=10
h-a-l-9000
DOSBox Author
 
Posts: 4512
Joined: 2005-2-23 @ 00:14

Re: Patch for OpenGL fullscreen bug

Postby Dominus » 2011-2-18 @ 16:10

Hey man, nice shot;)
User avatar
Dominus
DOSBox Moderator
 
Posts: 7539
Joined: 2002-10-03 @ 09:54
Location: Vienna or Ludwigsburg

Re: Patch for OpenGL fullscreen bug

Postby wd » 2011-3-04 @ 16:10

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.
wd
DOSBox Author
 
Posts: 10818
Joined: 2003-12-03 @ 21:23

Re: Patch for OpenGL fullscreen bug

Postby FrodeSFS » 2011-5-09 @ 22:29

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).
FrodeSFS
Newbie
 
Posts: 1
Joined: 2011-5-09 @ 22:20

Re: Patch for OpenGL fullscreen bug

Postby VileRancour » 2011-5-13 @ 13:25

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)
User avatar
VileRancour
Oldbie
 
Posts: 1585
Joined: 2003-5-14 @ 22:11
Location: 1-01-80 0:00a

Re: Patch for OpenGL fullscreen bug

Postby snakesqzns » 2011-8-30 @ 03:10

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: Image

Note that the artifacting I described above only shows up on the right and bottom when using this shader.[/img]
snakesqzns
Newbie
 
Posts: 4
Joined: 2011-8-30 @ 02:58

Re: Patch for OpenGL fullscreen bug

Postby VileRancour » 2011-8-30 @ 03:42

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!
User avatar
VileRancour
Oldbie
 
Posts: 1585
Joined: 2003-5-14 @ 22:11
Location: 1-01-80 0:00a

Re: Patch for OpenGL fullscreen bug

Postby gulikoza » 2011-8-30 @ 19:55

See here if you know any HLSL :happyhappy:
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: Patch for OpenGL fullscreen bug

Postby snakesqzns » 2011-8-31 @ 01:35

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 ... nGL.shader

You can try converting it to HLSL and use gulikoza's Dosbox.
snakesqzns
Newbie
 
Posts: 4
Joined: 2011-8-30 @ 02:58

Re: Patch for OpenGL fullscreen bug

Postby gulikoza » 2011-8-31 @ 05:41

You've said OpenGL.CRT shader :confused:. caligari's scanlines does not seem to have barrel distortion.
In any case, you did not open the linked thread, yes? :happyhappy:
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: Patch for OpenGL fullscreen bug

Postby snakesqzns » 2011-9-01 @ 01:51

Guess I had a seizure or something.

The shader in the screenshot is indeed OpengGL.CRT (https://gitorious.org/bsnes/bsnes/blobs ... nGL.shader).

I did see your linked thread btw.
snakesqzns
Newbie
 
Posts: 4
Joined: 2011-8-30 @ 02:58

Re: Patch for OpenGL fullscreen bug

Postby dosmax » 2011-9-03 @ 02:30

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
Castlevania-scanlines.jpg
Castlevania-scanlines.jpg (120.02 KiB) Viewed 12335 times
dosmax
Newbie
 
Posts: 66
Joined: 2010-9-05 @ 08:10

Re: Patch for OpenGL fullscreen bug

Postby leileilol » 2011-9-04 @ 02:35

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! :)
Voodoo2s aren't 100mhz stock
Geforce256 isn't released as a beta on New Years '99 under the Quadro brand
386DX vs SX isn't about a missing FPU
DOS gaming isn't a bilinear 320x200 16:10
DOS PCs aren't better than the Macintosh
Old PCs aren't 'aesthetic'
User avatar
leileilol
l33t++
 
Posts: 9050
Joined: 2006-12-16 @ 18:03

Re: Patch for OpenGL fullscreen bug

Postby RoyBatty » 2011-9-04 @ 20:00

Does it emulate phosphor persistence also? So far I haven't seen one that does, and that would be a really great thing to see.
User avatar
RoyBatty
Member
 
Posts: 427
Joined: 2009-8-22 @ 11:37

Re: Patch for OpenGL fullscreen bug

Postby gulikoza » 2011-9-04 @ 20:43

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).
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Next

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 0 guests