Magistross thanks for taking the time. Could you share your .capx? Because I tried the same yesterday, and it ruined xSpeed for some reason (-3 going left, +2 going right)and also introduced a 1-pixel gap again. You can see it if you drive 'player' in a corner and keep pushing: it sinks one (or half) a pixel in.

<img src="https://dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/platform.jpg" border="0" />

Ashley

Thanks for taking the time. So, this is the built-in (and awesome, don't get me wrong) platform movement:

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/C2platformmovement.capx

When the 'player' bounding box is 25x25px, 'player' doesn't even move.

When the 'player' bounding box is 23x23, 'player' moves ok, but again, the 1-pixel gap makes its appearance.

<img src="https://dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/platform.jpg" border="0" />

And this is my implementation which works without a glitch always, except when introducing dt (although Magistross may be on to something)

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/jumpy2.capx

It does all I want it to do, and takes advantage of C2's inbuilt bounding box and overlap functions, so your code is definitely not going to waste.

I think this (http://www.scirra.com/FORUM/the-big-timedelta-headache_topic35671_page1.html ) discussion is really really pertinent to the problem, but I can't really parse the ConstructClassic-specific ideas, since I know things are different with C2. I do hope I'm not making a nuisance of myself.

newt: You're probably right. Thanks! I don't mind basing an engine on odd size tiles at all, I was just puzzled

I should also mention, the code only works correctly for odd pixel sizes. For example 25 works, 26 doesn't

Hmm.

This is very weird.

Can anyone confirm this?

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/test%20movement%20with%20actual%20loop.capx

I've set the (25x25pixel) player's bounding box to be 23x23, providing 1 pixel of padding (otherwise player is stuck) The code works great, all collisions are pixel perfect.

If I change lines 12-15 to take dt into account,

(for example if I change 'Set Xdirection to 1' into 'Set Xdirection to 60*dt'), collisions become very erratic. There's a random pixel-wide gap between 'player' and platforms/walls. And if I reset the 'player' bounding box to 25x25, 'player' doesn't move at all, possibly because the condition for standing still is satisfied (i.e. don't make a move if moving will result in overlapping a platform)

Does anyone know the inner workings of this? I suspect it's the collision detection, but I may be missing something in code.

I can't stress this enough: the code runs *perfectly* when I leave dt out of it. Ashley? Someone? No rush, I'm just obsessed with finding out if it can be helped. If not, does anyone know if it is a logical compromise to leave dt out of a game? Would it be game-breaking?

Thanks in advance

don't sell yourself short, you pretty much solved this one! And it needs just one event!

if player is overlapping platform

and FramePlaying=/=0 -> set player.Y -=1

I think this is quite a robust engine already. Now if we could figure why dt is so unpredictable with this one...

Hi retrodude, thanks for the welcome.

Yes, I'm trying to make "player" climb that big step just by going to the right.

Hmmm just had an idea.. Maybe I can make a high bump detector sprite and a low bump detector sprite... If the high *and* low bump detectors are overlapping an obstacle, then don't let "player" move. But if only the low bump detector sprite overlaps an obstacle, then assume it's a step and stand on it. So "player" can tell the difference between a wall and a step. I'll test this!

What was your idea?

Edit: oh I see! You made a smaller step, on frame 2 of the platform animation. OK, how does this help? Do a check of if FramePlaying=2 -> set player.Y -=1 ?

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/jumpy2.capx

It worked!!! This is so cool, thank you retrodude!!

EDIT. SOLVED thanks to Magistross and retrodude and newt:

.capx

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/jumpy3.capx

playable here:

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/index.html

____________________________

Hi everyone!

I'm Christina. Long time lurker, first time posting.

I've been disappointed with the lack of pixel-perfect controls in Construct2, since I have my sights on making a simple metroidvania as practice, and I really need to save time by using small pixelart sprites.

This (http://69.24.73.172/scirra/forum/viewtopic.php?f=8&t=1095) custom platform engine by Kayin is awesome , but when translated into C2, it suffers from the 1-pixel inaccuracy problem (http://www.scirra.com/forum/platform-object-sinks-into-solid-ground-bug_topic57004.html)

I managed to find an old trustworthy MMF2 method by Damian (http://damiansgames.com/post/6923285368/making-a-platformer-in-multimedia-fusion-2-or-games) and successfully ported it into C2.

I had to make the player sprite's bounding box one pixel smaller on each side (player sprite is 25x25px, player bounding box is 23x23px), but other than that it works great. I'm sure I could clean it up a little, especially those "direction" variables.

If anyone wants to take a look, the project is here

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/index.html

and .capx is here

dl.dropbox.com/u/28087823/Construct%20Examples/pixel-perfect%20engine%20with%20loops%20-%20no%20slope/test%20movement%20with%20actual%20loop.capx

So!

1st Question: is there any way to implement slopes in an engine like this? I mean small, 1-pixel steps, that the player sprite can climb, like Kayin's. Check the .capx , that small pixel-high bump on the floor is enough to completely stop the player sprite - which is good, it means pixel-perfect collisions are working. I tried using a slopeDetector sprite, but it kept thinking the walls were slopes. Perhaps I'm missing something.

2nd question: does anyone know why this engine won't play nice with dt? I tried introducing 60*dt instead of 1px steps and movement immediately becomes erratic. Jump strength becomes random as well. Does using pixel-perfect collision loops come at a price?

Glad to be here :)