Java-Gaming.org Java4K winners: [ by our judges | by the community ]         
Featured games (67)
games approved by the League of Dukes 		Games in Showcase (∞)
games submitted by our members



News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Java-Gaming.org > Games Center > Contests > Finished Contests > 4K Game Competition - 2009 > Best [Smallest] Consistent Timing?
Pages: [1]
  Print  
  Best [Smallest] Consistent Timing?  (Read 1376 times)
0 Members and 2 Guests are viewing this topic.
Offline Hsaka

Jr. Member
**

Posts: 95
Medals: 2
« on: 2009-01-24 01:33:18 »
Hi guys.

I was wondering what is the best method you've found so far for keeping consistent timing in a 4K game. I've looked at the source code for several 4K games and most seem to employ different approaches. Any tips on this would be greatly appreciated.
Offline BitDragon

Jr. Member
**

Posts: 66


Sunset? Nice gradient paint!
« Reply #1 on: 2009-01-24 04:27:02 »
I use System.nanoTime() to compute the exact duration of the most recent frame. I then compute a time factor from frame duration, which is applied in all computations. This way, you get approximately performance-independent game behavior. Pseudocode example:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
// Initialize timer
timer=nanotime
// Game loop
while game running
  // Update timer
  timer=nanotime-timer
  // Compute delta (this is a float or double!)
  delta=nanotimer/10e6
  // Example application: Movement
  exampleposition+=examplevelocity*delta


Note: You have to be a bit careful when dealing with derivates (e.g. accelleration), know your calculus  Smiley

hth Wolfgang

"I'm a ****ing starship, I'm allowed to cheat!"
GCU Arbitrary, Culture Craft
Offline moogie

JGO Strike Force
***

Posts: 775
Medals: 5


Java games rock!
« Reply #2 on: 2009-01-24 18:07:52 »
I do mine slightly differently I have a set game logic frame rate and undetermined paint frame rate. This allows me to not use a delta multiplier and instead just hard coded values thus reducing the code needed.

you can probably use nanotime instead of currentTimeMillis(), I used it for legacy JVMs

e.g. for a frame rate of 40 fps

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
long lastTime=System.currentTimeMillis();

while (game alive)
{
      while (lastTime<System.currentTimeMillis())
      {
             lastTime+=25;

             //perform game logic

      }

       // draw graphics

       Thread.yield();
}
Games published by our own members! Go get 'em!
Offline Hsaka

Jr. Member
**

Posts: 95
Medals: 2
« Reply #3 on: 2009-01-24 21:56:24 »
Thanks very much for the replies guys.
I'll try out moogie's approach as I was using the delta before.
Offline BitDragon

Jr. Member
**

Posts: 66


Sunset? Nice gradient paint!
« Reply #4 on: 2009-01-25 04:26:34 »
Quote from: moogie on 2009-01-24 18:07:52
you can probably use nanotime instead of currentTimeMillis(), I used it for legacy JVMs

It is a good idea to use nanotime, no matter which timing scheme you apply, because currentTimeMillis is very unprecise under Windows and will limit you to 20fps under certain (not so uncommon) system/os combinations.

Moogie, I'll try out your approach in my Elite clone, hadn't though about it in years due to the shortcomings of currentTimeMillis but with precise timing it should work for simulations with higher precising requirements, too.
 
Pages: [1]
  Print  
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.069 seconds with 21 queries.