Tag Info

Hot answers tagged

17

You want to separate update (logic tick) and draw (render tick) rates. Your updates will produce the position of all objects in the world to be drawn. I will cover two different possibilities here, the one you requested, extrapolation, and also another method, interpolation. 1. Extrapolation is where we will compute the (predicted) position of the object ...


12

Here's a quick outline, off the top of my head, of an algorithm that ought to work reasonably well. First, calculate the direction the object is moving, and check whether it's closer to horizontal or vertical. If the direction is closer to vertical (horizontal), adjust the position of the object along the direction vector to the center of the nearest pixel ...


11

One option that'll be a lot easier than fiddling with mipmaps and adding texture coordinate fuzz factors is to use a texture array. Texture arrays are similar to 3d textures, but with no mipmapping in the 3rd dimension, so they're ideal for texture atlases where the "subtextures" are all the same size. http://www.opengl.org/wiki/Array_Texture


9

Blue vector can be calculated easily: red - black (the sign between vectors is minus). But if you want just to interpolate between black and red vector, you don't have to calculate it. Linear interpolation is just linear combination. So you can just take: alpha * black + (1 - alpha) * red, where alpha has to be from interval <0,1>. If alpha will be 1, ...


8

For this reason, you'll find simulations are often run 1 or more frames ahead of what is in fact being rendered at given point in time on a give client. So in other words, what you render might in fact be the second last frame, not the last frame. Search this article for all instances of the word "ahead" and I think you will start to get the picture better ...


8

Okay, I think you have two problems going on here. The first problem is with mipmapping. In general, you don't want to naively mix atlasing with mipmapping, because unless all your subtextures are exactly 1x1 pixel sized, you will experience texture bleeding. Adding padding will simply move the problem to a lower mip level. As a rule of thumb, for 2D, ...


6

You have jitter, because you lag is changing constantly. This means, that while server sends updates exactly every timeBetweenTicks ticks, the client receives them after some variable time. That time is probably close to timeBetweenTicks on a good connection, but not exactly equal (And besides, you may have server lag and different clock speeds on server and ...


6

I have solved this problem before with some success with an approach I call "network shadows". I don't know if this is something other people do, but it's always worked for me. Each entity which is being synchronised across the network has an invisible network shadow entity. When an update comes in from the network, you teleport the shadow directly to the ...


5

Put very simply, linear interpolation of matrices is not always a good idea. If you have an animation you are trying to accomplish, and you are using matrices to handle the bones rotation, you can't just take a linear combination of them. You'll need to use slerp, extract the axis of rotation and interpolate the angle and recalculate the rotation matrix, or ...


5

In general, lerp functions don't take a speed, they take a parametric representation of how much they should be in between your start (A) and end (B) parameters. Of course, if you have a constant speed, you can figure out how long it should take you to go from A to B doing some simple math. If you're moving at X m/s, and you need to travel Y m, then you ...


5

While the server has the final say on the position, it should do that by verifying and sanity-checking what the client sends over as the inputs and position. I say this because what you're doing is moving the player immediately and the expectation that creates in your code is that the client is the real position. You think it generally works well, but it's ...


4

I took a quick look at your example and your code. You're extremely close to solving this, so I don't mind helping with a question that looks suspiciously like homework ;). In data.js, you are assigning the same UV coordinates to the front and rear faces of the cube. The coordinates seem to be ([0,0], [0,0.5], [0.5,0.5], [0.5,0]). This means that you can ...


4

Two that you're missing which immediately stand out to me are GJK and MPR. GJK is an algorithm for finding the closest point of two convex polygons. With a little bit of extra work you can use it to find incident points for intersecting objects, and hence calculate a collision manifold. This is done via polygon clipping, same as if using SAT, but GJK ...


3

When the pending movement is perpendicular to the last movement (in screen space), ignore it and use the last screen coordinates. If that lead to stutter that's as bad as the staircase, you might try moving the sum of the pending and last movement. I think the problem lies in v < sqrt(2). v > sqrt(2) should always move at least a full diagonal, ...


3

Looking at your second log file, I'm wondering if you're calling resetSmoothStates() in the right place? On lines 42, 46, 50, and 54 you can see that the original position stays at a constant [661.2183], indicating there hasn't been a physics update. On line 43, it looks like you're smoothing between the previous original position, [671.2361], and the new ...


3

Problem: Your computer can achieve the target fixed physics framerate, but your phone cannot. Solutions: Reduce the physics framerate (Increase FIXED_TIMESTEP). Reduce the physics calculations needed per frame. Do you absolutely need interpolation? Just render the uninterpolated state. Interpolation is only for making the rendering look smoother. ...


3

In video editing (and animation and other fields), the terms used for what you're talking about are "ease in/out" and "smash in/out", with "ease" meaning to begin or end from a standstill, and "smash" meaning to begin or end with full velocity. Your existing algorithm gives you "smash in, smash out", since it maintains a constant velocity the whole way ...


3

Do not attempt to replicate the whole game state. Interpolating it would be a nightmare. Just isolate the parts which are variable and needed by rendering (let us call this a "Visual State"). For each object class create an accompanying class which will be able to hold the object Visual State. This object will be produced by the simulation, and consumed by ...


3

The most common form of interpolation is linear interpolation. However, in the case of animating curve splines, another common one is spline interpolation.


2

I've heard this approach to timesteps suggested quite frequently, but in 10 years in games, I've never worked on a real-world project that relied on a fixed timestep and interpolation. It seems generally more effort than a variable timestep system (assuming a sensible range of framerates, in the 25Hz-100Hz sort of range). I did try the fixed ...


2

My solution far less elegant/complicated than most. I'm using Box2D as my physics engine so keeping more than one copy of the system state isn't manageable (clone the physics system then try to keep them in sync, there might be a better way but I couldn't come up with one). Instead I keep a running counter of the physics generation. Each update increments ...


2

One way to move slower at the start and faster towards the end would be to square the time: vector currentPos = posA + (posB - posA) * (timeI * timeI) If you look at this graph (wolfram) you can see why this works. To move faster at the start and slower at the end: float t = 1 - timeI vector currentPos = posA + (posB - posA) * t * t


2

Here is a graphical example of what I meant in the comment I wrote in the comment section of the OP's question. While the ticks representing the d values progress evenly from one vector to the other, the angular change (red lines) are not even. the changes near the middle of the sequence represent greater change than near the ends. so an animation of ...


2

There's not much you can really do about that for a general physics-based world. If all of your objects were moving along lines or specific circles, you could do something. But you're operating under actual physics. The object is where the physics puts it; you are simply drawing a pixel-based approximation of that location. It's generally something you have ...


2

Don't interpolate with velocity. Calculate the next actual position ( with full physics ) and simply interpolate between the last and current positions. Same for rotation and any other physical properties that graphics cares about. What might happen now is that an object bounces before hitting the floor, but if you keep your objects at reasonable speeds ...


2

Stumbled upon this post: http://www.gamedev.net/topic/605007-animation-transitions/ Interpolation doesn't work too well when the dot product of the two quaternions is less than 0. If this is the case, I just negate one of them and then do the slerp.


2

I'll quote my answer to this question, since it's basically the same thing - he's averaging compass angles while you're averaging hue angles, but the procedure's the same either way. You could convert each angle to a 2D vector and sum the vectors, then convert the result back to an angle. In pseudocode: totalVector = [0, 0] for each angle: ...


2

Compute two separate values: delta, the difference between your current value and your expected value; in your case, 4 - 5, ie. -1. step, the amount to change wrt. your speed, in your case 2 * Δt where Δt is your timestep (you appear to have a constant timestep Δt = 1, but if you want to cope with framerate jitter, you should consider adapting) If ...


2

In general, you should have an interpolation function f of any kind that satisfies: f(0) = 0; f(1) = 1; f(x) is continuous for all 0 < x < 1 (this can obviously be relaxed if you want jumps); 0 <= f(x) <= 1; and f(x) increasing for 0 < x < 1 (unless you want goofy effects). Ones that are computationally easier to do are ...


2

Quick answer: Z is not a linear function of (X', Y'), but 1/Z is. Since you interpolate linearly, you get correct results for 1/Z, but not for Z. You don't notice because as long as the comparison between Z1 and Z2 is correct, the zbuffer will do the right thing, even if both values are wrong. You will definitely notice when you add texture mapping (and to ...



Only top voted, non community-wiki answers of a minimum length are eligible