* Split the topic into DOSBox and SDL version threads *

Original DOSBox version thread is here: [DOSBox-only version] Hq2x / Hardware OpenGL-HQ scaling

Hope you don't mind, Moe - I thought it would make things easier to separate things a bit.

I got it to work, but I now have an annoying flicher in the bottom right corner of the window.

Moe,

Finally tried your OpenGL-HQ SDL.dll with the latest DOSBox CVS. I commented out the hwscale and scaler lines in my dosbox.conf and set output=surface.

I added SDL_OPENGLHQ_WINRES=1280x960 and SDL_VIDEODRIVER=openglhq environment variables to System Properties->Advanced->Environment Variables->User variables in WinXP.

The result is that the text at the DOSBox prompt looks OpenGL-HQ style, but when I try to run a game (Dark Forces in this case) it no longer looks like it's being processed by OpenGL-HQ. Also, I'm almost positive that it's not using hardware-accelerated OpenGL because turning on a shader in my video card's driver control panel doesn't have any effect on DOSBox's output (even if I quit and restart).

I've got an ATI Radeon 9800 Pro 256MB OEM AGP running the latest stock Catalysts (5.6) on WinXP Pro SP2 on an Athlon XP 3200+ with 1GB of RAM.

Is it possible that SDL is somehow crippled to default to software OpenGL rendering, or is there something I'm doing wrong? The former wouldn't surprise me, as it seems to behave that way for DirectDraw and Overlay surfaces.

UPDATE: Decided to try full-screen to see what would happen. Set fullscreen=true in dosbox.conf, fullresolution=1280x960. When I ran it, it went fullscreen and seemed to freeze before drawing anything. I tried changing fulldouble to false and that fixed it (note that I already have triple buffering disabled in the drivers, just to be safe, so that can't be related).

I noticed that there seems to be a lot of lag when running full-screen. It's noticable when typing at the DOS prompt or when moving a mouse cursor around.

I have a funny problem, the mouse won't move normally, it seems that it can't move through the entire window, as if there is some invisible barrier.

WilliamC: Does the invisible border change position/size if you use different resolutions?

@HunterZ: I just tested dosbox with smart shaders enabled and it works for me (cat 5.6). So I have no idea why it would use software only opengl on your system (besides AFAIK ARB_fragment_program cannot run in software mode, so OHQ wouldn't even run in that case).

It seems to change if I move my mouse really fast. It doesn't make much sense.

You're right. I was using ATI Tray Tools to pick the shader, and it wasn't an OpenGL shader that I had selected. I was able to get it to visibly show that it was using a shader, but now it isn't setting the specified window size - weird.

EDIT: I'm an idiot. I forgot that I needed to use output=surface and not output=opengl. Interestingly, output=overlay works too (told you it was using software surfaces!)

EDIT 2: Also wanted to mention that aspect ratio correction in DOSBox should be turned off to avoid ugly artifacts. I think you can just set an appropriate window size to have SDL do the aspect ratio correction.

EDIT 3: It seems that the sound in DOSBox is rather choppy when running in SDL OpenGL-HQ mode, even when I lower the cycles to where DOSBox is only using around 25% CPU.

Odd, the problem is only when playing Laser Squad.

If your 320x200 modes are not openglhqified, you probably have "scaler=normal2x" (the default value). Set it to "none", because otherwise, OpenGL-HQ sees 4 pixels where one should be, and decides to keep the blockiness 😉

OpenGL-HQ asks your video driver if it runs the pixel shaders in hardware and refuses to run if it doesn't - there is no way of having it fall back to software or something.

If display seems sluggish in fullscreen, remember that higher resolutions are slower - even though most is done in hardware, output size still matters, and your video driver does a few calculations on the CPU, so your CPU speed also matters. Raising frameskip by 1 should help. But nevertheless, it's a little bit funny... Check that you don't force vsync-wait for all apps in the catalyst control center, that made dosbox a lot slower for me.

I have found out that fulldouble is generally problematic: don't use it with openglhq. There is a workaround if you really want it, read about SDL_OPENGLHQ_DOUBLEBUF in the README.

Now about your problems, WilliamC: If you've downloaded a new SDL.DLL and set SDL_VIDEODRIVER, you're using the correct release. If you set "ouptut=openglhq" in dosbox.conf, you're using the old release. Don't do that. Go to the download directory and fetch the newest SDL-1.3-<something>.zip, read the README, and replace the SDL.DLL of dosbox with the one from the zipfile. Get back to us if you need more help. Oh, and if you have any problems, first check a plain 0.63 release of dosbox: I found out that one of my own mouse patches doesn't work that well with SDL-openglhq.

Yeah, I thought about vsync afterwards and disabled it, although I haven't tested fullscreen since (I prefer not to run in fullscreen)

EDIT: Also, any ideas on the sound issues, Moe?

Right now, no. I'd love to get my hands on some of your boxes, just to find out what's wrong. Anyone near enough or adveturous enough is invited for a nice weekend 😉

Try some combination of settings. If you find out about some really bad combos, tell us. I guess that some settings can ruin your day. Still, with me, overall performance is a lot better than with you, it seems. I really assume you have latest video drivers installed. Any details that you'd share?

I have the latest everything installed (it's a bit of an obsession).

I noticed that the sound is fine for around 20 seconds and then choppy for around 5. It seems to happen no matter how low I set the cycles (of course it gets worse if I set them too high). It also doesn't seem to be related to DOSBox CPU usage (did I already mention that?)

Increasing DOSBox sound buffer sizes helps a bit, but of course it quickly introduces huge delays.

No, the only thing that could help is frameskip. It seems that rendering a frame takes too long - by the time the next frame arrives, the old one isn't done yet. With our hardware, vsync-waiting is bad, a radeon 96/97/9800 class chip is simply not fast enough for frameskip 0 plus doublebuf plus vsync-wait.
It might be if you tune the refresh rate carefully (see that other thread about Hz values).

That's hard to believe, unless the OpenGL-HQ calculations are extremely GPU-intensive, but I guess there's not really any other explanation. Isn't is possible though to run the video rendering and sound emulation in different OS-level threads so that they don't block each other? Or is that not what's happening?

Yes, you got it right: OpenGL-HQ is extremely GPU intensive. It's three-pass rendering with fragment programs that hit the size limit of fragment programs on 9[678]00 class chips. (If they didn't, I wouldn't have used three passes...) There's a whole lot of difference between some fixed, integral scaling factor like in hq2x and arbitrary, non-integral ones. You do the math: 23 instructions that mostly run at one instruction per clock, twice run at the input resolution (say, 320x200 pixels), once run at the output resolution (say, x4 = 1280x800). That makes about 26 million clock cycles. Add some slack because of memory bandwith (texture memory) and instructions that need more than one cycle, let's say 30M cycles. With a 300MHz GPU, that makes 10fps. You've got 8 fragment shading units? Cool, makes 80fps. Then there is texture pixel transfer, color space conversion/packing/unpacking of pixel data, ATI's inexplainable desire to use floating point textures (16 bit per red, green and blue = double memory bandwidth), opengl setup, thread synchronization which all use valuable time. So even if your GPU runs faster, you can see that a 9800 class chip is at it's limits if you expect 70 fps. If you enable double buffering with vsync-wait, you can roughly halve the reachable fps because of mismatching frame rates.

Rendering already runs in a separate thread, and everything is done as asynchronously as possible - but in contrast to the dosbox patch, no frame is ever skipped automatically.

New release is out: no big changes, just a little cleanup and everything. As a special goodie for gulikoza, I've included a small patch for dosbox so that "output=openglhq" still works 😉
Oh, and it has a proper webpage now: http://garni.ch/dosbox/

Thanks, moe.
But you forgot to add SDL_openglhq_pass1.h ~ SDL_openglhq_pass3.h and SDL_openglhq_table.h in your achieve (SDL-1.3-openglhq-2005-06-29.zip)

No, I didn't. It's now generated on-the-fly, just as it has been in the dosbox variant of the patch. It all works automatically through the Makefile. For M$-support, you might take a look at the VS files in the dosbox variant, someone did a great job adding this on-the-fly mechanism for VS.

It doesn't create automatically those .h files for me. (I'm using MinGW/MSYS, not VisualC)

I found this page, but I couldn't find how to add on-the-fly mechanism in it.
http://msdn.microsoft.com/library/en-us/cpgui … egeneration.asp