Finally, a DirectX 10 video driver for Irrlicht

[Mel]

I think it would be most probable, bit if Irr is to be up to date on Windows platforms, the option to have a DX11 driver is important.

[hybrid]

We will integrate the ogl-es driver for Irrlicht 1.9, not sure if we can also do this one into the same release. Maybe we can put the dx10/11 driver into the branch and see how times go.

[Nadro]

As I said before I think that v2.0 would be ok for add new drivers (this and OGL3/4). What about branch? I think that we should put this driver into shader-pipeline branch, so driver would use FVF stuff (but firstly maybe we should update this branch to the latest trunk?).

I totally agree with Mel, that we should be up to date with some new API's (DX11 is for example important for MS store for Windows .

[Nadro]

OK, I updated shader-pipeline branch to the trunk. Now I need a patch with DX11 support created against trunk, I will put them to shader-pipeline branch (temporarly with semi disabled FVF support for this driver like in D3D8 driver). Next updates you could prepare against shader-pipeline branch. It should speed up developing process.

In this branch we can add features like an instancing, texture arrays, transform feedback etc. without any problems.

[Granyte]

There is one on the previous page.

Good news if you add the multiple VertexBuffer per MeshBuffer i will update the instancing patch for dx9 how ever i dont have the knowledge to write it for OGL

[Nadro]

Thanks for info. I'll put them into branch tomorrow and next we'll improve FVF system (like multiple vertex buffers support and other things require to DX11). True hardware instancing for OGL require hardware compatible with OGL3 (DX10), so we'll not implement instancing to OGL 1.x/2.x driver.

UPDATE:
Driver is uploaded on shader-pipeline branch. I have following info for them:
- CD3D11ParallaxMapping filer are missing in this patch, thats why I commented part of code related to create materials and include those files.
- Please remove Effect11 dependencies if You can, because it require to include DX11 sample code to Irrlicht build which isn't nice (Effect11.lib and d3d11effects.h).
- Some examples doesn't work for me (eg. skybox in terrain mode, shaders), but other works fine eg. Quake3Map. I modified drawVertexPrimitiveList (now it's compatible with FVF stuff), updateHardwareBuffer (Index and Vertex) and drawHardwareBuffer.

I see that EDriverFeature.h file include too much unimportant stuff like eg. HLSL, GLSL, ARB PIXEL SHADER, VERTEX SHADER variables etc. I'll split it into SHADER_MODEL_X_X packages.

[Granyte]

i don't think we can remove the effect11 dependencie but maybe we can actualy include the sources as part of the source code.
the effect framework is as far as i know the best and easiest way to have shader suport unless we develop our own wrapper for effects.

as soon as i get my devlopement machine i'll cheq the FVF trunk and provide the missing part but most shaders and material are still heavy in devlopement.

You mean you already made the dx11 driver FVF compatible?

Alright if you say it require dx10 hardware but i though the patch devsh made was using an extention that was availible in ogl 2.some.

[zerochen]

hi,

i think it is to early to ingerate this but if you really want here is my last patch.

dx11.patch


i made it against lastest irrlicht trunk.
it also includes all missing files.

I would suggest you to make the last changes undo and use this instead.

changelist:
- shaders can handle includes
- shaders handling reorganized + clean up
- shader vars can now set over the index
- skybox fixed
- stencil shadows doesnt break billboards anymore

regards zerochen

edit: oh rev4424 breaks the image drawing. i have to look at this before you can use the patch
edit1: ok fixed and reuploaded

[Granyte]

well it's the good time to fit it in a trunk so we can get more exposure and feedback

[Nadro]

This driver is too much bugged to be integrated with trunk. It'll be integrated with trunk when v2.0 developing process will start.

What about Effect11? We Why we can't suport normal hlsl shaders like in D3D9 instead of effect files? AAA games doesn't use effect files (this files are used mostly for tech demos). Now it's time to improve current existing D3D11 driver code without adding new features (like include in shaders). When we'll have the same level feature (properly working) like in D3D9 or OGL we'll add new features to them (interfaces must be compatible with OGL4 and vice versa). Thanks for the latest patch, I'll add fixes from them. What about FVF in current driver? Currently only basic interfaces are handling (so only builtin vertex types working like eg. in D3D8). If You will prepare next patches for this driver please do it against shader-pipeline branch.

[Nadro]

I applied this patch to the branch and it's doesn't work now (my AMD driver crash when scene is rendering, but I modified some parts in materials because inheritance was wrong and it didn't compile properly). I have following suggestion to this patch:
Inheritance is really bad here, I see many unnecessary places (materials files must be rewritten). Please use following files and class structures:
CD3D11MaterialRenderer
CD3D11HLSLMaterialRenderer or CD3D11SLMaterialRenderer (second option is better)
CD3D11FixedPipelineMaterialRenderer or CD3D11FPMaterialRenderer (second option is better)
CD3D11NormalMapRenderer
CD3D11ParallaxMapRenderer
and nothing more like that. Please also also do the same inheritance for material renderer classes like for example in OGLES2 driver (D3D9 and OGL have the same) and remove depedencies of Effect11 (we will not support effect files, just standard hlsl files) and dxutil.h - SAFE_RELEASE macro (this file is missing from SDK).

Please prepare this a changes against trunk or shader-pipeline branch (second option is better).

[zerochen]

hi

I applied this patch to the branch and it's doesn't work now (my AMD driver crash when scene is rendering, but I modified some parts in materials because inheritance was wrong and it didn't compile properly).

the inheritance is right and much better as it was before. have you just applied the patch or as i mentioned revert the dx11 add part and then applied the new patch?

I have following suggestion to this patch:
Inheritance is really bad here, I see many unnecessary places (materials files must be rewritten).

what do you mean with "unnecessary places" explicit?

Please use following files and class structures:
CD3D11MaterialRenderer
CD3D11HLSLMaterialRenderer or CD3D11SLMaterialRenderer (second option is better)
CD3D11FixedPipelineMaterialRenderer or CD3D11FPMaterialRenderer (second option is better)
CD3D11NormalMapRenderer
CD3D11ParallaxMapRenderer
and nothing more like that. Please also also do the same inheritance for material renderer classes like for example in OGLES2 driver (D3D9 and OGL have the same)

i already followed the naming convention of the dx9 driver. if you want to rename CD3D11HLSLMaterialRenderer to CD3D11SLMaterialRenderer do it. i have no problems with it. CD3D11MaterialRenderer and CD3D11FixedPipelineMaterialRenderer are the same, isnt it?

and remove depedencies of Effect11 (we will not support effect files, just standard hlsl files) and dxutil.h -

never touched that. i can try to remove it.

SAFE_RELEASE macro (this file is missing from SDK).

my patch doesnt use this macro

Please prepare this a changes against trunk or shader-pipeline branch (second option is better).

i would love to do it but i cant do it because the dx11 driver isnt applied to the shader pipeline. so i cant provide a patch only with changes to that.

i guess it doesnt work at all because you merged the old dx11 patch with my lastest.

regards
zerochen

[Nadro]

D3D11MaterialRenderer have problems with IShaderConstantSetCallback (inherit private member). I replaced all D3D11* files to files from your part (I didn't touch device specific files). I'll check it again soon.

[Granyte]

CD3D11MaterialRenderer and CD3D11FixedPipelineMaterialRenderer were not the same in my version and unles you modified it the CD3D11MaterialRenderer is the basic material class from wich all other inherit while the CD3D11FixedPipelineMaterialRenderer is the fixed pipline emulator that create all the fixed piplinle material.

also i don't understand why the exclusion is so necesary while the driver already suport hlsl files but i know that removing the dependecies is gonna be painfull and will require a complete rewrite of the fixed pipeline emulation system

[zerochen]

hm i cant really see the problem with the inheritance. its the same structure as the dx9 driver has.

Code: Select all

 
class CD3D9MaterialRenderer_SOLID : public CD3D9MaterialRenderer
class CD3D11MaterialRenderer_SOLID : public CD3D11MaterialRenderer
 
class CD3D9HLSLMaterialRenderer : public CD3D9ShaderMaterialRenderer
class CD3D11HLSLMaterialRenderer : public CD3D11ShaderMaterialRenderer
 
class CD3D9ShaderMaterialRenderer : public IMaterialRenderer
class CD3D11ShaderMaterialRenderer : public IMaterialRenderer
 
class CD3D9ParallaxMapRenderer : public CD3D9ShaderMaterialRenderer, IShaderConstantSetCallBack
class CD3D11ParallaxMapRenderer : public CD3D11ShaderMaterialRenderer, IShaderConstantSetCallBack
 
class CD3D11MaterialRenderer : public CD3D11ShaderMaterialRenderer, IShaderConstantSetCallBack
class CD3D9MaterialRenderer : public IMaterialRenderer
 

only the CD3D11MaterialRenderer changed because now its needs a shader file. (same as parallax now)
maybe its to late. i have more time this friday. so can have another look at it ...