And then that other problem: System.nanoTime on multiple cores…
Can’t some fancy API (like LWJGL) give us access to setting the affinity of a thread.
Then we can make some tiny class called Time, with a tiny method, called nanos(), which redirects the call to that thread. Problem solved. Everybody happy.
And probably less than one hour of JNI coding…? (I can’t do it)
Well, LWJGL uses the Windows multimedia timer which should be accurate no matter what anyway.
Cas 
I think it’s this bug. Hmmm… I wonder if this can be avoided with
while (System.nanoTime()<nextFrameTime) {Thread.yield();}
or is Minecraft <1.5?
There’s another work around for that bug which seems to work for me:
start a single (daemon) thread that just sleeps for Integer.MAX_VALUE and does nothing else.
Since Integer.MAX_VALUE isn’t an even multiple of 10, this causes the high res flag to get set and STAY SET for the duration of your program, avoiding any further timing drifts.
Sorry for joining the party late! This is again very impressive ;D
I really don’t know how you do it… :o
:oThat’s great!
use the LWJGL time it is not affected by cpu speed
There’s no sleep in lwjgl.
sorry, I was under the impression that it was the actual getting-time that was wrong and not the sleeping.
Well, it’s both. =)
The biggest problem is that using Thread.sleep() with values not evenly divisible by 10 causes the system clock to run too fast one some systems. I’ve added a bunch of work-arounds, but it doesn’t work perfectly.
This is a MAJOR FUCKING BUG, but Sun is fine with it, saying they won’t fix it because people didn’t complain when their previously suggested fix didn’t work, so they’re afraid of breaking anything.
It really should be Microsoft that fixes the problem since it’s their lame OS that can’t implement a simple clock properly. But isn’t there a workaround I read here somewhere… use a dummy thread to sleep for a really long time with a odd numberof millis - that way the clock stays in the higher resolution mode for the duration of the sleep - I think it’s flipping the clock resolution around every time a sleep needs the higher precision that causes the glitch.
This very thread, by mister Markus himself
Hm I’ve hardly ever come across this problem in the last, erm, how long… 7 years or so of doing sleep(1)s using the LWJGL Display.sync() method. EgonOlsen of these parts had a problem with it as I recall but he’s the only person to have ever reported it.
Cas
I haven’t personally run into it myself either, but I’ve gotten reports from players about it.
Display.sync() won’t cause the problem, it’s Thread.sleep() (like in, say, a sound mixing thread, or a background download thread)
Uber-cool! Just needs a shotgun for those mobs…
Wow very cool.
This game is sure one of a kind.
I like.
You’ve definitely got to include the ability to combine different blocks to make other ones, or special items, like a shovel for faster digging, a sword for fighting mobs, etc.
Also, I don’t know what you’re surviving here… why not have constantly rising lava combined with flying cannonballs that do damage to high points on the map (and anything near them)? Basically that means you’ve got to keep building upwards but you’ve also got to build a defensive structure around you to avoid the flying cannonballs.
Well on earlier JREs that would sleep for 14ms on Windows anyway
We ran into this at work when doing some timing sensitive network code it totally hoses the system clock. It seems like every sleep would flip the timer between a lower resolution and a higher one and there would be some lost time that happens during the switch due to rounding or something.
always get a “IndexOutOfBoundsException Index 2 Size 2” when dying.
nothing related to those bugs but this game is, IMO, just awesome… my son is alredy addict !!