Horde3D

About that license thing: What about code from future contributors? You wouldn't be able to change the license if not all would accept it, which could get difficult even at relatively low numbers of contributors.

I'm always confused about those justice issues! But the way I understand the LGPL is that if you contribute to the core dll that is licensed under the LGPL, your contribution has to be also licensed under the LGPL, hasn't it?

Nope, it also can be a compatible license (like MIT, BSD, or even GPL which would then make the whole thing GPLed).

The only problem is the relicensing as this can only be done by the author of the code.

Yeah someone could license their contribution as GPL, which would in effect create a GPL fork of the entire library (so this would be a mean thing for a contributor to do!).

It's best to keep the whole library under one license (look what happened to Boost before they created the Boost license), so seeing that the SVN is only maintained by two people at the moment I think it would be best if they only accepted LGPL contributions (and unless people say otherwise, we can just assume that their contributions are LGPL )

I agree, except that the SVN is maintained by four people

I am happy with the LGPL for PC development, but consoles have no dynamic linking...

_________________
Tristam MacDonald - [swiftcoding]

That was exactly my point. Atm there is only LGPLed code in the repo anyways, and it won't be difficult to let that stay that way even with large numbers of contributors, the problem is when you at some point in time want to be able to statically link it and therefore want to change the license to MIT or something similar. Or even make a commercial license for that. That won't work as long as not all contributors agree.

The simple solution to that would be now, while there are only a few contributors, have all of us assign Marciano the right to relicense our contributions to any free license he sees fit. All future contributors to the main branch would then be required to agree to the same, although they are welcome to branch if they don't agree (as always).

This would allow Marciano to relicense the whole engine if necessary, or to grant LGPL exceptions for specific platforms, groups, etc. at his discretion.

_________________
Tristam MacDonald - [swiftcoding]

... and I actually wouldn't like to know that he is able to sell my code when I'm not able to do anything against that, especially with larger parts of contributed code. There has to be a better solution

(for example a license exception which actually allows statically linking the engine under certain preconditions, like keeping the interface of the engine as well as the source behind it intact, everything against that would then have to be opened under the same license)

That is why I specified any *free* license, in my last post

However, the larger point I was trying to make is that if we don't set up the mechanism to assign this right to someone very soon, it gets harder and harder to do over time (till you end up like Linux, where it is impossible).

Meh, sounds complicated. A more liberal "excepting testing and deployment on any device lacking a dynamic linker" would be simpler.

_________________
Tristam MacDonald - [swiftcoding]

Hi guys, there is a good DirectX9 wrapper on codeguru.com, IMHO it will accelerate the DirectX9 backend adding process

If the community wants to create the backend from zero by hand, just forget about it !

I we are going the wrapper route, would rather something a little better known (and thus likely to be maintained and tested).

_________________
Tristam MacDonald - [swiftcoding]

I don't think that a wrapper would be the best solution...

We changed the render engine from Ogre3D to Horde3D. I lack the d3d9 support though so I will start working on a D3D9 port but that will take a while because my daytime job and our hobby project is higher priority than d3d9 support. But this great engine and editor spared us a bunch of time so I would like to help the community.

I have some questions:
- How should be a new renderer integrated into the project?
-- separate renderer dll,
-- a horde3d dll with support of both (windows only)
-- separate horde3d_ogl and horde3d_d3d9.dll
-- any other possibillity?

The shader must be different (hlsl) :
-- the d3d9 renderer loads some other shader file (eg xxxxx.shader_d3d9.xml)
-- there would be some attribute in shader.xml <VertexShader profile="glsl"> or <VertexShader profile="vs_3_0"> that would describe the target of the shader.
-- I don't know glsl too well, but maybe some macros could hide the differences (so less work for implementing both, but this could create bugs hard to find)

Probably there will be some other problems: projection matrix differences, initialization differences, handling of d3d9's default pool resources lost, resource referencing differences (int handle vs pointer), there is no d3d9 texenv that stores sampler states (filtering, uv wrap, ...), no standard shadow map support. And probably much more but I haven't used OpenGL for years...

Let's avoid using wrappers. The backend is not a priority for the time being (at least not for me, since i have no intention to do any windows or xbox commercial game) a volunteer will certainly appear sooner or latter.

I would rather have support for compressed textures, and animation fixes for collada exporter, collada 1.5 fully implemented and working would be dreamy, including collada physics and we really should discuss the need to introduce collada fx instead of the proprietary .shader model that we currently use.

If we are going to start adding rendering solutions that use totally different shaders, we really should discuss the need for an abstract model like ogre or irrlicht materials, adding a few more tags to our .shader files is not hard, but perhaps we should think about a better design?! (Even though shader and asset creation is not a part of the core engine, it is essential for it's use.)

I guess it is sooner

Personally i would like to have 4 build options... Build Debug OpenGL, Build Release OpelGL, Build Debug D3D9, Build Release D3D9. We should be able to query via command line or overlay debug information the renderer used and the mode it is being used.

I see many matrix transpositions in your future lol, there are allot of differences to make this task that should be trivial, complicated, but since the Brits and Americans still use the English Measurement system instead of the International Metric System, it is no wonder that these two APIs use different coordinate systems making things all that much fun... anyway, i hope you use the public svn server, so we can follow the development as a learning experience.