Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  Fast engine.tick() design  (Read 8789 times)
0 Members and 1 Guest are viewing this topic.
Offline euroq

Innocent Bystander





« Posted 2009-10-13 07:17:18 »

Hello all.

I am making a Java game.  It's intended target platform is NOT Windows, but I'm still going to write it in Java.  So, I have a pretty basic question, but there's a few different rather complicated answers.

My question is this: How can I make the most efficient engine, or main loop, which ticks and does gameplay action (moves character, enemies, etc.), while also dealing with repainting?  There are a few different ways to do so.

Method A:
Put delay in the tick() method.  Here, the game loop logic, and the repainting, is done on the same thread.  If the game processing and drawing takes longer than the delay, then the game will simply slow down.  I'll have to code efficiently!

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
class GameThread extends Thread {
   public void run() {
      running = true;
      do {
         try {
            game.tick();
            display.repaint();
         } catch (Exception e) {
            e.printStackTrace();
         }
      } while (running);
   }
}
// ... Engine tick ...
  public void tick() {
      long start = System.nanoTime();

      // Do game logic
     doActions();

      // Wait until a given amount of time has passed
     while (now - lastFrameNs < DELAY_NS) {
         try {
            Thread.sleep(1);
         } catch (Exception e) {}
         now = System.nanoTime();
      }
   }


Method B:
Calculate the time delta in the tick() method, and move enemies and other game logic according to how much time has passed.  The game will always appear to run at the same speed, although the FPS will go higher or lower depending on the processing load of the game actions and drawing. 

1  
2  
3  
4  
5  
   long delta = System.currentTimeMillis() - lastLoopTime;
   lastLoopTime = System.currentTimeMillis();

   // Do game logic
  entity.moveBy(delta);


In the above logic, you see that enemies will move depending on the time taken.  So, if it took 50ms, they'll move by 10 pixels, or if it took 25ms, they'll move by 5 pixels.

The problem with this method, is that in-game logic timing becomes hard.  What if a gun is supposed to fire 3 times a second?  If the processing theoretically took a total of 1 second, I would have to fire the gun 3 times in the same tick(), which is bad because what if you'd want a back and forth between two entities (A interacts with B, B interacts with A, etc., instead of A interacts with B x 3, and THEN B interacts with A x 3).  Or, in some cases where the logic just fails, the gun would only fire once when it was supposed to fire three times.

Method C:

Hmmm, I can't think of a method C.   Smiley

Well, what are you guys' take on this?

Thanks!
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2009-10-13 09:11:37 »

You can decouple the engine.tick() from the engine.render() so that you keep deterministic gameplay, while the framerate might vary.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
   public static final long[] HZ_60         = new long[] { 16, 17, 17 }; // 16.66
  public static final long[] HZ_80         = new long[] { 12, 13 };    // 12.50
  public static final long[] HZ_100        = new long[] { 10 };

   private long[]             updateHzArray = HZ_80;
   private int                updateHzIndex = 0;
   private long[]             renderHzArray = HZ_80;
   private int                renderHzIndex = 0;

   public GameLoop(long[] updateHz, long[] renderHz)
   {
      this.renderHzArray = renderHz;
      this.updateHzArray = updateHz;
   }

   //

   public long renderInterval()
   {
      return renderHzArray[(renderHzIndex++) % renderHzArray.length];
   }

   public long updateInterval()
   {
      return updateHzArray[(updateHzIndex++) % updateHzArray.length];
   }

   public void loop()
   {
      long nextUpdate = now();
      long nextRender = now();

      int renderCount = 0;
      int updateCount = 0;
      long renderTime = 0L;
      long updateTime = 0L;
      Interval second = new Interval(1000);

      while (!this.isStopRequested())
      {
         long now = now();

         if (now < nextUpdate && now < nextRender)
         {
            try
            {
               Thread.sleep(1);
            }
            catch (Exception exc)
            {
               exc.printStackTrace();
            }

            continue;
         }

         if (now >= nextUpdate)
         {
            long t0 = now();
            this.update(now);
            long t1 = now();
            updateTime += t1 - t0;
            updateCount += 1;

            nextUpdate += this.updateInterval();
         }

         if (now >= nextRender)
         {
            long t0 = now();
            this.render(now);
            Display.update();
            long t1 = now();
            renderTime += t1 - t0;
            renderCount += 1;

            // allow to skip frames
           while (now >= nextRender)
            {
               nextRender += this.renderInterval();
            }
         }
      }
   }

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #2 - Posted 2009-10-13 10:45:13 »

I have most of my games run at a game logic of about 30-40 hz, while rendering the game as fast as possible, interpolating the state between the last two ticks.

Play Minecraft!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2009-10-13 15:01:59 »

Interesting, my code does the inverse. But then, I never wrote a serious game.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #4 - Posted 2009-10-13 16:27:47 »

Interesting, my code does the inverse. But then, I never wrote a serious game.
Riven, I do it the same as you. Rendering gets second priority, whereas logic tries to be smooth. Probably depends on the game. The reason why rendering gets left out is because I need fidelity of input (thus I need to capture it frequently) whereas FPS are not so important, as long as the user can't really observe any graphical hiccups. Also, rendering in my games usually ends up taking much longer than the logic, so it makes sense to let the logic run free and reign in the rendering instead. I imagine Markus's games don't often suffer from these problems because he so often has very complicated game algorithms but very low res textures (like Minecraft as a good example).

See my work:
OTC Software
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #5 - Posted 2009-10-14 03:27:13 »

I have most of my games run at a game logic of about 30-40 hz, while rendering the game as fast as possible, interpolating the state between the last two ticks.
Same here.

@Demonpants
The same approach Markus_Persson described can be used to run the logic at any fixed speed. This means you can place the input checks in the logic. Letting your simulation run at whatever speed it can means if that speed is very slow, everything explodes. Not prioritizing rendering means that objects may not move smoothly. Markus_Persson's games don't have problems because his time step approach solves them all.

More on a fixed time step:
http://gafferongames.com/game-physics/fix-your-timestep/

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #6 - Posted 2009-10-14 11:15:10 »

It's not about prioritizing framerate over game feel at all. It's actually about making sure the game plays exactly the same on all computers (see the link Nate posted). The fact that the framerate gets as smooth as possible on any given computer is just a nice side effect.

There are a couple of downsides to this approach:

* If game logic takes a long time, every n'th frame will render slower than the rest, causing stuttering graphics
* The game visuals will always lag behind by 1/game_logic_hz seconds because of the interpolation. (Of course, this has the upside of putting the graphics more in synch with the audio if you tweak it right)
* If a game logic step takes more than 1/game_logic_hz seconds on a computer, the game will never catch up and the game won't be playable on that computer.

Play Minecraft!
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2009-10-14 12:36:22 »

I feel all dumb and stupid for sticking to my fixed frame-rate logic now :/

But hey, it works. 1 tick = 1 frame, no interpolation, and if it doesn't run at 60Hz... the computer's too slow.

Cas Smiley

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #8 - Posted 2009-10-14 13:15:34 »

Hey, don't knock it! A lot of my "smaller" games (ludum dare, 4k) use fixed 60 hz logic.
A major advantage of that system is that each frame takes about as long to process and render, so there's not as much uneven framerate.
A downside is playing a 60hz game on a monitor running anything other than 60 hz (except perhaps 30 or 120 hz) WILL get choppy.

Play Minecraft!
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2009-10-14 14:11:03 »

Fortunately modern monitors almost all run at 60Hz! (Being typically TFT screens)

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #10 - Posted 2009-10-14 16:21:16 »

Same here.

@Demonpants
The same approach Markus_Persson described can be used to run the logic at any fixed speed. This means you can place the input checks in the logic. Letting your simulation run at whatever speed it can means if that speed is very slow, everything explodes. Not prioritizing rendering means that objects may not move smoothly. Markus_Persson's games don't have problems because his time step approach solves them all.

More on a fixed time step:
http://gafferongames.com/game-physics/fix-your-timestep/
Hm, interesting. I've always just used a delta to make up for stutters - if it has been a long time since the last step then everything will move a little bit further. But I suppose it makes sense in most settings to try to fix things around the graphics, if I really think about it. Having the logic stutter is not nearly as observable as having the graphics stutter.

See my work:
OTC Software
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2009-10-14 18:03:26 »

Riven, I do it the same as you.

Hm, interesting. I've always just used a delta to make up for stutters

Actually, no. My engine ticks at a fixed rate. I thought that was obvious from the sourcecode.

It is the rendering thread that makes a 'best effort' at ticking at a fixed rate.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #12 - Posted 2009-10-14 18:57:04 »

Actually, no. My engine ticks at a fixed rate. I thought that was obvious from the sourcecode.

It is the rendering thread that makes a 'best effort' at ticking at a fixed rate.
Oh. Yeah I didn't read your source.

I do it something like this:

while(running)
{
    float delta = calculateDeltaFromLastTime();
    update(delta);
    if (timeSinceLastRender > renderThreshold)
    {
        render();
    }
    Thread.yield();
}

Usually I make it so that updates happen about 3 times per render. And obviously it goes as fast as it possibly can. Problem with this obviously is that it uses up your whole processor no matter what. I've been using the iPhone lately so this doesn't matter, but usually when deving in Java I just use the sync() method in LWJGL so I don't have to bother with it. Also, the reason I render less often on the iPhone is because long renders will lock receiving touch input which can cause very annoying control. So I update much more often. In Java I guess this isn't a problem typically because input is usually handled in another Thread anyway. Although I'd imagine with LWJGL you might want to do this so you can poll the keyboard more often.

See my work:
OTC Software
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #13 - Posted 2009-10-14 19:11:42 »

It's very important to have a fixed tickrate, to keep your game deterministic, which is a requirement for any (serious) networked game.

update(delta) is the root of all evil, unless delta is a constant Wink

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #14 - Posted 2009-10-15 06:32:54 »

It's very important to have a fixed tickrate, to keep your game deterministic, which is a requirement for any (serious) networked game.

update(delta) is the root of all evil, unless delta is a constant Wink
Yeah I guess I never spent enough time thinking about it. The first time I put a custom loop in the game (I had been using java.util.Timer previously, which is even worse), I was using an example that Kev made (Space Invaders) that attempts to achieve a constant FPS but allows fluctuation to happen. Or so I thought when I originally looked it. Since then I've been doing my own bastardized method.

So say you're trying to get 60 fps but the game is only able to get 40 fps. Doesn't that mean that you should be passing in a delta of 60 / 40 - moving everything a bit extra to make it all appear like it's working the same? Or should you just do like Markus suggested and go for a low easy to achieve logic frame rate (around 30 hz) and let the rendering take as much time as it needs? I guess really what should happen is you force the logic to maintain its 60 hz as best you can, sucking away from rendering frequency if you're having trouble meeting your desired hz. Yes/no?

I think I'm honestly going to go and adjust some of my game loops now, because this makes a lot of sense to me now that I'm actually thinking about it.

See my work:
OTC Software
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #15 - Posted 2009-10-15 09:56:31 »

My posted sourcecode answers your questions.

(If the game can't manage to tick at the frequency you have set, the game is not suited for the hardware it runs on)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #16 - Posted 2009-10-15 19:20:58 »

Okay, thanks, Riven. Smiley

See my work:
OTC Software
Offline Roquen
« Reply #17 - Posted 2009-10-16 11:17:05 »

Variable rate logic updates are not always evil (IMHO).  If one is performing physical simulations and/or distributed system based network logic, then yes you'll make your life much much easier. 

I'd say this point falls into the common game programming catch-phrase of: "Well, it depends".
Offline DzzD
« Reply #18 - Posted 2009-10-18 13:03:07 »

there i also a way to achieve same logic everywhere even with a low timer accuracy and a free framerate.

starting with the following assumption :
- no need to update physic if nothing is rendered to screen
- need to perform logic at exact fixed time step

basically it run like that :

1  
2  
3  
4  
5  
6  
7  
8  
9  
while(true)
{
 while(logicTime<currentTime)
 {
  performLogic();
  logicTime+=logicRate; //eg : 10ms
}
 renderScreen();
}


in this one framerate is free and logic is always exacly the same between computer even with a very inaccurate (high granularity) timer, last but not least it is damnly simple to implement


EDIT: something is missing in the above code : no need to render scene if logicTime>=currentTime => sleep(1) this will avoid 100% cpu usage and will adapt framerate to logic

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #19 - Posted 2009-10-18 13:44:17 »

That's pretty much exactly what I do, but with frame interpolation.

Play Minecraft!
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #20 - Posted 2009-10-20 01:27:56 »

That's pretty much exactly what I do, but with frame interpolation.
I'm attempting to get frame interpolation in my game working (just messing around with different types of game loops), and the result is very twitchy entities. I'm not sure if I'm doing this right.

So here it is distilled a bit:

In the update for the entity, it will add its acceleration to its velocity, then its position will be position + velocity.
In the draw for the entity, it will be drawn at position + velocity * interpolation.

The result is an incredibly twitchy entity.

The FPS are generally around 40 and the logic runs at a fixed 25 hz.

Interpolation is calculated like this:
1  
2  
float interpolation = ( now + TIME_BETWEEN_UPDATES - nextUpdate ) /  (float) TIME_BETWEEN_UPDATES ;
view.drawView( interpolation );


Can anyone point me in the right direction?

EDIT:
Let me just post my whole loop:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
while( loopIsRunning )
{
    double now = getTimeInSeconds();
     
    int updates = 0;
    while (now >= nextUpdate && updates < MAX_SKIPS)
    {
        update();
        nextUpdate += TIME_BETWEEN_UPDATES;
        updates++;
    }
     
    view.drawView( (getTimeInSeconds() + TIME_BETWEEN_UPDATES - nextUpdate ) / (float)( TIME_BETWEEN_UPDATES ) );
}

See my work:
OTC Software
Offline DzzD
« Reply #21 - Posted 2009-10-20 01:37:44 »

maybe you forgot to interpolate with acceleration in your interpolated position :

this :

pos = pos0+v0*t+0.5*a*t² (t=interpolation time starting at pos0 with velocity v0)

will be different than this :

pos = pos0+v0*t

EDIT :
if you want smooth interpolation (that take care in a certain manner of acceleration) try cubic interpolation






form : http://freespace.virgin.net/hugo.elias/models/m_perlin.htm

1  
2  
3  
4  
5  
6  
7  
8  
function Cubic_Interpolate(v0, v1, v2, v3,x)
   P = (v3 - v2) - (v0 - v1)
   Q = (v0 - v1) - P
   R = v2 - v0
   S = v1

   return Px3 + Qx2 + Rx + S
  end of function



Offline DzzD
« Reply #22 - Posted 2009-10-20 01:57:46 »



here some precision v0,v1,v2 are the last know position of your entity at fixed time step and v3 the futur position that you already know (interpolation vs extrapolation)

lets say v0=pos at t=0
lets say v1=pos at t=40ms
lets say v2=pos at t=80ms
lets say v3=pos at t=120ms

you will be interrested in finding v between v2 & v3 if you want v at time=100 just do

v=Cubic_Interpolate(v0, v1, v2, v3,1.5);

so for x/y:

xi=Cubic_Interpolate(x0, x1, x2, x3,1.5);
yi=Cubic_Interpolate(y0, y1, y2, y3,1.5);

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #23 - Posted 2009-10-20 03:03:50 »

In the update for the entity, it will add its acceleration to its velocity, then its position will be position + velocity.
In the draw for the entity, it will be drawn at position + velocity * interpolation.

It sounds like you are doing extrapolation. You don't want to guess where the object will be next frame, then sudden movements can render your guess incorrect and the movement will jump around. I recommend the link I posted earlier.

Snapshot the state of the game before each fixed logic step. Now you have the previousState and the currentState. Since you did a fixed logic step, you may have stepped < the delta. Do alpha = 1 - timeRemaining / fixedTimeStep to get a number between 0 and 1. Interpolate by rendering at the previousState + ((currentState - previousState) * alpha). This introduces one frame of latency, but no guessing is involved.

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #24 - Posted 2009-10-20 03:22:44 »

Here is a game loop:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
static final int LOGIC_HZ = 60;
static final int STEP = 1000 / LOGIC_HZ;
static final float PER_SECOND = STEP / 1000f;

int accumulator;
float speed = 1f;
final State previousState = new State();
final State currentState = new State();
final State renderState = new State();

void init () {
   currentState.x = 100;
   currentState.y = 100
   currentState.vx = 42 * PER_SECOND;
   currentState.vy = 42 * PER_SECOND;
   previousState.copy(currentState);
}

void render (int delta) {
   accumulator += delta / speed;
   while (accumulator >= STEP) {
      accumulator -= STEP;
      previousState.copy(currentState);
      currentState.integrate();
   }
   float alpha = accumulator / (float)STEP;
   renderState.interpolate(previousState, currentState, alpha);
   renderState.render();
}


Note the accumulator is int. The fixed steps are 16ms (60hz). Because I know the logic will always happen in 16ms increments, I base all my speeds on this (note I don't even bother passing the step to integrate()). Eg, if I move an object each logic step by 20 * 0.016, then it will move at a speed of 20 pixels per second. By doing this, in the above code I can use speed = 1 for normal speed or I can do slow (speed < 1) or fast (speed > 1) motion without ruining the simulation.

The state class would look something like:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
class State {
   float x, y, vx, vy;
   void integrate () {
      x += vx;
      y += vy;
   }
   void interpolate (State previous, State current, float alpha) {
      x = previous.x * (1 - alpha) + current.x * alpha;
      y = previous.y * (1 - alpha) + current.y * alpha;
   }
   void copy (State other) {
      x = other.x;
      y = other.y;
   }
   void render () {
      ...
   }
}

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #25 - Posted 2009-10-20 14:22:27 »

if you want smooth interpolation (that take care in a certain manner of acceleration) try cubic interpolation

That has one MAJOR flaw. If a ball is moving towards a wall at 100 mph at tick n, and hits the wall one tenth of the way between tick n and n+1, the renderer will interpolate the ball as moving into the wall and back out.

I always use linear interpolation. It's fast and it works well.
For things like pinball and such where collisions are important, I build a list of all collision points during a tick, then interpolate (linearely) between those when rendering.

Play Minecraft!
Offline DzzD
« Reply #26 - Posted 2009-10-20 14:52:08 »

That has one MAJOR flaw. If a ball is moving towards a wall at 100 mph at tick n, and hits the wall one tenth of the way between tick n and n+1, the renderer will interpolate the ball as moving into the wall and back out.

I always use linear interpolation. It's fast and it works well.
For things like pinball and such where collisions are important, I build a list of all collision points during a tick, then interpolate (linearely) between those when rendering.
I also usually use linear interpolation, but as Demon talk about acceleration cubic interpolation fit better. this is only a flow if you use it "brut force" and only interpolate position without doing anything else (you can handle such case pretty easily),

also in the case your mention (as I understand it).... linear interpolation will just make the ball never touch the wall like if a magnetic field keep it away, it is as false than going throught.... :p

Offline DzzD
« Reply #27 - Posted 2009-10-20 14:56:55 »

here is what I mean :



the advantage of Cubic vs linear is that you can subsampling it into smaller linear  part and compute real collision(avoid the MAJOR flaw), subsampling linear will have no effect and will stay as false.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #28 - Posted 2009-10-20 19:12:32 »

Thanks for all that, guys. I'm definitely going to go with the state approach as mentioned above - I've already got previousPosition and position stored, so all I need to add is previousRotation and it'll work fine. I wasn't really seeing it as being 1 frame behind which is what my original problem was, I think.

I'll let you all know how this works.

EDIT - Doing it via state looks great. Very stable and not twitchy. Thanks everyone. I'll definitely make my loops like this in the future. It's a lot nicer to not have to worry about a delta variable all the time, too.

See my work:
OTC Software
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #29 - Posted 2009-10-21 10:15:39 »

also in the case your mention (as I understand it).... linear interpolation will just make the ball never touch the wall like if a magnetic field keep it away, it is as false than going throught.... :p

I find it much less jarring with linear interpolation than cubic, and the overhead of doing a "clever" (ie world aware) cubic interpolation is probably a LOT bigger than you assume. I'd rather list all collisions within a tick and interpolate linearely between those.

Including acceleration in the interpolation, however, is a very good idea if you manage to do it right, but it'll only matter in games where things change direction a lot.

Play Minecraft!
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.

Riven (12 views)
2014-07-29 18:09:19

Riven (8 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (25 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

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

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

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

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

ctomni231 (59 views)
2014-07-18 06:55:21
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!