"Is by wall" condition doesn't work due to gap

I've been trying to figure out why my events with the "is by wall" condition haven't been working 100%, but then when I made my detectors visible I noticed that the detectors with the platform behaviour weren't always touching the wall -- even when you are trying to slam against it! There is sometimes a gap of 1 or 2 pixels, when it is a 2 pixel wide gap that's when I notice the "is by wall" condition not working.

I'm wondering if it is possible to remove this gap, or if possible to increase the detection size of the wall by another pixel (or have it variable)?

I accidently closed the first example I made which revealed the "bug" more frequently, but this new one I made only does a gap of 1 pixel on the left (the gap usually varies between 0/1/2 wide). But at least you can see it has a gap between player and wall:

http://dl.dropbox.com/u/1024727/c2/gap.capx

The gaps probably appear due to sub-pixel rendering and your unusual control system. If the hotspot is centered and the object as an odd width/height, this makes the object edges land between pixels, e.g. a 5x5 object with a centered hotspot (at 2.5 x 2.5) placed at (10, 10) has its right edge at X = 12.5. Since Platform only works to the nearest pixel it leaves a half-pixel gap which can appear as a narrow space.

Secondly why do you set the vector manually instead of using the control system? The Platform behavior wasn't designed to be controlled that way and it seems the push-out algorithm leaves a gap. If I set it back to default controls and disable your events it doesn't leave a gap. I'm not sure why it leaves a gap your way, but wouldn't it fix it to just use the behavior's control system?

Still, for the next build I've increased the is-by-wall detection to 2px.

Yeah I'm using even numbers and bottom-middle alligned hotspot for detection.

I didn't realize it was bad to do it "manually". I initially preferred to just use the vector as it feels more "in control" and simpler to just do -400 to move left and say -800 when dashing left, however I guess I may as well try and use the "simulate control" thing and just adjust maximum speeds and see how that goes. It also didn't feel as "snappy" when using "default controls", but that was probably just because I didn't have a very large acceleration value. The main reasons I don't use default controls because in the future I'm going to be adding customizable controls options, and in-case more input options are available later (such as gamepads).

Also, thanks for the increased size. :)

I've just tried using "simulate controls" to do movement and it works well, I'm still occasionally getting an issue with the condition but I'm not sure if its still the gap issue or not. Hopefully that 2 pixel gap detection for "is by wall" change will help though!

I am experiencing the same bug as alspal -- I have a sprite that contains an instance variable named "direction", I am simulating platform press right/left (depending on value of "direction") to move the sprite, and changing the value of "direction" depending on whether the sprite is next to a wall on the right/left. It usually works fine, but about 1 in 20 times the sprite gets stuck with a 1 or 2 pixel gap. I'm looking forward to the 2 pixel gap detection fix!

Figure out a kind of fix for this problem: to decrease the gap and therefore trigger the "next to wall" condition, on every tick I add to the sprite's X position dt * direction, where direction is a number variable, equal to 1 if the sprite is moving right, -1 if moving left. Hope this helps others as well!

stemkoski, have you tried r75?

Ashley -- just downloaded and tried out r75, it works perfectly now. Thank you!

Great, closing as fixed.