Remove DirectDraw output

[vandenk]

Hello,

With DOSBox-X I can not activate the output ddraw (it works with the official version) even if I put the line "output = ddraw" in dosbox.conf!
DOSBox-X puts the output in "surface"

Why ?

[joncampbell123]

Which binary are you using?

[vandenk]

dosbox-x-windows-201711292213.zip
same result on x86 and x64

[joncampbell123]

It may be that in compiling for Windows I forgot to enable DirectX support. A recent patch I accepted makes it conditional, and if selected, uses the DirectX SDK paths.

[vandenk]

This is the last version of DOSBox-X I use (previous post corrected)
Which version would not be impacted by this problem ?

[vandenk]

I have d3dx9_43.dll and d3dx9_43_x64.dll in DOSBox-X directory. Also is possible to check Direct3D box (the box remains checked) but Direct3D is not works (no Direct3D shader).

Tested with windows-20170914-115932 : same result ...

stderr.txt :
LOG: Resetting to DirectX mode
LOG: Failed to create ddraw surface, back to normal surface.
LOG: Failed to create ddraw surface, back to normal surface.
LOG: E_Exit: D3D not supported
E_Exit: D3D not supported

Same with last version (stderr.txt) :
LOG: Resetting to DirectX mode
LOG: Failed to create ddraw surface, back to normal surface.
LOG: Failed to create ddraw surface, back to normal surface.
LOG: Resetting to WINDIB mode

[joncampbell123]

What I mean is that apparently I forgot to compile DirectX support into the DOSBox-X binary itself. I'll see if I can remedy that in the next Windows binary release.

[vandenk]

OK, thanks

[joncampbell123]

I'm seeing DOSBox-X complain that DDRAW output cannot be done because it cannot create ddraw surface.

Debugging shows that it can create a ddraw surface, but it's not a hardware surface, so it considers that a failure. I didn't add that code, so I don't know why anyone would add that.

[joncampbell123]

I deleted my previous comments. It's my fault, not VS2017. The slow keyboard input is caused by DOSBox-X having a low level keyboard hook. I guess Windows isn't smart enough to know that it shouldn't call the hook proc of a program that's being debugged and stopped at a breakpoint, so it makes keyboard input really slow trying and failing to call it.

The strange thing is that the hook proc shouldn't be set unless you capture the mouse in DOSBox-X.

[joncampbell123]

The fault is that it's creating a ddraw surface, but it sees that the surface is not a hardware surface, so it releases it and considers it a failure.

Apparently in Windows 10 DirectDraw programs cannot obtain a hardware surface.

I tried modifying that code to allow use of a software ddraw surface, but then DOSBox-X crashes because the ddraw code expects to poke directly into SDL internal state to obtain the hardware surface. The particular variable is NULL if the surface is not a hardware surface.

[joncampbell123]

Okay, so maybe it's not the low level hook, it only happens if I debug break during the SDL surface setup.

[joncampbell123]

So on my system, I cannot use the ddraw output, but direct3d and opengl seem to work.

The aspect ratio correction menu item appears to be broken, so I'll see if I can fix that.

[vandenk]

I have done tests with several versions of DOSBox (official, ECE, SVN Daum, DOSBox-x), I use Windows 3.11 as guest OS.
With DOSBox-x x64 can not have a mouse that works well ... can not have DirectDraw and OpenGL, no pixel shaders with Direct3D ... with DOSBox-x x86 Win3.11 crash (I have a similar problem with the x64 SVN Daum version)...

Here are the results :

• DOSBox SVN DAUM (r3894) :
  Surface : Mouse OK / No Resize
  Overlay : Mouse OK / No Resize
  DirectDraw : Mouse OK / Resize Nearest-neighbor only
  Direct3D : Mouse KO / Resize Pixel Shader (Alway resize even when original size selected)
  OpenGL : Mouse OK / Resize (by other hradware ? / unchangeable)
  OpenGL_NB : Mouse OK / Resize Nearest-neighbor only
  OpenGL_HQ : exit DOSBox-x instantly

• DOSBox-x 201711292213 x64 :
  Surface : Mouse KO / No Resize
  Overlay : Mouse KO / No Resize
  DirectDraw : switch to surface
  Direct3D : Mouse KO / Resize Nearest-neighbor only
  OpenGL : exit DOSBox-x instantly
  OpenGL_NB : exit DOSBox-x instantly
  OpenGL_HQ : exit DOSBox-x instantly

• DOSBox O.74 Oficial :
  Surface : Mouse OK / No Resize
  Overlay : Mouse OK / Resize Nearest-neighbor in windowresolution / Resize by other hradware ? (unchangeable) in fullresolution
  DirectDraw : Mouse OK / Resize Nearest-neighbor only
  OpenGL : Mouse OK / Resize (by other hradware ? / unchangeable)
  OpenGL_NB : Mouse OK / Resize Nearest-neighbor only

• DOSBox ECE (r4065) :
  Surface : Mouse OK / No Resize
  Surfacepp : Mouse OK / No Resize
  Surfacenp : Mouse KO / Resize (by scaler ? / unchangeable ?)
  Surfacenb : Mouse OK / Resize Nearest-neighbor only
  Overlay : Mouse KO / Resize Nearest-neighbor in windowresolution / Resize by other hradware ? (unchangeable) in fullresolution
  DirectDraw : Mouse OK / Resize Nearest-neighbor only
  OpenGL : Mouse OK / Resize (by other hradware ? / unchangeable)
  OpenGL_NB : Mouse OK / Resize Nearest-neighbor only

Mouse KO = jerks, displacement wrong, lag ...

[joncampbell123]

Is this the latest binary of DOSBox-X? I just fixed the OpenGL crash on startup. SDL corrupts the format pointer when the OpenGL code quits then re-initializes the video subsystem.

[vandenk]

no it's 201711292213, I'll test with the new version.

[joncampbell123]

Sounds about right. I admit the output code is messy and needs work. What I inherited from DOSBox is a good chunk of hacks on hacks including code that pokes a little too deeply into internal SDL state to accomplish the desired goal.

On Linux, a combination of DOSBox-X + SDL bugs results in a window that you can resize, but DOSBox-X stops responding to resize events after the first time.

Last month's "sprint" was basic NEC PC-98 emulation, so perhaps for this month or two I'll cleanup the output code.

Fair warning: My cleanup process may break the scaler functions (such as hq2x) for awhile.

[vandenk]

I confirm that the mouse problems are solved with the latest version (x64 SDL1 20171215-0823).
However, the x86 version still bug with Windows 3.11.

[joncampbell123]

I'll have a new binary up soon.

[joncampbell123]

Binary is up.

[joncampbell123]

So even going back to Windows XP I do not have the means to test and develop DOSBox-X vs DirectDraw because none of the systems I have will allow the DirectDraw support to work. I have no way to maintain the code.

If anyone else here wants to take on maintaining that code and submitting patches, go right ahead. DirectDraw I understand would be ideal for Windows 9x systems where Direct3D is not available.

However if nobody has any interest, I would be more than happy to remove DirectDraw support from DOSBox-X.

[vandenk]

Ok, it is true that on recent operating systems (if opengl and direct3d work properly) ddraw does not have much interest ...

[joncampbell123]

@vandenk Exactly. DirectDraw is more useful on Windows 9x/ME than anything past XP.

Perhaps then, I should remove it. If anyone needs it, they can rewrite it to add it back. Hopefully when they do, they'll write it to tolerate hardware/software surfaces this time.

[joncampbell123]

I will remove it then, in the next binary release.

[vandenk]

Ok I close this issue

[joncampbell123]

@vandenk Not yet, let me remove it first, then I will close the issue!

[joncampbell123]

It's done. One more issue to fix: If you start up DOSBox-X with output=ddraw the window pops up and disappears.

[joncampbell123]

Done

[joncampbell123]

Also found a segfault that can happen if you startup in surface or OpenGL and use the menu to switch to Direct3D output.