Thanks for the build, Gulikoza 😀

Your Direct3D renderer works great, but I'm having somes problems with the SDL-OpenGLHQ renderer in a couple of games (mainly from Legend). I'm not sure if I should have posted this in Moe's thread, but since this is your build, it may be specific...

Sometimes, the cursor is stuck in a portion of the screen -- it's hard to describe for me. It's like the cursor can't move around the 640x400 resolution but instead is limited to a 640x200 zone which is vertically centered. Does that make any sense?

This only happens in window mode, not in fullscreen mode.

[Radeon 9550 + Catalyst 5.6]

I tried out the Direct3D patch. Pretty cool except when DOSBox attempts to switch from a game resolution (say 320x200) back to the standard DOS text resolution, I get a BSOD.

Interestingly enough this only happens if I have one of the pixel shaders enabled. I belive my card supports most pixel shader versions though, so I'm not sure what the issue may be.

My drivers are up-to-date as well.

You also need to apply DirectX DevPack 9.0b (not 9.0c).
There was DevPack in http://www.g-productions.net.
But you can't download from there now because admin considered that it is illegal lately (it was removed). headers and libs are needed, anyway.

Yeah it's really quite unfortunate that dx devpack is no longer available. But I wonder...if g-productions admin considers it illegal to host it, where should I host it then...for now I guess, there's always an option to compile with .net 2005 beta2 which is free at the moment...
other than that, sdl version should not matter, 1.2 branch is OK...

@barfoot: I'm not sure...but a user application should never cause a BSOD since it only runs in userspace. I do know however that some nVidia beta drivers caused BSOD with 2xSaI scaling, but I'm pretty sure it was a driver bug...perhaps they did not fix it entirely...

@Kaminari: yeah...I think I noticed it...but at the time I thought I had a dirty mouse sensor...but you should definitely post this in Moe's topic since I did not do big changes to his patch....it should work.

As someone mentioned on g-productions' forum, Microsoft probably doesn't actually care whether you distribute it as long as you aren't selling it. As someone else mentioned, it'd be best to provide a link to the official MS version and then a patch or post-installer to make it work with MinGW32/MSYS or Dev-C++ or whatever.

Bah...I hate Microsoft...
I've been toying with official June 2005 DX SDK and the headers seem to be fine (so there's no patch needed, just copy to some MinGW include directory). For dosbox, only a single library is needed - d3dx9, and that's no problem either: Reimp utlity (included in MinGW-Utils package) can convert between M$ and MinGW style libs. I've updated the code to compile with newest dx sdk, so that works too...The problem then is that the resulting binary needs d3dx9_26.dll. The dll is over 2MB in size (of course distribution is prohibited...) and the worse thing - M$ will bump the version with each SDK update! So a binary compiled with April DX SDK needs d3dx9_25.dll, if you will compile in August (when the next update is scheduled) you'll need d3dx9_27.dll. What a mess...

after struggling for a while and pm'ing gulikoza for help a couple of times, I finally managed to compile it with mingw/msys:
To do for the old diff:
get the DirectX 9 Summer Update SDK from 2003. Extract it and use the information on this page to convert the *.lib to *.a http://www.garagegames.com/index.php?sec=mg&m … e=view&qid=6939
Then throw the *.a files in your mingw lib dir. Then also throw the files of the sdk include dir into the mingw include dir. Edit dxfile.h by removing the last line of it. In d3dx9.h add #include <float.h> to line 20 and fix the includes starting from about line 43 (replace the "" with the <> tags).
Edit the Makefile in dosbox/src and add -ld3dx9d to the list of libs (the missing d in Gulikoza's instructions cost me hours 😀).
In the SDK find the file d3dx9d.dll and move it to where you install dosbox to.

That's it, now I'm ready for my holidays that start tomorrow 😀

That doesn't make much sense... How do commercial (and other non-commercial for that matter) games written with the DirectX SDK deal with this DLL issue?

Apparently they don't...yet! You're supposed to distribute dxsetup with every application. It's even recommended by M$ that you run it during install without prompting the user if he/she wants to install directx (of course...because even experienced users would probably click no to "Do you want to install DirectX9c?" since they know they already have it on the system...I would) so that it installs the missing dll. I'll probably modify the patch to make d3dx9 optional...making it compile without it as well (without shader support).

@Dominus: d3dx9d is the debug version of the library...release version is named d3dx9 😀

Indeed 😀

(see link to the patch on my page)

Here's an update to the patch. I've spent some time making it more compile friendly. It now modifies configure.in so you have to run autogen.sh before configure. It will add a few options to configure script:

--disable-shaders, will disable linking with d3dx9.lib even if it exists
--with-dx-headers=DIR, incase directx headers are not in mingw include directories
--with-dx-libs=DIR, incase directx libs are not in mingw lib directory

The configure script will now also properly check for d3d headers and libs. D3D can be compiled either with or without d3dx9. The good news is that mingw distribution already has all the files necessary to compile without shader support - compilation should be as easy as typing ./configure 😀

If you want shader scaling though, directx sdk is needed. The code has been modified to compile with all dx9 versions (9.0, a, b & c - ok, I won't bet my money on it, but I'm reasonably sure it should work 😀). The headers from the sdk can be just copied to some mingw reachable directory (specify with --with-dx-headers). For linking d3dx9 is needed. The d3dx9.lib library from official sdk has to be converted for mingw use with reimp utility. Just type 'reimp d3dx9.lib' and libd3dx9.a should be created (if it has a different name like libd3dx9_26.a, rename it - the configure script will only look for libd3dx9.a)...copy it to mingw lib dir (or specify a different directory --with-dx-libs=DIR). You will then probably also need to find a suitable runtime d3dx9.dll.

With these changes basic D3D support should be easy to compile and does not need any additional sdks or runtime dlls (other than what should already be installed on a xp machine). Shader support is somewhat more tricky, devpack9b is probably still the best bet if you have it. Otherwise you'll have to go with M$ official sdk...This changes should now also theoretically allow D3D to be compiled for x64 (since dx9b did not have x64 dx libs) but we might not be there yet 😀. I haven't posted this to my page yet since it's now harder to test all compilation cases, what is and what isn't available on some particular machine plus this is my first tinkering with configure.in script. It's quite possible I messed up something or that something could be made better...

Thanks, gulikoza.
I don't need to run this command any more.

1export LIBS="-ld3dx9"

- Adding to "ld3dx9" to 'LIBSS=' line in Makefile

Nope...no more Makefile editing, setting -I or -L, etc... 😁

browsed quickly through your patch:
It's better not to modify config.h.in (as it's generated)
but you should modify src/platform/visualc/config.h

and how does it behave with vga_parts 4 ? (last lines)
as I recall the 1 was needed on your system for something, but in general it could harm dosbox it's timing.

Yeah, the config.h.in is the one that was generated...I don't know why I included it in the patch, probably I thought this was visualc/config.h (the files are quite similar 😁). I'll fix it.

The vga_parts fixes some corrupt frames that really bothered me. I just have it in d3d patch so that I do not need a seperate patch and I hoped no one would notice 😜. If I understand correctly this defines in how many parts the screen is drawn. With vga_parts 4, some of the frames dosbox displays are actually composed of 3 or 4 different frames with ugly splits. 1 makes dosbox write the whole frame in 1 part but as this takes more time sound stuttering could occur. I haven't experienced any major problems so far so I've just left it this way...anyway, the original topic is still here if anyone is interested in this problem...

Free triple buffering?

gulikoza, take a look at dosbox-openglhq, I've used multithreading to hide the higher frame latency. I guess d3d also has this kind of latency (pixel transfer to the card) which doesn't actually cost CPU power, so a second thread makes sense.

I already have 😁. I've written something similar and I'm still having some problems. Texture locks fail from time to time and it's about 10% slower than single threaded version. Probably synchronization issues, it's hard to tell I don't have a lot of experience in this field. I'm sure that even single threaded version could work faster by careful examination where the stalls occur...perhaps even by delaying the output by 1 frame (make dosbox draw 1 frame, while drawing the previous to the screen)...there's for sure some work left to be done 😀

@Darkfalz: what exactly do you want to ask?

Well, yeah, that's about what I did with opengl. I think opengl is special since the requirements are stricter: Pixel transfers must complete before the opengl call returns, even if AGP-DMA is in use, stuff like that. So to get the same effect, I had to resort to a seocnd thread (SDL variant still does that, but more loosely coupled than in dosbox)
Did you use two (or more) internal framebuffers, so each thread has it's own buffer to work with?

Actually no, I'm using a single buffer with DISCARD flag (which should tell D3D to allocate a different buffer if the current is used in some drawing process). In D3D calls just queue in some command buffer until the buffer is full or there is a call which pushes them to the graphics card (the equivalents of glFinish() and glSwapBuffers() 😀). This also means that there is no guarantee which call will stall (it will usually be IDirect3DDevice9::Present, since there aren't that many calls to fill up the command buffer, but who knows).
The texture buffer should be allocated in the most optimal memory (I think this is the equivalent of having glAllocateMemoryNV()) where the graphics card can fetch it with AGP-DMA (is this where PCIe should perform much better? AFAIK AGP-DMA can only work from a limited memory addresses (AGP Aperature Size option in bios) and it's using normal PCI-DMA reads for other memory, whereas PCIe is using full speed up to 4GB).
Threads synchronize only in GFX_StartUpdate()...wait for semaphore (incase previous frame is still drawing), issue a texture lock, wait for lock to complete, return address & pitch to dosbox. In GFX_EndUpdate() unlock and present are issued and hopefully there should be enough time before next GFX_StartUpdate() to complete the drawing to the screen. Anyway, that's my theory, feel free to discard it 😁. But I still think the problem is thread timeslice. Present() shouldn't take more than 5-8ms that's well bellow ~10ms timeslice for each thread but still up to 50% cpu @ 70fps.