I really doubt it's a problem with Dosbox but with SDL.
@feeding: remember to do the windib thing when testing the opengl fixes.
Also try getting an official SDL.dll, as I wrote in the old thread, with this dll you probably don't need to set Windib yourself.

I hadn't posted yet, but I did try the stretch fix with windib enabled. Aero stayed working, but it stopped stretching.

The problem with the official SDL.dll build is that direct draw is broken. You can "force" it to work, but the results are... well smudged is the only way I can describe it. Everything gets blurry and smudged looking (like a piece of paper that's been soaked.) And even then, on my system ddraw is the only mode that will scale.

As far as I know (it's been a while since I tested this) Aero is switched off because SDL creates a DirectDraw surface (don't remember all the details why). This also happened with output=direct3d and my patch so I added a special code path to my SDL build that only creates a window without the DD surface (basically the same as OpenGL but without the OpenGL context, which is a whole lot of another problems by itself) - which is incidentally also what WINDIB driver does, but this allows you to keep DINPUT for input management...

Thanks for the insight. Seems that W7 users (and possibly related versions) should leave Aero off where full screen (given use of the SDL 1.2 branch). Especially since prior discussions confirm that directx is preferred over windib, some points including performance and the point you made about input management.

Also, opengl mode (with typical sdl/directx driver) seemed to require the hardware surface. I only tested by removing that flag which led to no video output, although the game audio could be heard.

I never used Aero, but another post suggested that it has balloons. Is this a necessary feature for running dosbox?

If by balloons you mean the thumbnails from the taskbar on hover, yes it will display a thumbnailed image of DOSBox with its contents. Required? No, especially when full screen when you cannot even see the taskbar, anyway. The only time that I can see it being an issue is when Alt+Tabbing out of DOSBox for referring to the manual for copy protection, etc. or some other document, such as a walkthrough. Or perhaps someone who has a dual monitor setup and does not like the theme change. It does not matter about any of the Aero interface enhancements since it will always be the primary monitor that DOSBox will use in full screen and the taskbar is not visible.

Besides, Aero is restored when DOSBox is closed. Seems a bit like a-lot-to-do-about-nothing.

Did you miss the part where I explained that I get graphics anomalies when Aero is turned off? Also, when that particular problem is reported to Microsoft, their response is, "Windows 7 is designed with Aero, we do not support turning it off. So turn it back on and contact us again if the problem continues." Yeah, very helpful. This is why I'm trying to get scaled full screen with Aero still on. Since I compile and run my own version of DOSBox, just downloading the SDL 2 converted exe is not really an option (which is why I haven't tried that yet.) If the official SVN ever starts supporting SDL 2, I'll download the source and give it a try, but until then, I'm trying to find a way to get it working with SDL 1.2.15 (Which, I believe is the last of the 1.2 series.)

Since my attempts to fix the SDL library have failed miserably, I've started working on trying to get opengl or openglnb to start scaling properly in windib mode. I always thought DOSBox had it's own internal scaling protocol (thus the iclusion of the scaler= and aspect= lines,) but I can't seem to get that working. DDraw, I believe does it in hardware, but I'm not completely sure about that. There is a hack/fix earlier in this thread that gets opengl mode to start scaling for me again, but switching to windib stops it from doing so.

Using a full screen ddraw surface will turn Aero off. That is by design AFAIK. Since both ddraw (HW surface) and surface (SW ddraw surface with dx driver) use ddraw the problem can't be solved there. OpenGL opens a normal window without the ddraw surface attached to it so it does not have this problem. That is one solution, but I found OGL not performing as well as other outputs. That's why I started with D3D. With a patched SDL, output=direct3d shouldn't turn off Aero (it doesn't on my machine) but it needs a plain GDI window without the ddraw surface which vanilla SDL_SetVideoMode does not produce. Attached is my patch and if you pass 0x40 to SDL_SetVideoMode() you will get a plain (obviously non-working with dx driver) SDL window to which direct3d can then attach itself.

gulikoza wrote:

Using a full screen ddraw surface will turn Aero off. That is by design AFAIK. Since both ddraw (HW surface) and surface (SW ddraw surface with dx driver) use ddraw the problem can't be solved there. OpenGL opens a normal window without the ddraw surface attached to it so it does not have this problem. That is one solution, but I found OGL not performing as well as other outputs. That's why I started with D3D. With a patched SDL, output=direct3d shouldn't turn off Aero (it doesn't on my machine) but it needs a plain GDI window without the ddraw surface which vanilla SDL_SetVideoMode does not produce. Attached is my patch and if you pass 0x40 to SDL_SetVideoMode() you will get a plain (obviously non-working with dx driver) SDL window to which direct3d can then attach itself.

Sorry it took so long, been dealing with a lot of other things as well. DOSBox won't allow me to set output=direct3d. I tried to program it into DOSBox, but I'm afraid the code got a little too complicated for me 🙁

You need to use Gulilozas code for adding direct3d or did you not read that part when he wrote he added it 😉

Hoping I haven't missed this anywhere, what happens with vanilla DOSBox (from SVN) and these settings:
- fullresolution=desktop
- scaler=none (or any of the "normal" scalers)

Dominus wrote:

You need to use Gulilozas code for adding direct3d or did you not read that part when he wrote he added it 😉

Ack, I did miss that, sorry. Trying to apply that patch now.... Well, my patch list is growing exponentially 🙁

Ah... Sweet success at last 😀 Added in the Direct3D patch (with a newly patched SDL) and now it works great. A little bit of trouble adding in the pixel shaders with multi-file find & replace. A bit of trial and error to get the coding right, it didn't want to put in the CR/LF at first. But got that straightened out. Direct3D with hq2x.fx pixel shader and normal2x scaler looks just awesome 😀 Aero stays working with output set to direct3d, so I'm not getting the graphics anomalies (so far.) If they come back, MS "claims" they will support it this time since Aero is enabled.

Thanks for the help all 😀

What troubles with pixel shaders? 😀

Silly, my own fault, need to learn to read troubles for the most part.

2 hours before I figured out they wouldn't work at all unless they were under the [SDL] heading. Was adding them to a default DOSBox config file, placing them at the top for some stupid reason I still can't figure out. Eventually downloaded and looked at someone else's direct3d build to find that out. Another half hour before I figured out that you had to add the .fx extension to the name in the config file. The last little bit thinking they were all the same before I changed my scaler to normal2x and they actually started making a difference.