[Deprecated feature] IVideoDriver + Texture Matrices

[Nadro]

In this topic I would like to share my ideas about features which should be removed in next Irrlicht versions. If you have other propositions please share them in this topic.

My first proposal is texture matrix support in IVideoDriver::(set/get)Transform method. At now user has access to texture matrices via IVideoDriver::getTransform and MyMaterial.TextureLayer[x].getTextureMatrix() calls. I see two disadvantages of that:
- code is more bloated
- lower performance due to copy matrices
Of course a fixed texture transform size (ETS_TEXTURE_x) will cause some problems in near future with maintenance of this stuff, when we'll solve a problem with low value of MATERIAL_MAX_TEXTURES.

Thats why I think we should remove the texture matrix support from IVideoDriver interfaces.

[hendu]

There are users of that feature. Probably in the less experienced end too, so they'd have to learn shaders to pass custom matrices -> angry users.

edit: I propose the fast_math and burnings to be nuked.

[kklouzal]

I propose that everyone stop worrying about 'application breaking changes'

A user will either update Irrlicht and edit their code.
Or they will not update Irrlicht and keep their code as is, being that Irrlicht is open-source if there is something they seriously need fixed they can fix it themselves.

Abstaining from making 'application breaking changes' only hinders progress of the library and bloats its code base.
If at the least, make it know that every major version increase there will be app breaking changes.

AFAIK nobody makes their living off an app they've made with Irrlicht. I don't see what all the fuss is about. Unless, of course, it's an excuse for the developers to stay lazy.

[Nadro]

We'll not force users to use a shaders in case of custom matrices. Instead of call glLoadMatrixf inside a setTransform method we can call this function inside eg. setBasicRenderStates method. Funcionality we'll be the same as before, just access for texture matrices by (set/get)Transform methods will be removed.

Personally I don't have a problems with changing API too, but many users really don't like it. Irrlicht is designed for fixed pipeline thats why in some places we should change API for improve an overall performance and apply the new features.

+1 for remove Burning's (lack of developers for this driver) and fast-math.

[CuteAlien]

@kklouzal: The main point of a library is to offer a stable interface, this matters a lot.
And there are companies making their living with Irrlicht apps (I've worked for some and I also make my own living mostly by coding Irrlicht apps). Yeah, this library is actually used in the real world :-)

[kklouzal]

That being said. If it's to increase performance or simplify a procedure then I think, no I know breaking the API should not be a concern. Put yourself in other peoples shoes, sure, you wouldn't want to have to change some code, but all that has to be put fourth is a little time, and the benefit is increased performance? Why would anyone in their right mind detest such a thing.

[CuteAlien]

The reason is that real projects don't use one library but usually at least half a dozen. And if libraries are not keeping a stable interface then you are constantly either working with outdated libs - which is not even possible in some situations (linux distributions...) or you have to rewrite your applications constantly (get's harder the more apps you maintain...).

Still I agree somewhat - but that depends on the optimization. Half the optimizations you code tend to make no noticeable difference in games. So you often get 40.1 FPS instead 40 FPS or similar... great (I just did spend my last 2 days on 2 of those *sigh*). If you break an interface it should be a real gain.

edit: Btw. I'm neutral about the change proposed in this thread.

[Cube_]

[/quote]edit: I propose the fast_math and burnings to be nuked.[/quote]
I don't see why, burnings is better than the generic software renderer speed-wise and is at least to some level quasi-feasible for usage (not quite but almost), I've never compiled irrlicht with fast_math so I can't tell but I've been toying with the idea (questions that come to mind when considering it: does it have a tangible speed increase? What sort of precision loss is there?)
just my 2 cents.

[hendu]

fast_math is not only less precise and slower than standard linux functions nowadays, cutealien found it's also buggy. Even if it's still faster than mobile or Windows functions, getting buggy results is unacceptable.

Burnings is a lot of complex code and unmaintained.

[Cube_]

Fair enough, fast_math has a valid reason of being deprecated then but even if burnings is unmaintained as long as it doesn't become incompatible I see no reason to remove it, I'd perhaps add a flag to compile it without burnings (for those concerned about space, actually I'd do that for everything nonessential, I wouldn't mind compiling irrlicht without the d3d code and the software renderers (and perhaps other nonessentials) to shrink the generated shared object file)

[mongoose7]

You do know that the software renderer has alignment problems? If alignment is an issue (and I thought it was with ARM), it would be better to keep Burning's and ditch the software renderer.

But neither of them support shaders, so they will not benefit from the ongoing changes to the engine, so why not ditch them both and advise anyone wanting a software renderer to download 1.8. They will never be worse on 8.1 than they are today, but they will require the support of legacy code in the future, and this would not be a good project choice. They will never be better than they are today.

[CuteAlien]

*sigh* I wish this wouldn't be a thread about general discussing anything anyone wants to deprecate. Making one thread per feature is better, because now the discussion about IVideoDriver::(set/get)Transform ETS_TEXTURE_x is getting drowned.

Both software renderers simply stay in because they have not caused troubles so far and they do what they are supposed to do (the first one is about offering a way to display a GUI without having to start a 3d device and burnings is about offering software rendering). As long as the vertex format doesn't change they will just continue working. Once we change that - well, then we probably have no choice but to kick them (but once we do that we have basically a new engine anyway).

[Granyte]

fast_math is not only less precise and slower than standard linux functions nowadays, cutealien found it's also buggy. Even if it's still faster than mobile or Windows functions, getting buggy results is unacceptable.

Burnings is a lot of complex code and unmaintained.

I don`t know about mobile but I'm pretty sure it's not faster then windows standard functions anymore

and from what I saw it is a mess that no one can really maintain since the dev that wrote the original code does not seem to be around anymore and no one understands is enough to make it work
that alone should be a reason to get rid of it

[CuteAlien]

Thomas (burnings developer) is still around and asked me about some troubles he had with svn and Irrlicht recently. So maybe he will contribute again some time.

[Nadro]

It looks like this feature may be removed, I don't see any opponents for this idea. I'll apply this change into engine soon.

BTW. I changed topic name, because it looks like CuteAlien is right and one global topic for deprecated features is bad solution.