Thndr's Forum Posts

  • Well figured out another work around for it, unsure if it'll pose an issue down the line but it works.

    All I did was because the bounding box tries to autofit 1 pixel larger than the sprite, move the collision box 0.5 pixels down and it always auto-rounds to be on top of the tile sprite. (had to modify the top to make sure it collided right as well)

    dl.dropbox.com/u/73774002/gbstyle_demo.capx

    Seems like it'll work well, although unsure how much of a hassle it'll be to make sure all the collision boxes are the same and how it'll work in the end. I wish there was accurate positioning rather than approximate position though :(.

    I assume I am doing it right for tileset based platforming, with sprites at different animation stages being marked as solid?

  • Ah, so the collision is more of an approximation than it is an actual value, even at low speeds.

    Looked around and I guess unless I get a custom platform engine to do my work, there isn't really any solution since I'm working with low resolution and the engine physically displaces the sprite into the solid objects (meaning if I had it 23.5x pixels tall it doesn't go through a 24 pixel tall hole unless it's into the ground a little bit, which happens when you land 50% of the time)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I was messing around with the collision polygon thing, make the box take up roughly 0.5 pixels less than the sprite itself.

    When the sprite is into the ground, it goes through the 24x high hole, but when it's standing on the ground, it doesn't go into the hole. I believe all of this is related. Going to mess with the fall rate to see if it's "going to fast" and the game doesn't catch it in time. Edit: Nope, still happens at Fall Speed 2

    Unsure why it would make the player sprite intersect with the solid tile 1 pixel.

    I know what I'm trying to make is rather low resolution, but depending on how it's working I might just have to mess around in GameMakerStudio instead of Construct 2. Wanted to make an HTML 5 game with the Awesomium wrapper run natively or in a browser, along with learn some Javascript instead of some custom language (GML). Maybe if my project wasn't so strict on pixel interactions :(

  • The first one was made with the construct beta, and the 2nd one isn't even a modification of the file I posted. :(

    I could easily make the sprite smaller itself, but I was considering the fact that if I have a 24 pixel high hole, a 24 pixel high object should just slide through. Plus with how it's designed, I'm not going to make the sprite smaller.

    What I would consider a good work-around is keeping the same sprite size but making the collision box for it smaller somehow. I could actually use that sort of thing for gameplay dynamics

    EDIT: Found it, it was under Sprite then it was the option below ORIGIN, Collision Polygon. Still find it weird that a 24x high sprite can't fit into a 24x high hole.

    Also why does the sprite when you jump sometimes go into the ground 1 pixel? (turned on pixel rounding to make it more apparent)

  • I made a small proof of concept demo and I seem to be having a couple issues with collision

    dl.dropbox.com/u/73774002/gbstyle_demo.capx

    I have the sprite 16x24, and the tiles are 8x8. The sprite does not go into the hole between the solid tiles nor do they go along the path. (I don't plan on having them that small in an actual game, just for this demo)

    The sprite also sometimes appears to take the space of the top pixel of the tile objects as well. Anyway to fix that?

    One of my thoughts was making a custom collision box for the sprite (and sloped tiles) but in a brief passthrough I didn't see anything of that sort. While it's a work around, I would also use a custom collision box for gameplay dynamics as well.