I hate to complain as I think Irrlicht is a really nice, well designed and easily understood rendering engine.
However... is there really a need for these in a lot of the cases as virtual functions can be very slow on some hardware and/or compiler and creator functions that hide the implementation destroy the ability to derive from them anyway so I fail to see the point.
We're thinking of basically stripping all this out of our game for performance before release however it's a bit of an unknown (incase something was missed) and from that point on we really wouldn't be able to use later versions of irrlicht which isn't good either.
Virtual functions and creator functions in scene manager
A virtual function is in most cases just minimal(!) slower than another function call. And I don't think it's even used in any functions where it really matters. The rule for all optimizations is - measure first and then optimize. Never optimize before you did measure stuff - you will optimize the wrong parts no matter how sure you are that you are guessing right. Doing such a micro-optimization is nothing but work and very likely you won't get a single frame more speed out of this. Invest the time in finding concrete bottlenecks (with profiling and with timing functions) and optimize those and you can improve your speed way more (for example try other settings for your octree - that makes several frames difference in one of my games - that's far beyond anything a micro-optimization will get you).
Also virtual functions are used a lot in Irrlicht. It simply won't work anymore correct if you remove them. Also you still can derive from the interfaces and add own classes to Irrlicht - which you couldn't otherwise. Doing OO-programming without virtual functions is basically impossible (other languages don't even support non-virtual functions).
Also virtual functions are used a lot in Irrlicht. It simply won't work anymore correct if you remove them. Also you still can derive from the interfaces and add own classes to Irrlicht - which you couldn't otherwise. Doing OO-programming without virtual functions is basically impossible (other languages don't even support non-virtual functions).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Most everything in Irrlicht is hidden behind an interface. This allows the implementation to vary without affecting the interface (i.e., a reference or pointer to ITexture can refer to a COpenGLTexture). This is necessary in some places to support different rendering libraries (opengl, d3d, software) or windowing systems (windows, xwindows...). In some places, it is not necessary, but the pattern is still used.
I'm interested to know how you figured out how much time is spent doing virtual function dispatches. I mean there would be no reason to eliminate them if you didn't know they were the actual bottleneck, right?
Travis
I'm interested to know how you figured out how much time is spent doing virtual function dispatches. I mean there would be no reason to eliminate them if you didn't know they were the actual bottleneck, right?
Travis
It totally depends on the hardware. On the iPhone we've done the tests and removed much of them to test and profile, didn't take long.
We where finding a 20% speedup or so however due to the fact the the vertext format and number of draw calls are also sub optimal (no batching) resulting in cpu waiting it might not neccessarily be that bad. Until we get that sorted I won't be able to tell you a definite figure. Basically it's the cache misses that kill you with virtuals plus the inabilty to inline them.
It's understandable, irrlicht was written for the PC and has a very OO design however this way isn't neccessarily the best for consoles/phones etc and there's no reason why a lot of the interface is pure virtual.
It's just a bit of a shame as I'm aware of all the issues removing them and therefore it's the last thing we'll do, if we need to do it we will otherwise we'll leave it but if we do it I'll effectively have to branch irrlicht at that point.
And yea I'm not saying all virtual funtions need to be removed but something like setPosition?
Currently stuff like this is virtual and therefore can't be inlined either so we get a double whammy.
Anyway, it is what it is and I suppose the irrlicht way is to hide everthing behind an abstract interface and there's plenty of reasons to do this too.
We where finding a 20% speedup or so however due to the fact the the vertext format and number of draw calls are also sub optimal (no batching) resulting in cpu waiting it might not neccessarily be that bad. Until we get that sorted I won't be able to tell you a definite figure. Basically it's the cache misses that kill you with virtuals plus the inabilty to inline them.
It's understandable, irrlicht was written for the PC and has a very OO design however this way isn't neccessarily the best for consoles/phones etc and there's no reason why a lot of the interface is pure virtual.
It's just a bit of a shame as I'm aware of all the issues removing them and therefore it's the last thing we'll do, if we need to do it we will otherwise we'll leave it but if we do it I'll effectively have to branch irrlicht at that point.
And yea I'm not saying all virtual funtions need to be removed but something like setPosition?
Currently stuff like this is virtual and therefore can't be inlined either so we get a double whammy.
Anyway, it is what it is and I suppose the irrlicht way is to hide everthing behind an abstract interface and there's plenty of reasons to do this too.
I understand what you mean because setPosition sounds as obvious as setting a vector2d parameter, or 2 integers or floats.Adversus wrote:And yea I'm not saying all virtual funtions need to be removed but something like setPosition?
But when dealing with inheritance you need to keep an open mind. If you are talking about a class that has a standard to meet such as a dimension2d or array then you can inline functions or make them non-virtual. When dealing with classes in general you have to consider that when setting the position you might also need to check if the object is out of bounds or something like that. It depends on the flexibility of the interface description.
From what I understand, you can inline virtual functions. I do with Visual Studio and it compiles, but I don't know which functions end up in-lined. You also need to set the project settings appropriately.Adversus wrote:Currently stuff like this is virtual and therefore can't be inlined either so we get a double whammy.
I can hear birds chirping
I live in the Eye of Insanity.
I live in the Eye of Insanity.
It doesn't matter if you inline or not, it's only a recommendation. Your compiler has ALWAYS the last word on whether to inline or not. A virtual function might not be compiled as such in some very rare and specific cases and thus could be inlined, but that's a far shot and it still would mean your compiler made sure that that virtual function was not virtual in those case, at which point you have to wonder if you use it well or not. It can happen if some time you use an object rather than a pointer and such too, but again...