One thing that Jogl needs is a high resolution timer. Is there one available? If not, I think one needs to be added.
There’s J3DTimer in Java 3D, but it seems a shame to have to include all of j3d just to get access to the timer class
One thing that Jogl needs is a high resolution timer. Is there one available? If not, I think one needs to be added.
There’s J3DTimer in Java 3D, but it seems a shame to have to include all of j3d just to get access to the timer class
There are a selection of high resolution timers available as seperate libraries. The first that jumps to mind is GAGE, at:
Adding another probably isn’t a good idea. There’s also a hidden one in Java, but you’ll ahve to search the forums to find a reference to that. Maybe they’ll make it public in 1.5?
Kev
[quote]There are a selection of high resolution timers available as seperate libraries. The first that jumps to mind is GAGE, at:
Adding another probably isn’t a good idea. There’s also a hidden one in Java, but you’ll ahve to search the forums to find a reference to that. Maybe they’ll make it public in 1.5?
Kev
[/quote]
It would be nice to have one that is guaranteed available and portable. Being in a third party package may fail on both those counts.
In addition, high resolution timing is essential to 3d rendering, so I think it’s pretty core to Jogl’s aims (perhaps it could go in the util package instead?)
The GAGE timer is guaranteed available, in that you can download it now and it will always be available to you. Its also as portable as JOGL, in that it works on the standard gaming OSes.
High resolution timing is essential to many things, putting it in every API that its essential to would create a maintainence nightmare.
Why implement yet another timer for the sake of it?
Kev
[quote]The GAGE timer is guaranteed available, in that you can download it now and it will always be available to you. Its also as portable as JOGL, in that it works on the standard gaming OSes.
High resolution timing is essential to many things, putting it in every API that its essential to would create a maintainence nightmare.
Why implement yet another timer for the sake of it?
Kev
[/quote]
GAGE is not guaranteed always available - the project could cease to be supported.
Additionally, if I distribute a Jogl application currently, I only need ensure that the user has Jogl installed - adding GAGE to the user instalation just to get a timer class is onerous.
Why implement a timer? Because it is a core feature of any 3d engine. It seems to me like the utils package is an obvious place for such a class.
How high res do you want? A high res timer under windows is all of 15 lines of code, and all other OSes provide millisecond precision via currentTimeMillis(). Are you looking for better than that?
Gage’s timer is offered in a seperate, and very small, package. Including it right within your application is pretty simple.
The only real solution to this is a high res timer as part of the core Java api, where it really belongs. Hopefully 1.5 will make this a reality. In the mean time I don’t see an advantage to adding yet another timer to jogl.
Class demos.util.SystemTime in the JoGL demos package performs smoothing internally to avoid effects of poor granularity of currentTimeMillis on Windows platform in particular.
You may be interested to give it a try…