Rarkon
Senior Newbie 
Oh god the universe is collapsing on me!!!
|
 |
«
Posted
2004-03-22 19:34:28 » |
|
I'm trying to get my game to render properly without refresh line. But the redering code I've come across all seem to need getTimeInMillis. So my question is how do you use getTimeInMillis, or if you know of a way to render without getTime please tell me. Thank you.
p.s. sorry if this was asked I'm new and I couldn't find it using search.
|
|
|
|
dreamweaver
Junior Newbie
Java games rock!
|
 |
«
Reply #1 - Posted
2004-03-23 02:11:15 » |
|
I'm newbee too . Really don't understand clearly but Java has System.getCurrentTimeMillis() if you need.
|
|
|
|
Jeff
|
 |
«
Reply #2 - Posted
2004-03-30 20:11:29 » |
|
True though its accuracy is bad under Win98
Most game use GAGE totday. You can google for it.
JDK1.5 has the nanosecond timer which is gauranteed to have a good accuracy.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
jbanes
|
 |
«
Reply #3 - Posted
2004-04-01 14:25:44 » |
|
True though its accuracy is bad under Win98
Most game use GAGE totday. You can google for it.
JDK1.5 has the nanosecond timer which is gauranteed to have a good accuracy.
Ack! Poor guy! He'll be trying to figure out what N-GAGE has to do with anything. The GAGETimer API can be found at http://java.dnsalias.com
|
|
|
|
Jeff
|
 |
«
Reply #4 - Posted
2004-04-01 16:04:12 » |
|
Thanks JB.
jk
|
|
|
|
D.t.O
Junior Devvie  
Psych'd about Java Games
|
 |
«
Reply #5 - Posted
2004-04-02 16:46:37 » |
|
http://java.dnsalias.com: GAGETimer has been updated to support the Java 1.5 System.nanoTime() method. The nanotimer is the default timer under 1.5 VMs. Previous Java versions will continue to use System.currentTimeMillis() or the native Windows timer. Is the "native Windows timer" more accurate than the Java currentTimeMillis() timer? I thought currentTimeMillis() was native..
|
Enjoy. Regards, - D.t.O
|
|
|
jbanes
|
 |
«
Reply #6 - Posted
2004-04-02 18:07:43 » |
|
The currentTimeMillis() timer only ticks 20-100 times per second on Windows. This is far too slow for a high performance game. Thus I added a DLL to GAGETimer that allowed it to access the Windows Hi-res timer which ticks ~30,000 times per second. This is what most people have been using. 1.5 has added a new timer (nanotimer) that ticks some ungodly number of times per second. This is now the default if you're using 1.5. 
|
|
|
|
Jeff
|
 |
«
Reply #7 - Posted
2004-04-04 20:45:53 » |
|
http://java.dnsalias.com: Is the "native Windows timer" more accurate than the Java currentTimeMillis() timer? I thought currentTimeMillis() was native.. There are multiple tiemrs under Win32. currentTimeMillis uses the standard system timer, its accuracy is bad (under NT) to horrible (under 98). There is another timer called the multimedia timer but there are Win32 performance reasons why the standard currentTimeMillis() doesn't use it. If you are under 1.5 use the nanosecond timer. Otherwise use GAGE 
|
|
|
|
endolf
|
 |
«
Reply #8 - Posted
2004-04-05 06:35:06 » |
|
But don't use it on a game server  , client side fine, but not on the server, ~60% CPU usage v.s. 0.1%  No idea why, but that was the only change  Endolf
|
|
|
|
Jeff
|
 |
«
Reply #9 - Posted
2004-04-05 06:47:54 » |
|
Whelp i did say there were performance reasons for using the lower accuracy timer under Win32 .
Otehrwise they wouldve just changed the timer's implementation instead of creating a whole new entry point.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
endolf
|
 |
«
Reply #10 - Posted
2004-04-05 07:35:48 » |
|
That was under linux, so that probably makes a huge difference, as I'm not sure how gage handles linux
|
|
|
|
jbanes
|
 |
«
Reply #11 - Posted
2004-04-05 15:31:42 » |
|
That was under linux, so that probably makes a huge difference, as I'm not sure how gage handles linux Depends on how you use it. GAGE is built to be the most accurate and precise timer for games possible with current Java technology. If you're going to use it for a game server, make sure you don't use the sleep methods! These methods are designed to spin on sleep, and will degrade the performance of a multithreaded server environment. If you just want to know the current time, GAGE should still work fine. What were you using it for on your server?
|
|
|
|
D.t.O
Junior Devvie  
Psych'd about Java Games
|
 |
«
Reply #12 - Posted
2004-04-05 16:27:52 » |
|
...make sure you don't use the sleep methods! These methods are designed to spin on sleep, and will degrade the performance of a multithreaded server environment. What does it mean for a method to "spin on" sleep (or any other method)  This may seem obvious to most, so sorry  ... keep in mind I'm a newbie.
|
Enjoy. Regards, - D.t.O
|
|
|
endolf
|
 |
«
Reply #13 - Posted
2004-04-05 17:48:08 » |
|
What were you using it for on your server?
I'm just the BOFH in this case, but I think it was a sleepUntil. Endolf
|
|
|
|
kevglass
|
 |
«
Reply #14 - Posted
2004-04-05 18:35:06 » |
|
Guess, I'll have to own up.. it was the MA server and it was indeed using sleepUntil. I had assumed on linux that it would just use a Thread.sleep(), hence my mistake. Spinning on the sleep means that it constantly loops round on a very small pause, using up lots of processor time.. My mistake has been rectified  Kev
|
|
|
|
jbanes
|
 |
«
Reply #15 - Posted
2004-04-05 18:43:45 » |
|
What does it mean for a method to "spin on" sleep (or any other method)  This may seem obvious to most, so sorry  ... keep in mind I'm a newbie. 1 2 3 4
| public void sleepUntil(long time) { while(System.currentTimeMillis() < time) Thread.yield(); } |
By yielding instead of sleeping, the method will return almost to the moment the clock flips over to match the "time" variable. The only problem is that it will use 100% of the CPU to do it. Of course, this isn't a big deal as the method is actually giving up its time to other processes, but anything that the other processes don't use will come right back to that loop. This method is particularly advantageous when dealing with the System.currentTimeMillis() timer. For example, if I'm deploying my game on Windows 2000, System.currentTimeMillis() gives a tick rate of 100 ticks per second. If we use Thread.sleep(), we have no idea how many milliseconds we have until the next tick. This means that the framerate may jump all over the place as we'll have no idea how often we need to sleep, or for how long. But if we latch onto the digital wave generated by the clock, we can always guarantee exactly 10ms to render each frame. Extra time can be slept off by waiting for the next clock tick. Here's a graph to demonstrate: 1 2 3 4 5 6
| -- -- -- |__| |__|
^ ^ ^ ^ | | | | begin rendering |
Make sense?
|
|
|
|
jbanes
|
 |
«
Reply #16 - Posted
2004-04-05 18:45:55 » |
|
Guess, I'll have to own up.. it was the MA server and it was indeed using sleepUntil. I had assumed on linux that it would just use a Thread.sleep(), hence my mistake. ... My mistake has been rectified  All's well that ends well, right? 
|
|
|
|
|