Irrlicht Engine

Well, it's also a question of how far abstracted your high-level API is. Of course you cannot provide a tesselation shader alternative, if none exists. But seeing that this is usually an optimization which will be enabled or disabled even for those platforms that would support them, there's no reason why it would be just bad to have some lacking support here or there. And if things are slower of less detailed due to old hardware that's to be expected by the users anyway.

@fmx: Yes, for me a basic implementation with, say, support of 3/4 of the features shown in the Irrlicht SDK examples would be enough to put it into the core engine. Before that I'd probably host it as another development branch just as the ogl-es drivers (which are to be included into the core in the near future, though, as they are rather feature complete).

A basic D3D11 driver would probably be the best way to go. But if we're going to integrate D3D10/11 then it should use the feature levels support from DX11 to do DX10. And also, DirectX 11.1 is out, so it would be best to use the D3D11.1 SDK to implement it.

dx11.1 is out O.o well indeed the driver should be implemented on the last version of the sdk and use diferent feature lvls

Well if DX11.1 is that far allready and DX12 is around the corner, lets just rewrite irrlicht from scratch when that comes out?

As I am not the one doing the work, I am reluctant to say what needs to be done. Windows 8 media is DX 11.1, but in compatibility mode aka desktop even dx8 runs on it fine. It seems between 9 and 11.1 there is a gulf, that would define irrlicht. DX9 and earlier and 11.1 and later. DX10 will fade away as it should along with ME.

What are you saying dude? It makes little sense!

So has anyone other than myself actually downloaded evandromillian's code and used it for something? See the Screenshot Of The Month July 2011 for details - http://irrlicht.sourceforge.net/forum/v ... 20#p253220.

i have it on my computer and most of my older project were using it butt then i moved to the SVN

Can it be used right now? I was thinking it was still too early to be used "as-is"...

christianclavet wrote:Can it be used right now? I was thinking it was still too early to be used "as-is"...

I thought this as well
I'm currently playing with Nadro's updated FVF irrlicht but I might look into it

yes it can but some project will run into issue

Were geometry shader implemented in this driver?

Also anyone tryed using it with the SVN?

I sucessfully ported the code from from irrlicht 1.71 to the 1.8 svn.

Idealy i would start working from it to build a functional DX11 driver for irrlicht now i need to understand a couple things.

1. The licensing of the current driver is zlib does that mean that a modified version could be integrated with irrlicht as long as proper credit is given?

2. Nadro built a FVF patch that is suposed to be complete and this driver has a FVF to so what is the status of the FVF patch? is it updated with the rest of the SVN ? and should i work toward integrating the FVF patch with this driver?

Basically yes to all. Nadros SVN branch will closely follow trunk and has far better chances to be integrated into the core engine due to active support by a dev team member. So it's probably a good idea to adapt this driver to the shader pipeline branch (and maybe use that one as a base).

Alright i got it to compile fine with the Shader pipeline branch now i need to understand nadro's FVF implementation completly to get the driver working


Also i'm not sure about how it works but currently looking at it it seem like the implementation lack some parameter that would be used for directx10 instancing.