Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  problem with currentTimeMillis()  (Read 6763 times)
0 Members and 1 Guest are viewing this topic.
Offline cyberyoyo

Junior Member




Java games funk


« Posted 2005-03-06 00:18:19 »

After reading that a lot of people had problems with java5.0 I decided to redo my 2d engine so that it worked with java 1.4.x.
I had a game loop that used nanoTime() for time synchro and it worked like a charm.
I rewrote my loop, this time using currentTimeMillis() and I just noticed a problem:
the value of currentTimeMillis is not updated regularly.The value isn't changed during 3 iterations and suddenly at the fourth it is increased of 50 units (50 milliseconds).
That makes it practically impossible to achieve a smooth animation in my engine.
Anybody else have encountered this problem? and do you have solutions?
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #1 - Posted 2005-03-06 00:48:54 »

"currentTimeMillis()" is dependent on the operating system clock.

The time it returns is dependent on the OS, it's better on Linux than Windows and it's even worse on Mac.

I suggest you use a C timer through JNI, like the GAGE timer or force your users to upgrade Java. Smiley

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2005-03-06 07:59:16 »

Quote

I suggest you use a C timer through JNI, like the GAGE timer or force your users to upgrade Java. Smiley


I know it was tongue in cheek, but... forcing everyone else to move to java 5 just because Sun's Windows 1.4 JVM has a bug isn't really fair. It's also likely to turn away most people with java (most people don't have java 5 yet, by the looks of things).

GAGE timer has been used by nearly everyone; it's small, it works. Just use it Smiley.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #3 - Posted 2005-03-06 09:38:36 »

GAGE is all you need, no more, no less.

It will even fall back on the sun.misc.perf Timer if its present (Suns VM 1.4.x)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Danskeren

Senior Member


Projects: 1


oi?


« Reply #4 - Posted 2005-03-22 23:00:00 »

How does this GAGE timer work? Do you have to download something to get it or is it built in as default?

Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2005-03-23 05:51:14 »

GAGE Timer is at:

http://java.dnsalias.com

Its a native library for windows that works using a different clock to the System.currentTimeMillis(). It wraps up the nasty work of deciding what you need to do and where.

GAGE Timer is brought to you by the letters A and D, the number 10 and our good friend jbanes.

Kev

Offline cyberyoyo

Junior Member




Java games funk


« Reply #6 - Posted 2005-03-23 20:37:54 »

Quote
GAGE Timer is at:

http://java.dnsalias.com

Its a native library for windows (...)


Yeah that's what I noticed unfortunately, so it doesn't really solve the problems I have and it's not really better than using java1.5 if it's only for Windows.
Offline EgonOlsen
« Reply #7 - Posted 2005-03-23 21:00:50 »

There's also a hires timer in (Sun's) Java 1.4 hidden in sun.misc.Perf. However, it's in an "evil" Sun package...
I've written myself a TimeProvider interface with one method (currentTimeMillis()) and different implementations for misc.Perf, System.currentTimeMillis() and the LWJGL timer. I'm accessing these via a factory class that returns the appropriate timer depending on my needs and on what's available on the current machine. It's not a problem to add two more implementations for GAGE and Java5's nanoTime...
That way, you'll get high precision where available and still have some fallback options.

Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #8 - Posted 2005-03-24 08:08:23 »

Quote
There's also a hires timer in (Sun's) Java 1.4 hidden in sun.misc.Perf. However, it's in an "evil" Sun package...
I've written myself a TimeProvider interface with one method (currentTimeMillis()) and different implementations for misc.Perf, System.currentTimeMillis() and the LWJGL timer. I'm accessing these via a factory class that returns the appropriate timer depending on my needs and on what's available on the current machine. It's not a problem to add two more implementations for GAGE and Java5's nanoTime...
That way, you'll get high precision where available and still have some fallback options.


GAGE already does all of that ^_^

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline luisoft

JGO Coder


Projects: 6


Java games rock!


« Reply #9 - Posted 2005-05-10 11:53:30 »

Hey EgonOlsen, I like your implementation, could u post the source code or send it by email?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #10 - Posted 2005-05-10 17:21:30 »

I was wondering some time ago how good is the LWJGL timer compared to GAGE? I guess the point is if you're already using LWJGL then why would you use another timing API if it works well with LWJGL?

Offline tom
« Reply #11 - Posted 2005-05-10 18:16:46 »

Quote
I was wondering some time ago how good is the LWJGL timer compared to GAGE? I guess the point is if you're already using LWJGL then why would you use another timing API if it works well with LWJGL?

They all used to use the same timer. LWJGL pre 0.96, Gage native dll, nanoTime and sun.misc.Perf all uses the Performance Counter api. It's problem is that it don't work properly on speed-step computers. The speed of the game will fluctuate as the processor frequency is changed.

LWJGL 0.96 uses timeGetTime wich can have 1 ms resolution. But it requires you to use Thread.sleep(1) in your game loop for maximum reliability. And sleep is not accurate in java. Sometimes it will degrade to 10-15ms accurace, making it no better than currentTimeMillis.

So there is no timer that works on all systems on windows Cry There is always a catch. The next step is to detect wich timer works best.

Offline Jeff

JGO Coder




Got any cats?


« Reply #12 - Posted 2005-05-10 20:29:42 »

Quote


I know it was tongue in cheek, but... forcing everyone else to move to java 5 just because Sun's Windows 1.4 JVM has a bug isn't really fair. .


Its not a bug.

It works as designed.

It just is not the right design for game needs.

Your choices for game needs are:

(1) The nanosecond timer in Java5 (IMHo the best choice)
(2) The old Sleep hack (depends  on undocumented behavior of
Sleep and as such is not reliable.)
(3) The Java3D utils timer. (Depedns on a native DLL so only works
on thsoe platforms j3D has been proted to.)
(4) A third party native DLL (same problem as 3).



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2005-05-11 11:21:09 »

The nano timer in 1.5, and in fact in every other bit of code in the rest of the universe that seems to rely on the same underlying code, is now unreliable and broken Sad Not a single game on my new laptop runs correctly - except the ones I've written Sad

Cas Smiley

Offline cyberyoyo

Junior Member




Java games funk


« Reply #14 - Posted 2005-05-11 16:46:45 »

Quote
The nano timer in 1.5, and in fact in every other bit of code in the rest of the universe that seems to rely on the same underlying code, is now unreliable and broken Sad Not a single game on my new laptop runs correctly - except the ones I've written Sad

Cas Smiley


Well in theory, every bit of timing code in the universe will always be faulty at one time or another anyway Cheesy
I changed my 2.6ghz athlon for a 3200+ XP64 and I didn't notice difference on my game that uses nanoTime().
And now that macintoshes have java 5, I think i'll stick with it, well maybe I'll write some redudant code to use misc.perf if the 1.4jvm is detected, that is if I manage to keep the motivation for that Smiley

Offline Jeff

JGO Coder




Got any cats?


« Reply #15 - Posted 2005-05-11 21:30:06 »

Quote
The nano timer in 1.5, and in fact in every other bit of code in the rest of the universe that seems to rely on the same underlying code, is now unreliable and broken Sad Not a single game on my new laptop runs correctly - except the ones I've written Sad

Cas Smiley


Ouch.  What platform is on that? I assume Windows since you are saying every game is broken.

Is this maybe a result of MSFt not handling this "speedstep" stuff right?


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2005-05-11 22:17:01 »

Sad I wish they'd fix it but really it's rather too late now, the cat is out of the bag. TBH I don't even know if they can fix it easily. Might be some strange hardware shenanigans.

Cas Smiley

Offline sunet2000

Senior Newbie




I want my mumart account back!


« Reply #17 - Posted 2005-05-23 00:34:59 »

Just hit this problem on jdk1.5.0, and I'm extremely disappointed.

Thread.sleep( 20 ) now consistently sleeps for 31ms on my Sempron machine. I remember seeing similar behaviour on much earlier JVM versions.

In my opinion this is quite unacceptable for a bug of this magnitude to be present in any JVM release. I fail to see how Java can provide serious competition to .NET as a desktop platform with performance like this.

I very much doubt the IO and networking classes use the exposed  interfaces, as it would likely ruin their performance.

EDIT:

Ok, rant over. I've come up with a nice robust work-around. I long for the days when you could hook your app to the vertical blank ....

I suppose it's an operating-system issue, possibly related to sleeping across schedule-points. I'd guess that other platforms like .NET have the same problems.

Cheers,
Martin


Offline Azeem Jiva

Junior Member




Java VM Engineer, Sun Microsystems


« Reply #18 - Posted 2005-05-23 04:32:34 »

Quote
Just hit this problem on jdk1.5.0, and I'm extremely disappointed.

Thread.sleep( 20 ) now consistently sleeps for 31ms on my Sempron machine. I remember seeing similar behaviour on much earlier JVM versions.

In my opinion this is quite unacceptable for a bug of this magnitude to be present in any JVM release. I fail to see how Java can provide serious competition to .NET as a desktop platform with performance like this.



Is this Windows?  Because Windows does not provide very granular sleep, try the same application under Linux and you should see 20ms sleep times.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #19 - Posted 2005-05-23 08:10:05 »

Why is it that C++ game developers never complain about this problem on windows but it hurts all java developers? Surely this points to it being a problem with java? And wasn't sun.misc.perf considerably better (I've never tried it, so I wouldn't know for sure)?

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2005-05-23 09:44:29 »

C++ developers don't use threads generally; and when they rely on timers they have yet to find out that they don't actually work. Valve, for example, don't know about the problem, as HL2 runs like shite on my laptop.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #21 - Posted 2005-05-23 13:54:09 »

And I suspect a large amount just run tick based and use vsync. Which raises the question - just why can't we get a guranteed v-sync?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2005-05-23 14:28:46 »

Because many shitty graphics chipsets simply don't support it. None of the Intel ones work for example. And of the ones that do, there is a daft setting that actually allows the user to completely override what the program specifies. Duh. And ingeniously there's no API to detect this except on Nvidia.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #23 - Posted 2005-05-23 14:32:14 »

Crappy intel hardware aside (anyone who buys that deserves whatever they get) why on earth aren't ATi at least offering the same as nVidia? Sheer sillyness. Angry

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Jeff

JGO Coder




Got any cats?


« Reply #24 - Posted 2005-05-23 21:18:13 »

Quote

In my opinion this is quite unacceptable for a bug of this magnitude to be present in any JVM release. I fail to see how Java can provide serious competition to .NET as a desktop platform with performance like this.


Just a note, this is not a bug.
Thread.sleep() gives no promise of any particular level of accuracy.

In general its going to be up to the underlying OS.



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Mark Thornton

Senior Member





« Reply #25 - Posted 2005-05-24 07:51:56 »

Quote
Just hit this problem on jdk1.5.0, and I'm extremely disappointed.

Thread.sleep( 20 ) now consistently sleeps for 31ms on my Sempron machine. I remember seeing similar behaviour on much earlier JVM versions.


What operating system (including version if Windows) are you using. In any case try Thread.sleep(19), Thread.sleep(21) and Thread.sleep(9) and report how long the sleep period is (measured using nanoTime).
Offline sunet2000

Senior Newbie




I want my mumart account back!


« Reply #26 - Posted 2005-05-25 00:51:55 »

Here's the test code, in case I happen to be doing something not-recommended. I'm running XP SP2 on a 1500mhz Sempron.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
public class Test implements Runnable {
      public void run() {
            while( true ) {
                  long timer = System.nanoTime();
                  try{ Thread.sleep( 20 ); } catch( InterruptedException e ) {}
                  System.out.println( System.nanoTime() - timer );
            }
      }

      public static void main( String[] args ) {
            new Thread( new Test() ).start();
      }
}


The output is quite amusing!

9ms   :~ 9600000
19ms :~ 19300000
20ms :~ 31000000
21ms :~ 21300000

Looks like 20ms triggers the scheduler into doing something wierd on my machine Smiley

I know I got a bit too emotional in my rant Smiley In these days of gigahertz and nanoseconds it's not unreasonable to be able to make something update once every 20ms is it?
Offline Mark Thornton

Senior Member





« Reply #27 - Posted 2005-05-25 07:49:36 »

That output is much as I expected. The JVM seems to assume that the natural resolution is 10ms and passes multiples of 10ms direct to the normal OS methods. However for values which are not multiples of 10ms, it makes some additional calls to alter the timing resolution.
It would be better if that 10ms value wasn't hard coded, but measured either at JVM install time or each time the JVM starts.
The normal clock period on this machine is 15.625ms (which is typical for the multiprocessor kernal).

Perhaps you should try 10ms as well; I would predict a 15.6ms result.
Offline sunet2000

Senior Newbie




I want my mumart account back!


« Reply #28 - Posted 2005-05-25 08:11:52 »

Just ran the test program again:

10ms :~ 10600000
20ms :~ 20200000

So it looks like my kernel has decided to use a 10ms timeslice again. I have no idea what could have caused this to change.

I guess that means there is a problem with the JVM, as it assumes the default timeslice on windows will always be 10ms?
Offline cliffc

Junior Newbie




Chief JVM Architect @ Azul Systems


« Reply #29 - Posted 2005-05-25 18:25:27 »

HotSpot just passes the given time through to through to the OS.  Nothing magical about 10msec, 15.6msec or any other number, at least not to HotSpot.

Before you can trust any such timing thing to be reliable you gotta run it "under load" - get a bunch of other threads running doing variable amounts of work+sleep (your AI wakes up, works for a quanta, sleeps, you decide to background load some music for the next scene, etc).  All those other threads running around will also mess with your timer's response.



Cliff Click, PhD - org dot acm at cliffc
High Performance Java VM Design and Implementation
Azul Systems
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (21 views)
2014-07-24 01:59:36

Riven (19 views)
2014-07-23 21:16:32

Riven (16 views)
2014-07-23 21:07:15

Riven (19 views)
2014-07-23 20:56:16

ctomni231 (47 views)
2014-07-18 06:55:21

Zero Volt (43 views)
2014-07-17 23:47:54

danieldean (34 views)
2014-07-17 23:41:23

MustardPeter (38 views)
2014-07-16 23:30:00

Cero (53 views)
2014-07-16 00:42:17

Riven (52 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!