VIDEO - Direct3D patch (Host)

Here you can discuss the development of patches.

VIDEO - Direct3D patch (Host)

Postby gulikoza » 2005-6-30 @ 13:59

I know you're probably already familiar with my D3D patch, but since the original topic is long lost in the forum archives I thought to reopen it.

Direct3D support for dosbox has come a long way since I first released it. I started it to overcome the speed penalty ATi cards get in OpenGL mode and now I think it's safe to say it provides fast & stable hardware accelerated output mode suitable for running on any recent (dx8+) GPU (Windows only of course :)). It also has support for using hardware scalers which can enhance low-res games using the power of today's graphics cards. D3D scaling algorithm is also a bit different from what other modes use, it has been modified to look better on LCD monitors which can blur low res images.

Latest version adds support for the 2xSaI hardware filter.

Patch source and cvs builds (with some other experimental patches) can be found on my page: http://www.si-gamer.net/gulikoza

In this thread you should discuss problems, bugs, improvements or any other ideas you might have...

(moderators: feel free to move this to the patches section :happyhappy:)
Last edited by gulikoza on 2006-2-01 @ 23:26, edited 1 time in total.
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby Kaminari » 2005-7-02 @ 12:51

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]
User avatar
Kaminari
Oldbie
 
Posts: 774
Joined: 2002-12-06 @ 01:54

Re: Direct3D patch

Postby barfoot » 2005-7-02 @ 22:32

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.
User avatar
barfoot
Newbie
 
Posts: 9
Joined: 2005-6-23 @ 04:30

Re: Direct3D patch

Postby ykhwong » 2005-7-03 @ 01:09

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.
ykhwong
Oldbie
 
Posts: 627
Joined: 2004-3-17 @ 15:35

Re: Direct3D patch

Postby gulikoza » 2005-7-03 @ 04:20

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.
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby HunterZ » 2005-7-03 @ 18:51

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.
You're perfect, yes it's true...but without me, you're only you.
User avatar
HunterZ
l33t++
 
Posts: 6073
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Direct3D patch

Postby gulikoza » 2005-7-03 @ 19:47

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...
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby Dominus » 2005-7-03 @ 20:36

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?se ... w&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 :)
User avatar
Dominus
DOSBox Moderator
 
Posts: 7578
Joined: 2002-10-03 @ 09:54
Location: Vienna or Ludwigsburg

Re: Direct3D patch

Postby HunterZ » 2005-7-03 @ 21:17

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?
You're perfect, yes it's true...but without me, you're only you.
User avatar
HunterZ
l33t++
 
Posts: 6073
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Direct3D patch

Postby gulikoza » 2005-7-04 @ 05:32

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 :)
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby gulikoza » 2005-7-05 @ 13:15

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...
Last edited by gulikoza on 2005-8-07 @ 10:10, edited 1 time in total.
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby ykhwong » 2005-7-05 @ 13:37

Thanks, gulikoza.
I don't need to run this command any more.
Code: Select all
export LIBS="-ld3dx9"

- Adding to "ld3dx9" to 'LIBSS=' line in Makefile
Last edited by ykhwong on 2005-7-06 @ 07:19, edited 1 time in total.
ykhwong
Oldbie
 
Posts: 627
Joined: 2004-3-17 @ 15:35

Re: Direct3D patch

Postby gulikoza » 2005-7-05 @ 13:45

Nope...no more Makefile editing, setting -I or -L, etc... :D
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby Qbix » 2005-7-05 @ 14:41

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.
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10558
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: Direct3D patch

Postby gulikoza » 2005-7-05 @ 21:01

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 :D). 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 :P. 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...
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby Darkfalz » 2005-7-06 @ 09:13

Free triple buffering?
Darkfalz
Member
 
Posts: 128
Joined: 2003-12-15 @ 13:30

Re: Direct3D patch

Postby `Moe` » 2005-7-06 @ 15:36

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.
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: Direct3D patch

Postby gulikoza » 2005-7-06 @ 16:54

I already have :happyhappy:. 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?
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Re: Direct3D patch

Postby `Moe` » 2005-7-06 @ 17:55

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?
User avatar
`Moe`
Oldbie
 
Posts: 1169
Joined: 2004-4-29 @ 01:06
Location: Oldenburg, Germany

Re: Direct3D patch

Postby gulikoza » 2005-7-07 @ 06:57

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 :happyhappy:. 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.
User avatar
gulikoza
Oldbie
 
Posts: 1700
Joined: 2004-6-25 @ 14:53

Next

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest