New answers tagged platformer
1
Don't collide against inner edges. A simple pass over your tiles can determine if the tile borders an open space on any particular edge. Set a glag for each edge in a given tile marking if its an outer edge (collideable) or inner edge (ignored).
One nice trick while testing this and other physics is to have a debug draw mode that renders all outer edges. ...
1
Now that you are implementing the physics on your own, as well as the collision code, I think the best answer lies within this tutorial. After the effect from the collision is calculated, you just consider the closest edge based on the average X position.
1
Ok, i'm assuming your existing collision detection has determined that a corner collision has occurred and the only question that remains is "Which edge hit first".
This is equivalent to the question "which has been inside the edge the least time". This is because if you imagine the edge as being an infinite length then for a collision to occure between ...
2
First of all: Don't just block user input as done by some games. It creates bad user experiences. One popular example: "What a horrible night to have a curse." (Castlevania II - Simon's Quest if you didn't know it. Lookup the Angry Video Game Nerd's review on YouTube. You'll get what I'm talking about.)
For dialog/story elements or tutorials the user should ...
1
A good way of keeping users from making a dialogue choice or skipping by accident is to not allow the choice for a period after it has appeared. Depending on the seriousness of making the mistake you should choose a time somewhere in the 2 to 5 seconds range. Having a visual cue about what is going on is usually best as it informs the user that your ...
0
Thanks to the contributors who answered this.
I went with my own solution in the end because it was simply enough to implement and gave perfect results.
All I had to do to scale the acceleration, was the following:
float fallAccel=(dt * num); //Where num is any arbitary amount and dt is the delta time between frames (hence it is scaled and also ...
3
Part of the problem is that your notion of 'velocity' isn't physical. Your updating of position is fine:
spriteYReal = spriteYReal + (spriteYVel * dt);
sprite.yScreen=(int) (spriteYReal*r.height);
This just says that the sprite's position is computed as Pnew = Pold+V*dt, which is fine - it means that V=dP/dt, which is correct. The problem is that the ...
0
Physics update rate must be independent from rendering frame rate. Becase it's not exactly 60 fps.
void update( float dt )
{
float maxStep = 1/60.0f;
if (dt > 0.25)
dt = 0.25f; // note: max frame time to avoid spiral of death
accumulator_ += dt;
while (accumulator_ >= maxStep) {
physical_world_->Step(maxStep);
...
1
First of all, let me say that most calculations were done with integer maths because without FPUs real values were slooooooow.
I'd say that in the vast majority of cases it would be axis aligned rectangles, simply because that is the fastest way, which as Seth pointed out, is just a special case of separate axis testing.
In some cases collisions would be ...
Top 50 recent answers are included
