Horde3D

Hm, I actually would like to be able to choose between OpenGL and DirectX at runtime (well, not that I'd actually care about DX, as I'm on Linux, but I anyways think this is the easiest thing when it comes to the user interface (probably the most difficult when it comes to coding though).

I'd like to see a branch in public svn for this one :p

dunno... IMHO it doubles the work. for example you would need both HLSL and GLSL scripts( or compile them dynamically from a common lang; overkill)

Only if you want to have a opengl fallback, if you use the dx renderer then you don't really need glsl shaders, pick one or use cg

Realistically no one is calling Horde3D::___FUNCTION___ in practice within any serious project. They've got their own abstract interface, in my case based on Horde's API. Many DX capable APIs let us feed the data we want, making it possible to parse the Horde XML and binary formats as needed. Even though Horde is my renderer of choice, if I want to write another render system, the only difficulty will be writing a "cooker" to convert those xml asset / shader files or writing import routines.

I thought we were giving the users a choice between gl and d3d

Then you *have* to develop both sets of shaders. At the very least, if we go this route then you need to be able to disable renderers at compile time.

It would be much less work to just make the renderers selectable at compile time. I also don't see a use case for runtime-selection: on windows, D3D always beats OpenGL, and everywhere else, D3D does not exist.

_________________
Tristam MacDonald - [swiftcoding]

I'm agree with kal.
I think selecting render engine at compile time provides a big feature leak ! By selecting render engine at compile time :

1.you must recompile the game many times to find and debug the render problems.
2.you must compile the game one for the DX and one for the OGL
3.your game fails to provide compatibility for the game users, imagine that someone have some problems with DX drivers on his computer and he couldn't switch to the OGL because of the preselected render engine at compile time
4.It's too difficult to add software renderer to the engine in future

you can solve the shaders problem by adding CG shaders support to the engine, if you think it's too difficult and your problem is rewriting shaders in both GLSL and HLSL there is a lot of programs such as RenderMonkey and FX Composer that they can provide shaders in GLSL, HLSL and CG !

Well, Cg is told to have quite some problems on ATI cards. I doubt this engine will ever go for software rendering though

Since you can use Horde as a DLL you can just switch rendering by loading another DLL dynamically. So if the rendering is compiled into the Horde3D DLL statically, you can still switch between the rendering backends by unloading your previous DLL and reload another one (of course it would be usefull if the interface to the DLL remains the same). Since Horde3D does not manage rendering contexts itself you have to handle rendering backend switches in your application anyway.

It's great to make the both interfaces same,This will reduce the code rewriting or need to write wrappers for DX and OGL by hand.
I'm not a pro OGL or DX guy but IMHO it's better to merge both DX and OGL in one DLL then by selecting backend at runtime switch between DX and OGL [If it's possible]?
Is it possible to use GLFW.dll (I guess not) with D3D backend or we must going to use other DX tools such as DirectInput, ... ?

It would be cool to be able to switch between DX and GL at runtime but other from that I don't see a real need. As swiftcoder says, probably D3D would be standard for most Windows apps and for the rest there is no choice anyway. But once we have a good API abstraction layer it is probably not too difficult to switch renderers...let's see.
Concerning shaders, what many commercial engines do is using a mixture of native HLSL (Window and XBox360) and Cg (for PS3). Since both languages have more or less the same syntax they can use unified shaders. But opposed to GLSL, Cg is a heavy dependency so I wouldn't like to switch to it by default.

Regarding runtime selection of GL/DX, I think it would be better to keep this outside of the Horde DLL. Horde should compile against one API at a time. If (when?) we get D3D support we should perhaps rename Horde3D.dll to HordeGL.dll and HordeDX9.dll.

As swiftcoder said, runtime selection of the graphics API can then be implemented in the application or utility layer.

Yeah you can still use GLFW's input functions at the same time as D3D, if you like.

IMO you should *never* use DirectInput because it is slow and adds unnecessary latency to user-inputs.
Even microsoft says not to use it unless you have to: "Overall, using DirectInput offers no advantages when reading data from mouse or keyboard devices, and the use of DirectInput in these scenarios is discouraged."

I would also choose the two DLLs option.

For shaders it would be great to use the same code for GLSL/HLSL. I think Crytek uses a preprocessor for this. I'll write some GLSL shaders than I will have a better understanding of this issue.

I haven't started working on the d3d9 renderer so I can't tell when it will be done.
And of course if someone has more time to work on it, I would be happy to test it or help in it.

Any updates?

_________________
Paul

There is allot of interest, but so far no one has step forward and added their name to the wiki.