How many people would be....

[Guest]

why not do irrlichtOpenGL and irrlichtX

When you get to this point, you might just as well do like the IrrlichtNX guys did and call the modified engine something else. Their "version" of Irrlicht became IrrlichtNX and now it's evolved to the point where it bears little resemblance to the original and it's been renamed again. Lightfeather I believe. The codebase has changed enough that a person would be hard pressed to use their Irrlicht programming knowledge in working with Lightfeather.

So where's the benefit? YAPA (Yet Another Programmming API? )A greater dependancy on the MS libs that drive it? Potentially more difficulties in deploying your game because the end user needs to have a particular set of dlls and may be forced to upgrade if they don't? "Shutting out" a market segment for your game that can't run it because they have older hardware and can't upgrade? Just to have more "cool" features?

BTW, the MS DX SDK is a nightmare to use, IMO. (I do have some good books on the subject...)

There are a lot of factors to consider in making a choice like developing for a single platform with a singular rendering API...

However, it's Spintz' call...

[Spintz]

I've been thinking about it, and a lot of people want OpenGL, but there's things I can do in DirectX which I have no idea how to do in OpenGL. I'm going to leave OpenGL in, I'm not going to update DirectX8 however, as the things I'm doing with DirectX9, I have no idea if they're supported in DirectX8. I'll look into it where I can. I'll get it so OpenGL runs a little better in general, and try and fix the transparency problems, etc.

However, my main goal is to add some cool features to the engine for my own purposes, and I enjoy sharing them with the community. One versions of IrrSpintz are released, if features are in DirectX that aren't in OpenGL or possibly DirectX8, there's no reason why someone else who wants the features in DX8 or OpenGL can't implement them myself. I'd be happy to include the changes someone else makes to them, as I could worry less about it and do what I know with DirectX9.

[bitplane]

I'm afraid I voted with the majority, the main reason for this is more work for you equals less work for Niko equals a better chance of getting your changes merged back in to the main source. Yeah baby, immortality, thats what I'm talkin about.
I wish I knew OGL so I could help out!

[Spintz]

So go learn it, otherwise I have to!!!

[Guest]

Two questions occured to me on the way to work:

1. Would IrrSpintz be merged with the Irrlicht development tree and pass along the new or optimized features?
2. Would users be able to select new features programmatically and still retain some "backward" compatibiity?

I guess I just don't want to have to make a choice between the two Irrlicht versions when it come down to it. Both are very good, and both have strengths and features that are desireable.

Thx.

[Spintz]

That's up to Niko, and I believe he is looking at IrrSpintz. He mentioned it on his blog when talking about the Open Source Diff Tools. There are features he doesn't take, like the 32 bit indices for example. However, the reason for that may be that you should be able to have a vertexBuffer with 16 or 32 bit indices. I haven't even released this new stuff, with 8 texture support and all these new materials for texture-splatting, reason being, in the current condition, I can't get OpenGL to work. That's why I'm debating all this OpenGL/DirectX stuff, because maybe I release it, and then Niko looks at it and can fix it. Or maybe anyone else who downloads it can play with it.

I believe that's the path I'm going to take. I'll keep trying with OpenGL, but others are much better at OpenGL than I. I'll implement features in DX and see what I can do about getting them to work with OpenGL.

I really started all this by modifying Irrlicht for my own personal needs. Lots of people wanted the features and so I released IrrSpintz, thinking it would be easier to just take the engine as a whole instead of applying tons of patches/changes to the code. It's turned into more, where I'm learning more and more about 3D and cool features in 3D, and unfortunately, in order to support some of those features, I have to drastically change the engine.

Enough rambling. I'll leave OpenGL into IrrSpintz, but if I get dead stuck on certain things, that I can't implement, I'll do it so OpenGL will still work without those features, and if you really want them in OpenGL, you'll have to implement them yourself. But at least you'll have the engine framework setup to do it, and examples of how it works in DirectX to go off of.

[Spintz]

And I just fixed my last DX bug in the new EMT_BASE_1ALPHA, EMT_BASE_2ALPHA and EMT_BASE_3ALPHA materials !!!!!

Broken - ( notice how the terrain was translucent )


Fixed - ( not translucent anymore )

[pfo]

Don't drop support for the older APIs, not everyone can support them. I do realise that only supporting DirectX9 and / or OpenGL may lead to faster development / release time, but if you cut out support, many people might not see the benefits of it (I.E. not being able to use the software). I agree that DirectX9 is the target standard (for DirectX anyways), maybe development of new features should focus primarily on DirectX 9 and DirectX 8 support should be added for them after they work in 9.