Ashley: If I'm picking nits, then your solution is not ideal. It is noticeable when you need the player to be in a vertical tunnel and unable to move even the slightest amount to the left and right.
My custom engine (heavily borrowed from Damian's MMF2 code, but also from old-school engines) solves the problem like this:
1. player.Xspeed is set to a positive or negative number (in my example 2 or -2) for as long as you're holding down the right or left cursor key respectively.
Xspeed is a variable that 'charges up' the number of times the movement loop is going to run each tick. The higher this number (absolute value), the more times the movement loop is going to run, and the faster the movement is going to look.
2.
-Every Tick
--abs(xSpeed) is added to xLoopIndex, which is the number of times the movement loop is going to run each tick. So xSpeed more times for each tick.
3.
-if LoopIndex >= 1
--perform the "Xmovement" loop "xLoopIndex" times
---each time you perform the loop, move 'player' by exactly one pixel, in the direction of the movement, unless it's overlapping an obstacle, in which case set 'player' back one pixel and then stand still (xLoopIndex set to 0, xSpeed set to zero, and the loop doesn't run any more)
4.
Quite an important step: each tick, we need to deduct the number of times the loop has run from xLoopIndex on the last tick. We need to start each tick with a clean slate, we don't want the code to recalculate movement it's already calculated before. One way to do this would be to set xLoopIndex to 0, but this produces erratic movement.
In hindsight, this happens because xLoopIndex is not necessarily an integer at all times. By setting it to 0, we are discarding the decimals, without giving them a chance to add up to integers between ticks.
Therefore a better way to do it is to deduct only the integer portion of this value, and keep the decimals-if any- for the next tick. This can be stated like so: xLoopIndex = xLoopIndex - int(xLoopIndex)
Therefore: each time the loop runs, and 'player' isn't overlapping an obstacle, the engine moves 'player' for an integer number of pixels. If it hits an obstacle, it is pushed back by exactly one pixel, and since this happens before the loop ends, you never even see the overlap drawn on the screen.
And since the loop runs only as many times as necessary (that is, as long as you've pressed a cursor key for), the xPosition of the object is always known and controlled, and quantized to a pixel.
Not so with the built-in Platform behavior, which uses the bounding box collision to stop the movement when and only when it has to deal with the problem. My custom movement only moves 'player' by one pixel when there's a demand to do so, and pushes 'player' out of obstacles exactly once per loop, then kills loop.
Note that C2 *does* still register a collision at the entrance of a 25px tunnel, and *does* stop me moving down. But I took this in stride, as a very sharp collision detection algorithm.
This presented itself as a perfect 1-pixel gap around 'player' at all times, because a collission was detected 1 pixel before it occurred visually.
But since this gap was consistently and at all times exactly 1-pixel wide, it was the practical thing to do to just make the bounding box exactly 1 pixel smaller in all directions. Oversensitive collision solved, and since pixel-quantized control of 'player' is *already* also solved thanks to loops, the engine allows for pixel-quantized movement every time.
I'm a fake programmer, so I hope this made some sense to you.
I'm not sure I need a different built-in platform behavior or collision detection. The one we have works great for what I need. And collisions are working more than great, and are extremely reliable. I've done extensive tests.
Also, this has nothing to do with deficiencies in your code. Old-school platformers used to use loops all the time, didn't they? Construct is still miles ahead, since it allows me to focus on the essentials of game creation, instead of having to worry about collision algorithms and performance hits and the like. It's still pretty much plug-and-play.
Did I help any?..