virtual void animateNode (ISceneNode *node, u32 timeMs)

[clarks]

Code: Select all

virtual void animateNode (ISceneNode *node, u32 timeMs)

Design wise, I do not understand why the time is being passed in this fashion. I believe that irrlicht should pass the elapsed time. However, irrlicht just passes the time from os::TImer::getTime(). Yes the elapsed time can be calculated inside of the animateNode function, but if there are hundreds of nodes being animated it would just be the same calculation over and over again. The general use case is that someone would need to know the elapsed time. So why wasn't it designed that way instead.

Please elaborate.

[chronologicaldot]

You may have a separate clock for animating your node that is independent of the real clock. With a separate clock, you might even go BACK in time, which would be a negative change. Note, however, that time is given as a u32, which is never negative, so unless you're going to cast u32 to s32 or s64 every time, you might as well perform a subtraction calculation.

That's my take on it at least.

Edit: Also, in some cases (for some models, I mean), their positions might be calculated from a set start time as opposed to being calculated from the last stance (where change in time would be convenient to use).

[clarks]

I understand where you are coming from, but I believe that the general use case would make the most sense.

[hybrid]

Well, don't really know if this or that is the more common case. IMHO, getting the full elapsed time is the more general case and should cover the requirements more naturally. But such a discussion is pretty useless, as we're stuck with this API now. Changing such an interpretation of a value is pretty much the worst that can happen to a long standing API. But in case you can profile a real bottleneck from this behavior , we might consider some counter measures.

[clarks]

But in case you can profile a real bottleneck from this behavior

I dont think I would be able to do that. However, this gets me thinking about the future of irrlicht. At some point in time, I believe that irrlicht will have to make a break from its current API. Change is good.

[hybrid]

No, change is only good where necessary. And since I doubt that you'd really notice this calculation anywhere in any reasonable application, it's simply inappropriate here.

[clarks]

No, change is only good where necessary.

Not exactly. Change can also be good if someone has a different vision, but not exactly necessary.

And since I doubt that you'd really notice this calculation anywhere in any reasonable application, it's simply inappropriate here.

I just said that I do not think I would be able to do that. If you're words were not meant to be harsh then forget the rest of this comment. Else, what is your hard feelings about? It's simply a discussion .

[hybrid]

I said that this optimization (which your original post was about) won't be really noticeable. There will be no speedup with this change, because there are far more demanding calculations going on. Even with thousand of animators around. So breaking with thousand of existing apps and forcing all Irrlicht users to change their code is far worse. There's simply no measurable benefit