hi
Does anyone actually use com.xith3d.scenegraph.TimerInterface or com.xith3d.timing.JavaTimer? As far as I have seen everyone uses the System.currentTimeMillis() function (or maybe nanoTime). So this class and interface seems useless. I would like to delete them. Is this ok for everyone?
At least we should refactor them to com.xith3d.utility.timing.
Marvin
I use “System.currentTimeMillis()” only, so first of all - I don’t mind, and secondly I never know “com.xith3d.timing.JavaTimer” exists. If enybody can explain me it’s purpose/benefits - I’ll appreciate it, really.
Bohdan.
Well, I could guess a reason. If we used the JavaTimer class in the project internally and one time we wanted to switch to nanoTime to have more precise loops, we just needed to change this one class.
But since we actually don’t use it at all, this reason is not very good. And the calls for currentTimeMillis() or nanoTime() are not very many.
it should be kept for java3d compability reasons … even if it’s just a wrapper to System.nanoTime
Is it renderer dependent? - since in the LWJGL implementation it could use their timer function which is reported to be more reliably 1ms accurate than the native java version (in 1.5).
Kev
I couldn’t find it in Java3D. And actually it is a wrapper for System.currentTimeMillis() at the moment.
At the moment, I’m looking through the Java3D API docu, and finding it is not very comatible to Xith3D. Mostly it is, but in a lot of things it is not.
No, it isn’t. And I recently found out, that it is used in the project in the View class. But it can be easily deleted, because it is only used in one call.
Actually it is in version 1.4!
Since nobody seems to use this class, but something like it exists in Java3D in a utils package, I refactored the class and interface to com.xith3d.utility.timing. I hope this is ok for everybody.
Marvin
At one point the System.getCurrentMilis() has a resolution of 55 ms on the PC, which is why most people bind to the hi-res timer to get the time to pass into each frame render. Because java did not support a better timer we added the interface so people could plug-in the JNDI binding to the PC multi-media hires timer, but felt that the implementation should not be added to the codebase.
If System.getCurrentMillis is still at a 55 ms resolution then it is no good for 3d interpolation.
It is not anymore. The resolution is one ms now. So it is absolutely suffiocient for 3D interpolation, as I think.
Wrong, it’s system dependant, and still above 20ms on windows 98/Me, at least the last I checked.
I don’t use this timer myself : I’ve developped a pluggable timer which uses nanotime when possible, and smoothes currentTimeMillis on multiple frames when not possible
(useful for unsigned applets that can’t rely on JNI calls).
Lilian
getCurrentMillis uses getticks, which has an OS dependant resolution.
-win9x 50-55msec
-win2k/xp/etc 10msec
-linux 1msec
-mac 1msec
nanoTime uses queryperformancecounter, which is somewhat flaky on some systems. Mine for example shows the so called “qpc leaping” behaviour, which basically means that it jumps a few seconds into the future whenever it feels like doing so (under heavy busload… eg games).
LWJGL’s timer uses timegettime with 1msec resolution (there is some extra call required for changing the resolution to that) on windows and just getCurrentMillis under linux/mac, because thats already with 1msec resolution.
LWJGL’s one is imo the best choice. 1msec res is accurate enough for games (see all quake engine based games for example) and its also very robust.
If System.getCurrentMillis is still at a 55 ms resolution then it is no good for 3d interpolation.
Well, you can cheat a bit, but thats very fiddly and it needs some time to adapt… and there are over/understeer effects etc. The adaptive yield loop throttle thingy (used in fuzetsu) works even fine with a resolution of 250msec… well, that is as long as the time per frame doesnt fluctuate too much.
Can’t we adept this method. LWJGL is Open Source, isn’t it? So we should be able to copy the code. So we could paste it into the JavaTimer class.
Could you do it, oNyx?
(didn’t read the entire discussion)
I guess you should keep it because :
Hey hey hey hey no way. First if I understood a bit LWJGL use native thingies for timing, heh ? Then copying code is just ugly (you have to track changes in the original version and synchronize manually accordingly).
It’s not the way to go IMHO. Well we have a timer interface, heh ? So just implement an LWJGLTimer class extending Timer.
[quote="<MagicSpark.org [ BlueSky ]>,post:14,topic:27961"]
Well we have a timer interface, heh ? So just implement an LWJGLTimer class extending Timer.
[/quote]
Wouldn’t this be a dependancy at the wrong place?
Wouldn’t this be a dependancy at the wrong place?
[/quote]
Well the problem is : we should have three jars instead of the one we have currently. We should have xith3d.jar xith3d-lwjgl.jar xith3d-jsr231.jar. So dependecies issues are resolved.
[quote="<MagicSpark.org [ BlueSky ]>,post:16,topic:27961"]
Well the problem is : we should have three jars instead of the one we have currently. We should have xith3d.jar xith3d-lwjgl.jar xith3d-jsr231.jar. So dependecies issues are resolved.
[/quote]
Yes, this sounds good.