The title says it all.
I added a static vector3f which just gets its values altered for each call of setTransform() or setRotation() or whatever, to limit garbage.
Nobody sees potential bug, I hope ? (References problems, e.g.)
[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:28264"]
The title says it all.
I added a static vector3f which just gets its values altered for each call of setTransform() or setRotation() or whatever, to limit garbage.
Nobody sees potential bug, I hope ? (References problems, e.g.)
[/quote]
Can’t see why this should fail in any way.
Unless somebody is doing wierd threaded stuff this should be safe.
Anyway, Xith3D is meant to be single-threaded.
[quote="<MagicSpark.org [ BlueSky ]>,post:4,topic:28264"]
Anyway, Xith3D is meant to be single-threaded.
[/quote]
Ah, now I see what you mean. And it actually could be a problem. Maybe you won’t see an errorous effect in any case. But it should be safer to schedule it. If it isn’t a performace issue, this should be no problem.
It is a performance issue, and people aren’t supposed to call Xith methods from different threads. I can maybe add some synchronized{} blocks to make sure some nasty things actually don’t happen but… I don’t think it’s really necessary.
I’ve done it in my private version of Xith, and IIRC there was a problem with a nested method call (I might be wrong : it was a year ago), otherwise as said, in a single threaded application it shouldn’t cause any problem.
Lilian 
Xith3D isn’t designed to be multi-threaded, so unless you are changing that I would not worry at all.
Anyone using Xith3d will have to keep all of their Xith3D calls in the one thread.
Reducing garbage is essential. C++ console games are designed so that there is NO garbage created during the game loop and there’s no reason why this can’t be done in Java, or at least minimised (stack-local objects in future versions of Java should help with this goal).
Cheers,
Will