Don't forget that there are still a lot of OS's with slow clock interrupts out there, like Win XP. The accuracy of the sleep is only within +/- 15 msec, unless you do the trick to get a high speed clock mode:

Setting that thread as a daemon will make it run in the background and will automatically end when the applet is closed.The only thing you need to know about sleep(xx) is that is inaccurate without using that thread sleeping forever trick. Otherwise, you're good to go.For a really smooth game loop, it is best if you use a busy Thread.yield loop like this:

It probably is, but still doesn't achieve 1ms accuracy. Try the same without the accuracy thread and you might even have much bigger differences. Hence the tight loop checking the actual time spend by the sleep on every iteration.

Why you are trying to clutter your game code with those sleep(2)Only set sleep in one place and only if needed. There isn't any reason for minimum sleep. Just use example what raking provided and you are safe. Don't try to use any kind of magic here. Its just a game loop and done millions times before. Use what is already tested and proved to behave smoothly.

I agree, your timing numbers make it look like the XP is still using its clock interrupt of about 15msec. I can think of two possible reasons that you are not showing better accuracy with your TimerAccuracyThread running.

1) [Unlikely]Maybe this tactic only works with Win XP sp 3. My system is sp3, not 2, so I can't say for sure it works on sp2.

(2) Maybe you are measuring your accuracy using System.currentTimeMillis(). It will remain at 15msec accuracy, even with TimerAccuracyThread running. To measure elapsed time correctly (if you are not already doing so) use System.nanoTime() instead.

Below is a class I wrote which I use to get timing metrics. The main() method will demonstrate the difference between measuring with currentTimeMillis() and nanoTime(). Try running it with and without TimerAccuracyThread.

Dont clutter the code. Use sleep/yield only in on place inside of loop and dont put it after the draw calls. If you are doing turn based game use sleep if something with real time components then use yield.

Where you have "learn" that yield/sleep after image drawing thing. It's just plain wrong. Computers are most efficient when they are running on full speed. Best method is then: draw fast as possible and sleep after that until next frame is needed to render.

If something happens to users computer it will propably happen when cpu or gpu load is hi, there is no reason to run cpu or gpu at 70%-100%, if it can be run 20%-40%, even if heavy load is just a short time.

I will set as many sleep and yield moments as i can to my code, and i feel im more respected that way when i speak about how my code runs, but im not starting to argue about this, i just want to know if there is any common times i should yield after every bufferedimage or quad, i would love to use sleep but it is not possible with present java to sleep so short times, so i have yield loops with nanotimer().

Thread.yield() uses a lot more CPU than Thread.sleep(). Also you'll get a lot more "respect" by using proper coding conventions and doing it right.

Also "i would love to use sleep but it is not possible with present java to sleep so short times", can't this be fixed with infinite sleeping thread trick.

Yield != sleep. It essentially means "take this thread out of the running queue, search for runnable threads, put them on the queue if they are available, and if they aren't available, continue running this thread". That is a of work you are adding to your while loop, and it does not prevent that thread from still eating up all CPU usage (where as sleep does).

Yielding also has dramatically different effects on different operating systems. In Windows Vista and 7, the OS will generally sleep your thread more often (it is a lot more difficult for threads to starve each other from Vista onwards). On Linux and XP, it won't. As a result parts of your app can freeze on one OS, and not on another, all because you used yield.

In my own code I sleep for the length of an ideal frame, minus the length that the last frame took (I think this was already suggested above). In practice the ideal frame time is around 15, a tad faster then 60fps. This always worked well for me, and I'd recommend it over yielding, spinning or sleep(1)'s. I would only use something more advanced if this does not work for you!

There is a good reason why Windows, and Mac OS, don't use high resolution timers by default. It is the same reason why Java, and especially JavaScript, also don't support a high resolutions for their timers. It is because it significantly drains the battery life on laptops and other devices. Chrome developers experimented with having a high-resolution timer, and found they used up an extra 25% of battery time. That is a quarter of the life spent solely on keeping the timer accurate. In one of the Mac OS X updates Apple reduced the internal timer, as it significantly increased battery time. IE 9 even has different resolutions, depending on if you are plugged into the mains or not.

A hint to the scheduler that the current thread is willing to yield its current use of a processor. The scheduler is free to ignore this hint.

Yield is a heuristic attempt to improve relative progression between threads that would otherwise over-utilise a CPU. Its use should be combined with detailed profiling and benchmarking to ensure that it actually has the desired effect.

It is rarely appropriate to use this method. It may be useful for debugging or testing purposes, where it may help to reproduce bugs due to race conditions. It may also be useful when designing concurrency control constructs such as the ones in the java.util.concurrent.locks package.

I do have this 200-400 maybe more bufferedimages on drawing row, largest is 900x900px and some are somewhat a 200x200px and 100x100px and a lot of 32x32px, and i do not know any other way to let graphics card rest a bit after every bimage than my good friend yield loop with nanotimer ?

Frame rate limiting is only useful on laptops. It's either to reduce power consumption or reduce graphics card heat. My little laptop likes to be 89 degrees if I don't set my settings carefully. Only power consumption is relevant in this case of course, but letting a Java2D program run wild doesn't sound that bad...

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