VOGONS


First post, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

I'm trying to compile the latest 1.2 and 1.3 SDL.dll's, and I can't get one that doesn't cause DOSBox to report a failure to create a hardware ddraw surface in output=ddraw mode. I know about the hack in src/video/windx5/SDL_dx5video.c but it no longer seems sufficient. Has anyone else noticed this?

Reply 1 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Can anyone confirm this one way or the other?

Reply 2 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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 🙁

Reply 3 of 17, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Reply 4 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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

Reply 5 of 17, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Reply 6 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 7 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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

Reply 8 of 17, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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)

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 9 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 10 of 17, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Reply 11 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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

Reply 12 of 17, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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

Reply 13 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 15 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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

Reply 16 of 17, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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)

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

Reply 17 of 17, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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?