IIRC, switching SDL to use WINDIB will fix it or upgrade to Windows 8.

DOSBox & Aero (Transparency disabled on Full/Windows mode switch)

That thread is 5 years old, isn't there a better fix for this yet? The fix listed there (the diff patch file at least,) doesn't seem to apply any more. It won't apply automatically because the locations have changed, and when I find the locations manually, I find that the text has been changed too. Not sure I want to risk making changes blind, when I don't understand the underlying problem in the first place. What exactly is causing the issue? Scanning the linked web site, it sound like it's caused by trying to change the entire palette. Reading the thread it sounds like its caused by DOSBox changing the intro screen to red when switching to full screen.

I tried setting an environment variable SDL_VIDEODRIVER=windib and that appeared to fix the problem, till I discovered that it killed scaling 🙁 For some reason, scaling only works with ddraw for me, and with windib ddraw always "fails to create" the surface and switches to normal mode.

And, no, I just spent $200 upgrading to Windows 7 because I had to, I'm not spending another $200 to upgrade to an even worse OS for at least a year. Windows 7 sucks.... Windows 8 is 10 times worse 🙁

You may submit your own patch if you don't like the other one.

There's a SDL2 port of DOSBox on the forum somewhere. Issue might be fixed there.

truth5678 wrote:

You may submit your own patch if you don't like the other one.

It's not that I don't like the patch, it just that with it's age it no longer directly applies, and I don't understand the patch 🙁 Maybe it's my meds or lack of sleep, but I can't seem to get a clear picture of what the problem is in the first place. I'm not much of a programmer, just enough to alter code that already exists, and then only if it's not too complicated. Most of what I do is cut and paste code from other places. With maybe a tweak here and there. If I had a better grasp on what was causing the problem, maybe I could do something to fix it. But first, from what I'm reading, the problem isn't with DOSBox but with SDL. So, the fix would need to be in that. Not that big a deal, since DOSBox needs a special compile of SDL in the first place, just put that fix in as well. But, that brings me back to what's causing the issue.... I just don't know, it seems it might have something to do with a palette change, but how/why does that cause it?

It would be best if the problem is specific which can be established by testing. It appears unknown which conditions work in dosbox under W7, such as whether an active windib driver shows the same result under different output modes and W7 enhancements (aero glass).

Also, the age of the thread does not necessarily make it irrelevant. After all, it did provide a working solution. The ddraw output mode uses directx which that same thread warned about using.

truth5678 wrote:

It would be best if the problem is specific which can be established by testing. It appears unknown which conditions work in dosbox under W7, such as whether an active windib driver shows the same result under different output modes and W7 enhancements (aero glass).

Also, the age of the thread does not necessarily make it irrelevant. After all, it did provide a working solution. The ddraw output mode uses directx which that same thread warned about using.

I didn't mean to say it was irrelevant. I'm saying I can't figure out how to use it safely. The differential file no longer matches up. Without understanding the underlying theory behind the patch, I cannot even guess at how safe it would be to make the changes blindly. As an example, one of the patch locations in the diff file is at line number 995. Yet, the only lines that match what is to be removed, are at line number 250. Also, the bracketing lines are now non-existent. So, what happens if I remove those line and put in the new ones??

That is the main issue. What is the actual problem? It seems to only occur with DirectX (thus setting it to use windib fixes it.) This is probably why setting output to opengl doesn't cause the problem as well. Only, my monitor is a fixed resolution, and ddraw (which absolutely requires DirectX - and won't work at all with windib,) is the only output that will scale on my system for some reason. So, with windib enabled, or opengl selected as output (either will fix the problem,) most of my games will play in a little box in the middle of the screen. Try reading text in a 320x200 box on a small 1366x768 monitor. It is a little difficult.

On the other hand, disabling Aero causes other problems. Mainly graphics anomalies. Nothing catastrophic, mind you, just distracting. I wish I could take screen shots of it, but they just turn out normal (without the anomalies.) Basically, it looks like random digital (blocky,) lightning bolts. Bright white jagged lines randomly appearing around letters, surrounding motion objects, and such. Nothing crashes, or anything like that, it's just highly distracting, and sometimes makes text impossible to read.

FeedingDragon wrote:

The differential file no longer matches up.

Attached are the patches updated for latest SVN; however, I didn't test them yet so they may require testing and modification. I don't use W7 either. 😀

FeedingDragon wrote:

This is probably why setting output to opengl doesn't cause the problem as well.

Is there a disadvantage to using opengl output mode?

Additional information on ddraw mode under W7: Resizing DOSBox windowed in Windows 7.

truth5678 wrote:

Attached are the patches updated for latest SVN; however, I didn't test them yet so they may require testing and modification. […]
Show full quote

FeedingDragon wrote:

The differential file no longer matches up.

Attached are the patches updated for latest SVN; however, I didn't test them yet so they may require testing and modification. I don't use W7 either. 😀

FeedingDragon wrote:

This is probably why setting output to opengl doesn't cause the problem as well.

Is there a disadvantage to using opengl output mode?

Additional information on ddraw mode under W7: Resizing DOSBox windowed in Windows 7.

Thanks, that fixes the problem. The constant opening and closing window every time there's a resolution change is a bit distracting, but it's better than the garbage when Aero is off.

As for opengl, (as well openglnb, surface, & overlay,) they won't scale the image. Well, they won't scale graphics mode screens. DOS stretches out just fine, but as soon as a graphic mode lodes, poof, I get a tiny box in the middle of my screen 🙁 It's the exact opposite of the link you pointed me too. It probably has to do with I have an ATI (well AMD now,) card and they had Nvidia cards. Ddraw work great other than killing aero when full screen, (and from what I've been reading that's really a problem with SDL.) They had the exact opposite. Opengl scaled things just fine, it was ddraw that wouldn't scale things for them.

My Windows XP install was a little more compatible for some reason. That one would scale with either opengl or ddraw. At that time I used opengl because it seemed to run smoother. When MS forced me to upgrade to Win7, it took me a bit of time to realize that the upgrade also cost me the ability to scale in DOSBox. It was at this time that I learned I had broken ddraw with my build of DOSBox. Got that fixed, then had a really fun time changing opengl to ddraw in 173 conf files 🙁 Yes, I have a separate conf file for every game I install in DOSBox, and a couple of general purpose ones for testing (well one for each screen mode: CGA, VGA, SVGA, Tandy, etc...)

*edit* Forgot to mention *edit*
When I can back off of my meds again and get more sleep, I'll try to look at the code and see if I can do anything to smooth that out a bit.

I posted a patch here for opengl mode: VIDEO - OpenGL Fullscreen/Desktop Fix (SDL1). I don't know whether it would help in this situation, but it may be worth testing.

Also, it is possible to replace the text for multiple files. One way is a bash shell via cygwin, mingw, or similar unix-like software. A one line script would look something like this (this is untested):
for i in *.conf; do cat $i | sed 's/ddraw/opengl/' > $i.new; done

There must be Windows GUI software that does the same, but via menu options. 😀

truth5678 wrote:

I posted a patch here for opengl mode: VIDEO - OpenGL Fullscreen/Desktop Fix (SDL1). I don't know whether it would help in this […]
Show full quote

I posted a patch here for opengl mode: VIDEO - OpenGL Fullscreen/Desktop Fix (SDL1). I don't know whether it would help in this situation, but it may be worth testing.

Also, it is possible to replace the text for multiple files. One way is a bash shell via cygwin, mingw, or similar unix-like software. A one line script would look something like this (this is untested):
for i in *.conf; do cat $i | sed 's/ddraw/opengl/' > $i.new; done

There must be Windows GUI software that does the same, but via menu options. 😀

I'll try that patch out 😀 Tomorrow maybe, finally starting to get tired enough that I might actually get some sleep. As for multi file find/replace, there is one HERE, and I have it "now." I didn't have it then... Changing them in the future will be easy, it was a pain in the butt at the time though 🙁

Are there any good tutorials on how to import diff files into the local repository/source code base?
Thanks
Jack

You use the patch utility 😉
If you know how to google you can find several guides (hint - search for: how diff apply patch)

Thanks Dominus.....

Ok, tried the OpenGL patch... Didn't help 🙁 Actually made things worse. Went from no scaling to Vertical only scaling (which looks weird, let me tell you.) So, a 640x400 screen became a 640 x768 screen.

I still wish I could find out exactly why Aero gets turned off. It only happens when using DirectX, SDL, and Fullscreen. But it always happens in those conditions. It doesn't matter if you switch to full screen or start in full screen. If you are using SDL with DirectX, Aero gets turned off. I can only assume it has something to do with how SDL uses DirectX in full screen mode. If I knew why it happens, I "might" be able to tweak it to not do it any more.

That's a good result! I didn't expect the patch to allow scaling where before it did not (the proper test is to check whether it reverted to surface mode).

truth5678 wrote:

That's a good result! I didn't expect the patch to allow scaling where before it did not (the proper test is to check whether it reverted to surface mode).

Ooops, sorry. Yes, it stopped opengl from turning off Aero. What exactly does it do? It looks like it forces it to a single display list and turns off switching to "surface" mode. Don't know enough about either one of those to know what that actually means. I see a marathon of web searching coming up in my future.

One web site suggested that the Aero getting turned off was because SDL was insisting on taking control of the entire palette, while Aero has certain palette entries locked. The problem is that I don't know enough of how DirectX or graphics work. I found where SDL claims the entire palette when in full screen mode, but reserves the first 10 entries in windowed mode, and I "could" just get rid of the if/else and lock it into always reserving the first 10 entries for windows. But I have no idea what sort of effect this would have. Another option (as this seems to limit the palette to 256 colors - while almost all modern computers are capable of 16M colors,) is to convert it so that it always builds a totally different palette. But I have no idea how to go about stretching the palette to do that. *EDIT* Correction, it reserves the first and LAST 10 entries in the 256 color palette.

Additional information: From what I've been reading, Windows Vista and beyond no longer allow processes to open up a "separate" screen. Full screen processes instead are just windows with no border, set to "always on top", no title bar, no menu bar, no status bar, and locked to change the desktop to match the resolution it is using. (which always messes up my open folders and apps when it doesn't use my current desktop settings.)

I think I'll try the first route first. That is, having it always reserve the first 10 entries. Also going to look at how it handles the palette in WINDIB mode, as that has no effect on Aero either.

It seems like palette or resolution is a likely cause of the problem, but not likely caused by dosbox itself. Included is an additional patch to test alongside the opengl patch referenced above. It will force the resolution and window modes for testing. The goal is to obtain a 1024x768 (opengl) stretch without the problem you reported above (the improper video aspect ratio). The resolution and mode can be customized in the patch (for testing only).

truth5678 wrote:

It seems like palette or resolution is a likely cause of the problem, but not likely caused by dosbox itself. Included is an additional patch to test alongside the opengl patch referenced above. It will force the resolution and window modes for testing. The goal is to obtain a 1024x768 (opengl) stretch without the problem you reported above (the improper video aspect ratio). The resolution and mode can be customized in the patch (for testing only).

Well, it's stretching correctly now. Aero is being disabled again though. So this fix cancels out the last fix 😒 As a note, I tried changing everything in SDL so that (other than actual screen creation,) it treated everything full screen the same as windowed. No good, still (even with a limited palette,) it Disables Aero in full screen mode.

On the same note, was playing a game for more than a few seconds testing earlier, the Aero fix "aero_fix_ver4.diff" posted by truth5678 doesn't actually fix it after all. Aero is still disabled in full screen mode, it just re-enables it if you switch back to windowed mode. I played one of my games for a while earlier, and the glitchy graphics showed up 🙁

I'm wondering if windib mixed with the stretchable opengl would work for me. Though, I'd sort of like to incorporate the fix without locking it to full screen with a pre-fixed resolution if I could. The other option is to set full screen mode to original and let my monitor do the re-size. Don't like that because it doesn't handle it very well for some modes.

**EDIT**
Forgot to note, the "gl_stretch_test.diff" had one small error. The routine chanted at 407 & 445 is supposed to return a value. I just copied the "return sdl.surface;" command from the commented out section to the end of the additions.