Ashley's Forum Posts

  • Let a zombie bite you. If you can't beat 'em, join 'em.

  • Lots of programs go for a sort of 2D flowchart view. I never liked it. Moving things around in 2D takes up way too much screen real estate. Lots of other programs do it that way as well (e.g. Unity's new PlayMaker thing, and Scratch and its derivatives like Google Android App Maker and Stencyl), so I don't think Construct has anything to gain by doing that.

  • OK, I'll work on global/local variables for the next build and maybe something to improve collisions a little bit, although not full fine collisions just yet.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • That would be a possible solution, yeah. Not sure that Classic does that though because I did seem to be able to reproduce the issue. I think the nearest-pixel-hotspot would be good for C2 if Classic doesn't.

  • The "pixel float" problem is this:

    • the editor places objects at integer coordinates by default
    • objects have a centred hot spot by default
    • objects with an odd width or height therefore actually end on a half-pixel
    • the platform movement push-out algorithm only works to the nearest whole pixel

    This is the same in both Classic and C2.

    For example a 15x15 solid block placed at (50, 50) with a centred hotspot actually extends from (42.5, 42.5) to (57.5, 57.5). That's exactly what you asked for, it's just the math means its edges land midway between pixels.

    The way the platform movement works is like this: when you are falling, you are actually teleporting small distances every tick. When you land on a solid, at first the object doesn't land perfectly on top - it ends up lodged some way inside a solid. The platform movement notices this and starts what's called a 'push-out': it moves the object up one pixel at a time until it's no longer overlapping a solid. Now the player has landed perfectly on top of the solid, but to the nearest pixel.

    This means the platform movement floats only half a pixel above solid objects with a centred hotspot and an odd number for height.

    Then, it's the whim of the renderer how this is displayed: it may round it one way, and there is no gap. It may round it the other way, and there's a whole pixel gap. It may support sub-pixel rendering, which results in a gap which is a 50% blend of the background and the floor colour, which still looks like a gap, but fainter.

    In short, everything is working correctly, but the results are not always consistent or intuitive.

    As I said it's the same way in Construct Classic. It seems pretty minor so I'm tempted to let it go - the solution is pretty tough as well, considering you can floating-point position objects to be, say, 0.117 of the way between two pixels. Getting the push-out algorithm to detect this exactly is tough. It seems better to say it will land you within 1 pixel of the floor. It seems to have done the job OK in Classic. Does that sound OK? Has anyone actually had real problems with the sub-pixel float in games they've made in Classic?

  • You do not have permission to view this post

  • You do not have permission to view this post

  • I just tried in Classic, and its platform movement has the same bug. Nobody seemed to notice it there...! It's only ever a gap of less than a pixel.

  • Joshiii-Kun, that's cool, but did you see the new platform behavior in release 35?

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post