Finally, a DirectX 10 video driver for Irrlicht

evandromillian · Post by **evandromillian** » Wed May 19, 2010 6:12 pm

Hello everybody.

I spent three months developing a video driver for DX 10. Only the basic infrastructure is ready, and there are still problems to solve, like objects with dynamic geometry (sky boxes, particles and text scene nodes), since DirectX 10 only supports vertices in buffers. But there's good results. See the screen shots:

In this, I still have some problem with visualization of sky dome...

The driver is using DirectX 10.1, which permits use of WARP driver, enabling acceptable performance even on machines without dedicated video cards. It's also only supporting feature levels 10.0, 10.1 and 11.0 (to use feature levels 9.X, use DirectX 9 driver

).

Additionally, I made some other changes, like preparing some classes to add effect material (like HLSL FX and CgFX).

I developed DirectX 10 version together with DirectX 11, just to allow using Cg plugin, because there's no Cg API for DX 11, so I started with DX 10.

It's available in BitBucket: http://bitbucket.org/evandromillian/irr ... x/overview

I wait for comments.

ACE247 · Post by **ACE247** » Wed May 19, 2010 6:29 pm

WOW!

Are you serious?
This is just too good, finally at least the groundwork for a DX10 Driver is made!
And its your first post.
I want to see more

greenya · Post by **greenya** » Wed May 19, 2010 7:02 pm

Great news man.
Really would like to see more screens!

bitplane · Post by **bitplane** » Wed May 19, 2010 7:32 pm

Nice work! Will you need the GUI to be rewritten to support DX10? I think we'll need an OnPostRender or something in the skin (everything is batched up during calls to the skin and then presented as a hardware buffer during postrender)

evandromillian · Post by **evandromillian** » Wed May 19, 2010 7:42 pm

Hi, and thanks for all.

Really, for gui and other drawing modes, will be great make them to support hardware buffers, but I'm developing some dynamic buffers inside the driver. I will upload some amount of geometry each time and draw. This way, at least for this stage, we won't need to rewrite the core of engine.

I will post code in some SVN this week, and I will apreciate the help of all community to complete this long-awaited feature.

Thanks once more.

Nadro · Post by **Nadro** » Wed May 19, 2010 8:46 pm

Good work, I think that we should prepare similar rendering model in both DX10 and OGL3 drivers (eg. builtin material types doesn't work), so when user will run some code on DX10 and OGL3 driver without shaders, screen should be looks identical on both drivers. I'm waiting for code

BTW. Some functions code like draw2DImage should look similar on DX10 and OGL3, so we can use one code for both drivers.

3DModelerMan · Post by **3DModelerMan** » Wed May 19, 2010 9:58 pm

Awesome!!! I was about to try and do this myself, but now I won't have to. I would love to help out on this if you need any.

evandromillian · Post by **evandromillian** » Thu May 20, 2010 2:31 pm

Hi for all.

Follow the link of project in BitBucket:

http://bitbucket.org/evandromillian/irr ... x/overview

The project was developed using Irrlicht 1.7.1 as base. Much of ideas of DirectX 9 driver was used too. There are changes in IVideoDriver (addEffectMaterial method), adding of new driver types (EDT_DIRECT3D10 and EDT_DIRECT3D11), also in IMaterialRendererServices (setEffectVariable method) and other places. I think that the addition of shader material renderers can be the last issue; all infrastructure shall be working well first.

I think that the main issue now is to fix drawing of scene nodes with dynamic geometry or those that don't store geometry in hardware buffers (as text and sky box scene nodes, as well as GUI).

Hey bitplane, takling about GUI, I like your idea. This will be a great evolution not only for Direct3D 10 driver, but for all, cause in today drivers the use of hardware buffers is much faster than glVertexPointer (without buffers) or DrawPrimitiveUp in DX9.

I'm counting on all of you to evolve the project.

Cheers

Nadro · Post by **Nadro** » Thu May 20, 2010 2:52 pm

For dynamic data (2d images, text, particles etc.) You can create built-in buffer with simple quad and You can transfom them and draw (similar to OGL3 method).

evandromillian · Post by **evandromillian** » Thu May 20, 2010 5:48 pm

We have to take into account that DX 10 only draw with vertex and pixel shaders, no fixed function.

So, we have two situations

- for 2d:
- we can use dynamic buffer for vertices, using solid material renderer
- OR (as you suggest) using a built-in quad buffer, but we shall transfer transform matrices to a constant buffer and using DrawInstanced and a custom material renderer

- for dynamic geometry (skybox, particles), there's no other simple way than using dynamic buffers, due to use of material renderers.

Of course, we could use instancing for GUI, only uploading scale and position matrices, but this requires use of a custom renderer, requiring more effort.

This is the reason that I prefer using dynamic buffers, to better adapt with Irrlicht core, DX 10 material renderers (and shaders) and the different types of scene nodes.

slavik262 · Post by **slavik262** » Thu May 20, 2010 6:47 pm

Amazing job! How fast can this be integrated into Irrlicht proper? I mean, I know there's still a fair amount to be worked out (and I understand why), but it would be great to see this in Irrlicht.

evandromillian · Post by **evandromillian** » Thu May 20, 2010 7:58 pm

It's very difficult to integrate DX 10 into any engine, because there's no more fixed function pipeline (forcing to create shader generators or many specific material code into shaders, see CD3D10FXMaterialRenderer shader code) or a simple way to set transform matrices and variables to APIs.

On the other hand, I like so much the idea to move validation to creation time, because this free much processing needed by driver each time you set a texture, a state value, buffer etc.

I like Irrlicht so much, because the higher level of control you have in game (much more than Ogre3D, for example). Of course, you need to code more, but this is the price. That is why I started this project.

hybrid · Post by **hybrid** » Thu May 20, 2010 8:57 pm

I did not yet even check one piece of code, but a major request: Could you change the license to zlib? Or at least would you change it at some point in case we'd add this driver or parts of it to the engine?

3DModelerMan · Post by **3DModelerMan** » Thu May 20, 2010 10:03 pm

I really hope this gets in the engine. That would be great. I'll check out the source code soon. The best features so far seem to be the new shader models, and the .fx file support. Will this do geometry and compute shaders?

slavik262 · Post by **slavik262** » Fri May 21, 2010 4:08 am

evandromillian wrote:It's very difficult to integrate DX 10 into any engine, because there's no more fixed function pipeline (forcing to create shader generators or many specific material code into shaders, see CD3D10FXMaterialRenderer shader code) or a simple way to set transform matrices and variables to APIs.

On the other hand, I like so much the idea to move validation to creation time, because this free much processing needed by driver each time you set a texture, a state value, buffer etc.

I like Irrlicht so much, because the higher level of control you have in game (much more than Ogre3D, for example). Of course, you need to code more, but this is the price. That is why I started this project.

I'm aware of the complexities of integrating DX10, which has no Fixed function pipe, into an engine like this. Don't take any of my comments as criticizing your work or speed. You've done a wonderful job.