In case you haven’t seen this:
http://java.sun.com/j2se/1.5.0/
Release notes:
http://java.sun.com/j2se/1.5.0/relnotes.html
Some info on the new features:
http://java.sun.com/developer/technicalArticles/releases/j2se15/
[quote]Linux and Solaris users who have the latest OpenGL drivers and select graphic cards can get native hardware acceleration from Java2D using the following runtime property:
java -Dsun.java2d.opengl=true -jar Java2D.
[/quote]
Thats interesting. Then again I am having trouble understanding most of the other features :’(
Also http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html
The 2D features like accelerated translucency (although still has to be enabled with runtime, for now) and the Bufferedimage stuff is cool
What about the hi res Java Timer? Did they make the Perf thing standard, or added something else? How do I access it?
[quote]What about the hi res Java Timer?
[/quote]
java.lang.System.nanoTime()
[quote] The transparency value is TRANSLUCENT and translucency acceleration has been specifically enabled at runtime (sun.java2d.translaccel=true).
[/quote]
How exactly do you enable something at run-time? where does the line of code go?
You just have to set a System property,
you can do it either on the cmdline
-Dsun.java2d.translaccel=true
or through code
System.setProperty("sun.java2d.translaccel","true");
And if you do it through code, make sure it’s the very first thing you do, i.e. before displaying anything that might use Java2D. I tend to forget that little tidbit on a regular basis.
I was wondering are their any other methods concerning the timer besides getNanoTime()? What if I wish to know the ticks per sec? Is there a way of getting them without having to write a method for it? Also is their any benefit (besides the pure java implementation) of the Java timer over the GAGE timer?
With the getNanoTime() solution you stick to a standard and here you have nona second accuracy so you should have all the precision your game needs.
[quote]With the getNanoTime() solution you stick to a standard and here you have nona second accuracy so you should have all the precision your game needs.
[/quote]
No, you don’t have nano second accuracy. You have whatever accuracy the OS supports translated into nano-seconds. i.e. Under Windows NT, the System.currentTimeMilis() clock updates every 10ms. The nano-clock may work in a similar fashion by only updating ever few hundred nano-seconds.
As to GAGETimer, I plan to update that to use the 1.5 timer as soon as I get a chance. That way, you’ll have code that works on 1.4 and 1.5, plus a standard set of methods to make dealing with time and sleeping easier. (Without clock drift!)
getNanoTime() is guaranteed to be the finest timer you can get on the platform. So, yes, it will be the best you can do.
So what would be the proper way of using the nanoTime() method? How would I get the ticks per second? Or the gametick time? or should a different approach be used?
Amazingly getNanoTime() isn’t actually as useful as the LWJGL hires timer which has been around for, ohh, three years is it? I wish we were consulted a little more sometimes. Still, it gives us something to do working around it 
Cas
[quote]So what would be the proper way of using the nanoTime() method? How would I get the ticks per second? Or the gametick time? or should a different approach be used?
[/quote]
You would use it in the same way as currentTimeMillis(). Hopefully the resolution will be good enough on all systems and that there will be no need to compensate.
You can get the ticks per second in the same way as with currentTimeMillis(). Sit in a loop until the value returned changed. The delta gives you an indication of the resolution of the timer. Although I don’t see the need for this information except to check that the resolution is good enough. But then again, I don’t use an advanced game loop.
What is the gametick time and what do you use it for?
It is the time alloted for one gametick. If I wish to do 30 game updates a second then gametick = ticks_per_sec / 30. I was thinking about his on the train this morning: if it’s a nanotimer then wouldn’t the resolution be 10^-9 ticks / sec? So then at 30 gameticks per sec one gametick would be = (10^-9 / 30) ?
I am thinking I should stick with the GAGE Timer (since I just got my loop to work well with it) and just use the updated 1.5 GAGE when Jbanes writes it.
[quote] So then at 30 gameticks per sec one gametick would be = (10^-9 / 30) ?
[/quote]
Sounds correct. (10^-9/30) nanoseconds is just another way of saying 1/30 seconds.
10^9/30 I think.
Right:
10^-9 is a nanosecond
10^9/30 is one gamtick at 30 gameticks per sec.
And I guess its implied that the resolution is at 10^9 ticks per second. I am still not sure, however, if their are any benefits (besides the obvious pure Java one) of using this over the GAGE Timer. Since on my pc the GAGE resolution is 3,500000 ticks per sec which is also pretty good. Although maybe a higher precision will allow me to deal with lag better?
Assumign GAGE is doing its job right then thsi and GAGE should both have the same accuracy-- which is the bext accuracy to be had on the paltform in question.
The main benefit is that, as thsi is aprt of the JDK1.5 defintion, it will appear on a lsystems that implement JDK1.5. A secondary small value is that you don’t need to destribute a DLL with your app which may simplify your installatio nand/or make it possible to use thsi in security situations where you cannot sue a DLL. (eg Applets)
That may or may not be important to you depending on how you destribute your code and if GAGE is already everywhere you want to go.
[quote]A secondary small value is that you don’t need to destribute a DLL with your app which may simplify your installation
[/quote]
That’s a big value actually (for me).
If you’re using 1.5, GAGE gets the full Nanotimer resolution and does not depend on the DLL. The DLL is only used on 1.4 (in theory, 1.1-1.4) platforms.