Hmm... I later spent ages trying to figure out why something else was happening: every so often, the player would appear to move below the surface of the tile it was supposed to stop on, then flick back to its proper position.
After much printing out and comparing values and repetitive testing, I found the collision function wasn't always testing against the right tiles. Specifically, in the case above, it was testing against the tile just above where it was supposed to and I wasn't sure why for a while...
Turned out, I wasn't factor in the delta when I was determining the end point for tiles to check against. I was adding the y velocity, say, instead of yvel * delta, so the collision detection function wasn't checking far enough.
So I changed it to:
float colBoxEnd = x + ( xvel * delta ) + w;
and the other 3 cases similarly (the other directions, that one is for moving right).
Now, after some testing last night and today, it seems that all of my collision problems are gone. I haven't been able to replicate that jittering ever since factoring in the delta.
I guess it must have been checking against the wrong tiles all along
Why position the player in case of collision at all ? If you do a look-ahead check that shouldn't be necessary.
Seemed like snapping to the closest valid position was a reasonable way of doing it.
Do you mean I should calculate the velocity required to put the player in that position instead?
I did try that before in a C++ game... I'm not sure what I went with in the end exactly. It took me ages to try a lot of different ways of getting the player to collide properly with moving enemies and in the end I just abandoned it and did things another way that was equally good or better gameplay-wise...
Why are 3. and 4. two separate steps ?
I did change that a bit... I put the gravity before the y collision checking because I realized that the new extra gravity of a frame wasn't being taken into account for collisions since it was being added after the collision checking
Well, you just answered your question as to why it's happening.
If you're checking collision at the goal you'll find, in step 2, that you'll be 'colliding' with that block and your repositioning code puts you to the right of it (Since that's the rules).
Except now I'm really quite confused as to why it seems to be working perfectly...
Hmmm... looking at the exact code now I think I might see why... the separate axis testing doesn't take into account the other axis' velocity. I think that would result in what I'm seeing... yeah, I think so.
IE- Distance from important character edge X to important block edge X, divided by the current velocity. Then distance from the character edge Y to block edge Y, divided by the current velocity. Since in both cases the distance will be less than your velocity, you will have a value between [0,1]. Compare the two. The lower one is the direction in which collision with that block will first happen. If they're the same, it's a going to be a perfect corner collision, and you should decide how that works.
Interesting... I'll try to remember how that works. I've had similar problems before.
After messing around trying all I can though... I'm pretty sure it's finally working now. Have to get used to Slick and remember to always put delta in appropriate places