Ashley plus I was thinking: it's not that complicated a code either, and it also simultaneously takes care of direction of animation.

If you'd rather you found an official workaround, I'm fine with it as well. Are you averse to me posting this as a fully commented example on the forum?

On the off-chance that someone is looking for a loop-based engine, since old-school games are often about that. I will comply whatever your decision.

Ashley That's good to know, thank you for taking all the time to help. I don't doubt the pixel-perfectness of the platform behavior, in fact it's proven itself. I'm just skeptical if it can do what I want it to do with the same accuracy and reproduceability.

Unfortunately, random behavior increased a lot when I did what you suggest. At least now we're closing in on the real issue.

This is the bounding box I used, just a fraction of a pixel smaller than 25x25px (I made a lot of different sized bounding box tests, all produced the same result)

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

(If you're certain a specific decimal will work, and I just haven't found it, then maybe we need decimal input support for the bounding box coordinates? I too discovered the cool properties of non-integer bounding boxes while making tests for my engine)

The problem is this; the 'player' sprite just stuck there for no reason for a good while and then dropped

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

Or even actively stayed on the wall, while I was pressing up and right;

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

These are all problems that got solved when working with loops...

Ashley: no, no seams. There were never any. But two things:

1. ['player' starts off floating like this:] (edit: this was my bad)

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

2. 'player' can't get past this narrow corridor, is obstructed by the ceiling. Everything is laid out according to a 25x25px grid, so 'player' ought to be able to just squeeze through there.

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

It *can* apparently be fixed by making the bounding box one pixel shorter vertically, ending up with a 25x24px bounding box for a 25x25px sprite. But the same problem exists horizontally: 'player' can't squeeze through vertical corridors 25px wide, like so:

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

Which you'd argue can be fixed by making the bounding box one pixel shorter lengthwise. But it can't, because if I do that, then this happens: (one pixel gap)

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

Is this reproducible? Should I file a bug report? I'm fine with making a complicated engine that's tailor-made for my needs, I don't want to pile more work on your shoulders.

Ashley Apologies! Here's the one

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

Ashley I'm probably doing something wrong. I'd love to see your .capx

here's mine, with the built-in behavior:

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

Magistross that was *brilliant*. Thank you! What a stroke of genius, adding abs() right there! I think we can upload this engine as a tutorial/example. I'll fully annotate it and give credit to you, retrodude, newt and Damian. What do you think?

.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

Ashley apologies! Please check the new .capx directly above. Pixel perfect in every single aspect, and thanks to Magistross, framerate independent. Supports slopes (by using curved bounding boxes) and ledges you can grab on to.

Screenshot comparison. This is the built-in platform behaviour (notice the sprite having sunk 1 pixel to the right and one pixel toward the bottom)

<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 the pixel-perfect implementation without any sinking pixels

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

TELLES0808 great pixelart by the way :) No, the sinking problem is just the 25x25px 'player' sprite using the platform behaviour. It's not animated, and it's only a placeholder that will be invisible. The animated sprite will, as you say, be pinned on this 'player' sprite.

Thank you all!

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!!