Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  [Java2D] Need some explanation on an old tutorial.  (Read 194 times)
0 Members and 1 Guest are viewing this topic.
Offline tyeeeee1
« Posted 2014-05-12 19:52:26 »

Hey,

I'm trying to rewrite the game loop that I've been using for every single project I've made recently, but some information in the tutorial isn't very clear to me. Could someone explain why, in the variable timestep game-loop, the number 1000000000 is used and whether or not delta actually matters at all.

Throughout everything I've made with the variable timestep game-loop, I've never used delta and everything has worked just as it should. The one time where I did do a quick experiment by using delta in my particle system, everything went haywire and the particle movement bugged out. This leads me to believe that the delta variable doesn't need to be used.

Oh, one additional question. Is there a simpler game-loop that can be used which performs the same as the variable timestep game-loop in this tutorial?

The variable timestep game-loop was taken from this tutorial: http://www.java-gaming.org/index.php?topic=24220.0


Thanks for any help.
Offline philfrei
« Reply #1 - Posted 2014-05-12 22:04:29 »

In the Variable timestep game loop, we take a measure of how long the loop is taking to execute, and use that to compute a "delta" that will be applied to the animations. If the loop executes quickly (higher fps) then the delta will be smaller, causing the movement to be less per frame. If the execution speed slows down for a loop, the delta will be larger, and the movement on that iteration of the game loop will be greater.

In this scenario, OPTIMAL_TIME is being used as a denominator for the calculation of the delta. The exact value of the OPTIMAL_TIME looks to me to be somewhat arbitrary. I assume Eli set it to this value because he wanted to be sure that it was never less than the elapsed nanoseconds for a given loop. Whatever the value is set to be, and whatever deltas result from the calculation, the animations will have to be "tuned" to work correctly with those deltas.

Just in case you've missed the point about how the deltas are used: lets say you have a target speed for an animation of 2 pixels per frame, e.g., xVel = 2. Thus, the animation computation is: xPos += xVel;

With variable timestep game loops, we would multiply xVel by delta before adding it to xPos. Since the delta is a function of the elapsed time, when more time elapses, the delta is larger, when the loop processes more quickly the delta is smaller. The OPTIMAL_TIME denominator helps 'tune' the delta to a value that makes sense for the animation computation. We want deltas to mess with the xVel a "reasonable" amount. I'm not sure what reasonable is here, maybe 50% to 200%? I'm guessing in your attempts to use the delta, the value when multiplied against xVel or yVel produced some unreasonable movement values because it wasn't tuned very well.

A "simpler" game loop can mean different things. If you want to eliminate the fractional aspect of the animations (it seems like you already do this, since you eliminated the delta, according to your post), but ensure that the game runs the same speed on various computers and runs the same speed when vastly different amounts of computations are made per loop, then a common strategy is to use a variable amount of sleep per loop in order to ensure each loop takes the same amount of time.

Thus, we save the time at the top of the loop, and as the last set of commands for the loop, inspect the elapsed time and sleep the difference between the elapsed time and the fixed target time for the loop. The following code illustrates the basic concept.

1  
2  
3  
4  
5  
6  
7  
8  
while (running)
{
    long startTime = System.nanoTime();
    game.updateAnimations(); // no delta needed
   game.render();
    long elapsedTime = System.nanoTime() - startTime;
    Thread.sleep(elapsedTime);
}


Problems with this:

(a) accuracy of the system clock. With Microsoft OS's, I think the system clock is often set to update every 15.5 millis or something like that. Lots of folks here talk about getting around this by kicking the system clock into a higher gear, but I can't recall the exact method. I think it was running a concurrent Thread with a sleep command with a very high value: e.g., Thread.sleep(Long.MAX_VALUE);

(b) the game loop speed is only capped, not prevented from slow downs. If your game loop code takes so long to execute that it creates an elapsedTime value that is larger than the TARGET_TIME, there is no provision for "catching up".

NOTE: this is EXACTLY THE SAME COMPLAINT used against the util.Timer in Eli's tutorial!! (And, the same performance result.) Thus, this simpler game loop method is in effect pretty much equivalent to using the util.Timer (NOT the swing.Timer).

I do not share the prejudice held here by many at JGO against the use of util.Timer for game loops. Most here prefer to use some variant of the variable-sleep amount. But, we could schedule a fixed-time loop with a simple timer-scheduling command, e.g., from Eli's:
1  
    timer.schedule(new GameLoop(), 0, 1000 / 60.0); //new timer at 60 fps, the timing mechanism

NOTE: I changed his LoopyStuff() to GameLoop() [purely cosmetic] but also, made the repeat interval a double rather than an integer calculation! [tutorial bug fix]

With this, the GameLoop object is an extension of TimerTask, as Eli presents. There's no need to calculate elapsed times or manage sleep intervals.

"Greetings my friends! We are all interested in the future, for that is where you and I are going to spend the rest of our lives!" -- The Amazing Criswell
Pages: [1]
  ignore  |  Print  
 
 

 

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

The first screenshot will be displayed as a thumbnail.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (27 views)
2014-09-07 01:11:22

Longarmx (26 views)
2014-09-07 01:10:19

mitcheeb (34 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!