Can anyone confirm this one way or the other?

I don't know if it's related, but I noticed that in the latest DOSBox CVS and latest SDL 1.2 CVS, running with output=opengl results in 100% CPU usage even at 3000 cycles. When I try to type anything in DOSBox, it responds very slowly.

Edit: I think this may have been because of some driver options I had set - possibly forcing triple buffering in OpenGL.

Also, I get the ddraw hardware surface error even if I try to run in fullscreen, and I get it again every time I switch between full and windowed (or vice versa).

And since overlay is a joke in SDL (actually uses surface if you pick overlay), I'm basically stuck with surface as my only choice for output in DOSBox 🙁

Seems the new sdl's default to windib, which screws any hardware surface support

Thanks. Any idea how I can override it back to ddraw?

in sdl_video.c change the order of the bootstraps so directx comes before windib. Might just force dosbox to first use ddraw in windows so it can always fall back to windib if shit goes wrong. Although sdl people said that this order might be reversed again later on

Wow, thanks for the instant reply! (note to self: post at 4am Pacific time when asking questions for Harekiet 😉) I'll give that a shot and post a follow-up. I did get things working quite well for now with Moe's OpenGLHQ SDL.dll.

OMGOMGOMG it worked! Fade to Black now runs FULLY PLAYABLE AT 640x400 at 140000 cycles!

is this with the first mentioned hack? I knew about that hack but forgot all about it, so could anyone refresh my memory (especially since that sdl compile I did back then has disappeared from my computer)

The old hack was (I think) to allow hardware surfaces in windowed mode. To do that, open SDL_dx5video.c, search for #if 0 and change it to #if 1. I'm not sure whether it's still needed but it probably is.

It turns out that they've also now changed it so that windib always takes precedence over ddraw (in fullscreen and windowed alike), so as Harekiet mentioned you also have to open sdl_video.c and swap the section on windib with the section on ENABLE_WINDIB with the section on ENABLE_DIRECTX so that the directx part comes first.

One thing I've never been able to do is get hardware overlay support. It seems to just fake it with normal surfaces. ddraw is probably just as fast though.

for hardware overlay's you'll have have to edit dx5_yuv.c and reenable some #define at the top of the file.

Yeah there's a line "#define USE_DIRECTX_OVERLAY" that's commented out, but when I uncommented it I could see that it was still faking it.

How I can tell if an app is using overlay:
- when I span an overlay across my two monitors, it will only display the half that is on one monitor or the other (and not both halves at the same time)
- overlay output tends to be blurred

thanks Hunter for taking your time to explain it to me.

...compiling...compiling...compiling...
Damn it takes some time to compile that 😀

Edit #2: And what did I learn? SDL CVS is not stable 😀
(with last CVS I get errors when compiling Dosbox)
Now lets go back to 1.2.9

I don't have problems, although I'm using the 1.2 CVS and not the 1.3 CVS (which I think is now out of date).

Back to overlays: I did some experimentation and discovered that if, after the overlay is created in sdlmain.cpp around line 487, I log the value of sdl.overlay->hw_overlay it is always zero. I've tried tweaking different things but I just don't know enough about what I'm doing to have any idea why SDL refuses to create a hardware YUV overlay. My guess is that it's more likely SDL's fault, as I remember their overlay test app wasn't using a hardware overlay either.

That's weird...cause hw_overlay is always set to 1 in SDL_dx5yuv.c.

Yeah, and I was able to put a printf in the function that sets that and saw that it was being executed.

What if you set SDL_VIDEO_YUV_DIRECT=1 env variable? This fixed some problems for me...it seems that if SDL_DOUBLEBUF is passed to SetVideoMode, I will get a sw overlay unless YUV_DIRECT is set.

(btw...1.3 branch had some updates recently. I think it is now incompatible with Moe's openglhq unless rendertarget patch is applied. See sdl mailing list)

Unfortunately that seems to have no effect. I even tried enabling SDL_VIDEO_YUV_HWACCEL as well.

Edit: Has anyone else been able to get it working? Is it something about my computer or is overlay just not useful/important when ddraw is available as an alternative?