A blog entry from Cody Brocious about the Alky Project this week had let me think again about the possibility to run Direct3D 10 games on Windows XP. Some euphoric people have already called this a world saver or something like this. I am although have read comments that call this solution a back port. Something that many people had said is not possible at all. First of all this is not a back port it is an wrapper or to more exact an Direct3D API to OpenGL API translation layer. You may ask why something that could run D3D10 applications is not a back port. Well it may or may not run applications that make use of the D3D10 API but you still can’t use Direct3D 10 GPU drivers on other systems than Windows Vista. A full back port would required this and as I had written before this would requires a huge amount of work that is practical impossible for someone outside Microsoft. Maybe this Windows clone ReactOS would someday handle Windows Vista drivers but this would not made Direct3D 10 games playable on Windows XP.

You may say I should go away with this technical stuff as you only want your Direct3D 10 applications run on Windows XP and these guys will made it possible for you. They even talk about the unnecessary to update your video hardware. All this for only $50 that you have to pay to become a member of their Sapling Program. Doesn’t this remember on the bussines model of Cedega? Well Transgaming Technologies want $5 per month and I haven’t see any word about Direct3D 10 but at least you get more than simple promises for your money.

Talking about promises get us to the question: “Could the Alky Project successful?”

It is not impossible but in its current state this software is far away from giving you bank for your bucks. Not a single Direct3D 10 application I tried with it works correct. Most of them doesn’t even start at all. The rest produce not the correct visible result. Many Direct3D(X) 10 entry points are missing and even the functions that work are only stubs. Somebody mention in the comments to their blog entry that the wrapper use only the fixed function OpenGL pipeline and doesn’t care about the shader code. I don’t know how long they have need to put this together but hopefully not that long. Anyway I don’t expect that they are ready when the first game with Direct3D 10 support hit the shelf.

Does this mean that all hope is gone? Well the Wine team has started working on Direct3D 10, too. But natural they are focusing on Linux and their summer of code is more about building the basic infra structure. But with this there are only one step behind the Alky Project. Well anybody who starts with a Direct3D 10 to OpenGL wrapper today is only one step behind.

With at least two projects on the way we could though that the future of Windows XP gaming looks bright. But how long would it take until these approaches can show us some real results like running a game like it was meant on Windows XP instead of Windows Vista?

I don’t know the answer and therefore I had to wait and see.

After the April SDK still doesn’t contain a piece of a managed Direct3D 10 I decide to update my own solution again.  If you look at the new assembly you may notice that there is a Direct3D 9 namespace, too. The code behind this is not ready to use for more than simple device enumeration but I was too lazy to remove it from this build.

As every two month we got a new DirectX SDK.

You can download this piece over there. There is no download for the debug symbols as they are now distributed with the same symbol server that is used for the operating system symbols.

As every time a quick comparison of the new and old headers show some differences.

The D3DX9 version is updated to 33 but there are now API changes. A look at the release info shows that the new version was nessary because the shader compiler is updated.

DXGI defines 3 new status and error messages:

-          DXGI_STATUS_MODE_CHANGE_IN_PROGRESS

-          DXGI_ERROR_GRAPHICS_VIDPN_SOURCE_IN_USE

-          DXGI_ERROR_NOT_CURRENTLY_AVAILBLE

Let’s look at Direct3D 10:

-          The SDK version goes one up to 1001.

-          There is a new shader variable type: D3D10_SVT_TEXTURECUBEARRAY

-          3 new shader input flags: D3D10_SIF_TEXTURE_COMPONENT_0, D3D10_SIF_TEXTURE_COMPONENT_1, D3D10_SIF_TEXTURE_COMPONENTS

-          One new Name: D3D10_NAME_SAMPLE_INDEX

-          The shader debugging structures are removed.

-          The shader desc lost 4 instructions counts but they are still in the documentation (need to ask what’s going on there)

-          The sRGB D3DX10_FILTER enumeration values are back.

-          All functions that takes a thread pump take an additional pointer to an HRESULT were the asynchronous operation result can be stored.

-          The D3DX shader compile functions now take two flags instead of one.

-          The D3DX effect creation functions take additional profile information.

-          D3DX10LoadTextureFromTexture and D3DX10FilterTexture are not longer support a threaded operation.

-          D3DX10SaveTextureToMemory takes an addition flag parameter.