[Solved] pixel-perfect platform engine using loops

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 <font size="6">sinks</font> 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:

https://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)

https://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.

christina

The collision box of your sprites are the exactly same on all the frames?

The sink symptom is looking like a issue with different collision polygons I had a time ago.

If yes, I concern you to use the animation sprite as animations only, and pin them to an invisible square sprite object, with the collision polygons set to the size you want, so, you can make all your code to work for the invisible sprite and set everything else, like animations, to be pin on that.

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!

Haha ! It was nothing really ! <img src="smileys/smiley9.gif" border="0" align="middle" /> I could have just used abs() in the loops condition but I didn't like the idea of having index variables possibly taking negative values... <img src="smileys/smiley36.gif" border="0" align="middle" />

Nice work with the engine, looking forward to seeing it in action !

christina - I don't see a link to a .capx using the platform behavior with no third party plugins. The link in your last post uses a custom movement.

Pixel "sinking" in the built-in platform movement should be considered a bug. I really want to discourage "custom" engines, because a much better solution is to improve the built-in movement to do what you want, instead of making you reinvent a whole complicated engine.

For the record, I tried your custom platform movement example, deleted all the events, added the platform behavior, and corrected the collision mask so it's bounding box (it appears to be set to one pixel sunk in). It was pixel perfect, I couldn't find any sinking issues that you describe at all.

Ashley what did you have to do to the bounding box? Just adjust it in the sprite editor visually?

Just right click, set to bounding box. That's the default collision polygon, it looks like that object was deliberately altered to have a one pixel sunk in collision mask.

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

christina - that .capx still uses the Sprite Font plugin.

Ashley Apologies! Here's the one

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

christina - where do you see seams in that example? I don't see any.

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.

It's just that exact-sized gaps can't be moved through by the Platform behavior. If you shrink the bounding box it's still pixel perfect, but since the object can move further it shows a gap. Everything's working correctly and by design so far. (The player starts in the air because you placed them inside a solid, which confuses the behavior; place them over an empty space and they'll fall right down and work properly.)

Since you use pixel rounding, you can probably get away with making the bounding box just a tiny fraction of a pixel shorter horizontally and vertically. This will never let the player appear a pixel out of place, but still allow them to pass through exact sized gaps.

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