Well, there isn't much to see, at this point.
I'd like to work on the CPUInfo application for a bit now, then I'll get back to the D3D engine... I still haven't ported all my code over, so I can't actually load objects from disk yet. I'll post something eventually, when there's actually something more to see than just some spinning donut :)

I've been busy with reinstalling my laptop, getting a new home server and some other stuff, so I haven't actually done any coding recently.
Posted on 2009-07-23 07:45:39 by Scali
I've been writing various components for my game engine for the better part of three years now, and I'm only just now getting to the point where there is stuff to see beyond some simple rotating meshes.
Its easy to draw stuff, but thats the SMALLEST fraction of a 3D engine! People get frustrated if I refuse to release demos every other month, and they get disappointed if I do... you can't win.
It's all I can do to try to ignore that and keep rattling along at my own pace, and keeping that pace consistent.
I'm guessing you're in the same boat.
Posted on 2009-07-24 00:07:26 by Homer
Well, for me it's slightly different. I've written various 3d engines over the years, and I do have all the code for many of the things that an engine could/should do... It's just spread out over different languages and different iterations of the engine.
Even if I port it all into the current codebase, it'd only be the same demos that I've already shown years ago. Lots of work, and pretty pointless really.

I do have some ideas for new functionality, but at the moment I can only implement those using Cuda. I'm basically just waiting for the final release of DX11, where I have hardware acceleration of all the features, including Compute Shaders.

Aside from that, I've lost most of my interest in developing 3D stuff in my spare time... and I haven't had a lot of spare time anyway, lately.
In fact, I hadn't touched my 3D code in years. I think the original D3D9 engine hasn't been touched since 2006 or so. Then in 2007 I had some time and tried to port it to D3D10, but it proved more difficult than I thought, so I just abandoned it.
Now it sorta works in D3D10, but that's about it. Lots of tedious work to do, without a lot of interesting results... I'm not really motivated.

Currently I'm just trying to solve some of the user-interface things that have been there for years. Things that, thanks to DXGI, will hopefully remain useful for years to come. In the past I never really gave myself enough time for it, because my main goal was to work on functionality and some specific graphics effects or algorithms, rather than making a nice, robust, userfriendly application.
Posted on 2009-07-24 04:27:41 by Scali
Ah, I did actually fix *some* of the problems with the DX9 code...
I found that it didn't call Reset() properly in all cases. That would explain why it couldn't recover rendering. It always did in the old engine (it also didn't resize the rendertarget when resizing the window... it does now, as it always has).
Still doesn't solve the problem that your fullscreen window seems to get minimized by Windows automatically as soon as another window gets focus. I'm not sure how to prevent that from happening, if it's possible at all.
But since you can now always maximize the window again, and it resumes rendering, I don't think it's a big problem.

I'll worry about other things first, like how to get the fullscren resolution right in D3D10 :)
Posted on 2009-07-24 20:41:31 by Scali
Semi-related to this topic...
The new August 2009 DirectX SDK is out, and this time it contains an official release version of DirectX 11 rather than just beta runtimes:

I'll be playing with that a bit, and fix my code up to run with the final binaries. Then it should run on any Vista and Windows 7 system without special developer runtimes.
Posted on 2009-09-10 04:02:13 by Scali
Hum... the actual DX11 runtimes for Vista are still in a public beta stage. Which meant that out-of-the-box, none of the August 2009 SDK DX11 examples worked. There just weren't any DX11 runtimes installed at all (they removed the beta ones that were in the earlier SDK releases).
So I had to download and install this script to get access to the Platform Update for Vista, which includes the DX11 runtimes:

For some reason it didn't work on my laptop with Intel graphics (the D3D11.dll is still missing), but it did work on my desktop with an nVidia card. I'll see if I can copy the missing files over, and get it working on the laptop aswell.

Another surprise was that nVidia has released a new GPU Computing SDK, and they support DirectCompute aswell now. So for the first time I actually got to see the DX11CS samples with hardware acceleration. And the first impression was pretty good. It seemed to be much closer to Cuda performance than some of their OpenCL stuff.

Anyway, I fixed up my code to work with the RTM runtimes rather than all the stuff with the _beta suffix. And now I have an official D3D11-capable engine :)
It should now run out-of-the-box on a Windows 7 machine, since they come with DX11 preinstalled. I just couldn't use that up to now, because the SDK only contained the beta stuff, which linked to files with a _beta suffix, so you had to install the beta runtime anyway on Windows 7. I still have the Windows 7 RC installed, so I'll check if it works on there.

Anyway, this means that at this point I will be abandoning the DX10/10.1 part of my codebase. A lot of the code should be compatible between DX10 and DX11, but I don't really see a point in using the DX10 stuff anymore. If you can run DX10, you can run DX11.
I'll see if I can put some new binaries up, with the full DX9/DX10/DX11 and 32/64-bit stuff... and some of the fixes/improvements I've done on them a while ago.
Then I'll probably continue work on the CPUInfo lib first, because I want to get that ball rolling, and the best way is with a nice free opensource application similar to CPU-Z, I think.
After that, I'll return to the 3D engine, and dig out the old scene loading code, and get some more inspiring visuals on screen.
Posted on 2009-09-11 02:35:07 by Scali
I think the problem with my laptop is that it has a Dutch version of Windows Vista installed. I copied some files over from my English Vista manually, and managed to get DX11 working on my Intel X3100 onboard chip. Sadly it cannot do DirectCompute though, will require a driver update I suppose.

I fired up my Windows 7 RC installation, and uninstalled the March 2009 DirectX SDK and runtimes, and my D3D11 code still runs.
So it should indeed run out-of-the-box on a Windows 7 installation now. I did need to update to the latest nVidia driver to get DirectCompute working, but it didn't require a special beta driver or some registry hacks to get it working. Just the standard 190.62 WHQL drivers.
Posted on 2009-09-11 16:45:17 by Scali
Microsoft has confirmed that the public beta is only for English versions of Windows at this point. It's a bit of an oversight that they didn't make that more clear on the website or during installation.
They also hope to get the platform update out of the beta stage shortly after the public release of Windows 7 (which would be the 22nd of October).
So within about 2 months we should have final DX11 support on Vista, just like on Windows 7.

A small caveat is that DX11 will require SP2, just like DX10.1 required SP1. I personally am not bothered by that, I think every user should have the latest servicepack installed... but sometimes I do run into people who deliberately do not install servicepacks. This will force some developers to continue supporting DX10 and DX10.1 aswell... Together with DX9 that still has to be supported because of people still using XP... that's a total of 4 different APIs to support.
Posted on 2009-09-15 06:41:48 by Scali
Fine by me - becoming an expert at version wrapping :)
Posted on 2009-09-20 03:58:33 by Homer

Fine by me - becoming an expert at version wrapping :)

Didn't you just support DX9 though?
Posted on 2009-09-21 09:43:39 by Scali
No good here (32 bit XP, D3D9 August 2009 runtimes)
Theres no GPF or anything, it terminates cleanly without apparently doing anything.
Posted on 2009-09-21 10:26:47 by Homer
Well, that's the thing with this approach...
I just try to see if my DLL loads. If it does, I import some functions that I expect to be there, which I can then call to see if a DX device of that particular version can be built (you could have DX10/11 installed, but a videocard/driver that isn't capable).
If the DLL doesn't load, it's a missing import... That could be either a DX library, or something completely different, eg Visual C++ redistributables, fmod, etc.
It's very hard to try and give some meaningful error message at that point, but on the other hand it's very easy to check if 'it works'.
I could do some generic message like "Okay, I tried all versions, and nothing loaded", but normally that shouldn't happen. You should at least be able to run DX9.
I suspect your problem is a lack of VS2008 SP1 runtimes, not DX-related.
Posted on 2009-09-21 11:22:23 by Scali
I think I could create a simple internal log...
I can keep track of which DLLs I try to load, and then the result.
There are basically three ways in which each DLL can fail:
1) The DLL doesn't exist.
2) The DLL exists, but LoadLibrary() fails anyway. Apparently there are missing libraries, I just don't know which (could be missing D3D version, or something else).
3) The DLL exists, and loads, but my Test()-function failed to create a valid Direct3D environment.

If I just log these errors, I could display them if I fail to get ANY DLL opened. Perhaps have some option to display it to the user even if it does load a DLL (so that if he falls into DX9 mode, he will be able to see why DX10 or DX11 didn't work). Then it would just be silent under normal conditions.
But it's always going to be hard to get meaningful errors. You can test if it works or not, but there could be a million different reasons why it won't work.
Even if you know which particular DLL failed to load, it's often difficult to figure out where to get it (eg the Visual C++ 2008 SP1 redistribution package).
Posted on 2009-09-24 06:43:27 by Scali
You could delay-load potentially troublesome DLLs, and use SEH to handle the situation - dunno if you get the DLL name in the exception handler, though.
Posted on 2009-09-24 09:21:44 by f0dder

You could delay-load potentially troublesome DLLs, and use SEH to handle the situation - dunno if you get the DLL name in the exception handler, though.

But that's exactly the thing... It's far too much work to figure out all the 'potentially troublesome DLLs' and using delay-load and all that.
The reason why I chose this loader system is because it's very simple and robust. I just code my DLL with everything on it, not having to worry about anything... Then the loader will see if it works or not, in a clean and non-fatal way. So basically I reduced the problem to delay-loading a single DLL.
Posted on 2009-09-24 09:32:46 by Scali
Potentially troublesome DLLs is pretty easy; Visual C++ runtimes, DirectX DLLs, and anything you know won't be installed on a typical end-user system because it's stuff you've specifically downloaded :)
Posted on 2009-09-24 09:47:29 by f0dder

Potentially troublesome DLLs is pretty easy; Visual C++ runtimes, DirectX DLLs, and anything you know won't be installed on a typical end-user system because it's stuff you've specifically downloaded :)

If it really was that simple, I would have done it.
Reality is that with all the different versions of Windows, and all the servicepacks and hotfixes and all that, it's impossible to tell what is going to work where.
I don't have a large collection of machines and OS configurations to test on. I just have my own PC, which may have multiple versions of Windows installed, but all with at least two versions of Visual Studio installed aswell, and all the latest updates.
It's just impossible to track down every potential point-of-failure, let alone to try and handle each problem in an elegant way. Just look at how complicated my code was for simply checking for a 32-bit or 64-bit OS. You need different versions of the same API calls, which may or may not be available in the kernel library, depending on what Service Pack you have installed and all that... And that's just ONE operation.

Besides, figuring out which DLL or function is just one part of the problem... then you still have to map it to some meaningful information to the end-user... eg missing function() in library.dll -> Install Service Pack 2 or higher. That's just impossible to do.
I guess the best thing to do is just to tell the user that it didn't work, and then give a standard predefined message with requirements, hoping that you caught everything.
Posted on 2009-09-24 09:52:17 by Scali
Well, if you try to take it to function-call granularity, sure, things get a bit hairy - MSDN does have information (as long as you don't care about older Windows versions), but dunno if it's always correct. But imho logging missing-DLL would be a useful diagnostic.
Posted on 2009-09-24 10:02:31 by f0dder

Well, if you try to take it to function-call granularity, sure, things get a bit hairy - MSDN does have information (as long as you don't care about older Windows versions), but dunno if it's always correct. But imho logging missing-DLL would be a useful diagnostic.

Well, if you want a 'perfect' solution, you have to take it to function-call granularity... Because older versions of a DLL may not have a particular function. That's different from the DLL not being installed at all.
Logging any DLL load failures would be useful, problem is that it's sadly not that straightforward to do. I wish I could just do LoadLibrary() and then get accurate info on why it didn't work. Which DLL failed, or which function?
The main problem here is that it isn't recursive. I could delay-load MY DLLs, but if these DLLs themselves also import other DLLs, I don't think I can get any info on those, because those DLLs were not built as delay-load.
And even so, converting my code to delay-load is not just a flick of a switch, I guess. I'd also need to catch all the default libs and such, which I now take for granted. And I'd need to craft my own handler etc.

If you're going down that route, it might be better to just build your own lightweight Dependency Walker-routine. Just walk all the import tables yourself, and recursively check for problems. May actually be less work... in fact, might be a useful open source project :)
Posted on 2009-09-24 10:08:21 by Scali
Random thought:
I suppose I could do some simple pattern matching on DLLs that can't be found or where functions are missing.
Eg, for "msvc*.*" or "mfc*.*" I could suggest to install the VC++ redist.
For "d3d*.*" I could suggest installing the DirectX redist.
Since it's open source anyway... you could create lists of DLLs that map to certain messages. You could build default lists for whatever is in certain redistributable packages, and have anyone extend/customize it for whatever they want.
I might look into that this weekend.
Posted on 2009-11-06 08:30:52 by Scali