Similar Posts

8 Comments

  1. FYI, your code lead to YoYoRunner app crash on macOS. GMS2 editor do not report any error, runner just crash. On Windows it works ok, as expected. Probably you discovered gamemaker engine implementation bug on macOS.
    This happens in player step -> move_x -> slope_move -> move_y, when we return zero from move_y, trying to go up on slope, but get stopped by solid object above us. Exact crash happens on line 12 slope_move when we subtract _xdir from x to go back.

    How far you plan to go? Do you plan to implement one way slopes? Solid platforms that can push and move player? Pushable (by player & platforms & other boxes) boxes? Combination of all of this? Boxes on boxes on moving platforms that can be properly pushed by other platforms and also push player, etc.
    And (most importantly) all of this properly synchronized with sub-pixel movement of sprites? Without noticeable jitter? Keeping good performance?
    I tried do this, but gave up. Personally, I found this unsolvable in Gamemaker. Integral nature of collision resolution in Gamemaker is not well matched with smooth sprite movement.
    Good luck with your project, it is interesting to observe its progress.

    BTW, comment in on_ground script say: “return instance_id of the colliding ground object or noone if not colliding”, but I think it always return boolean value, true or false.

    1. Hey dmitry, thanks for stopping by and letting me know about it. Have you already opened a ticket with YoYo? otherwise I could do it, let me know.

      Regarding the project, I think moving platforms pushing multiple stacked (and pushable by player) objects could be within my reach. I might try the one way slope thing as well but it’s gonna take some time (because of my day to day job). This weekend I’ll give it a shot.

      As you noticed yourself, when dealing with something like that (moving stuff mainly) it’s important to take care of the order of execution so I will spend some extra time dealing with those issues. For that reason though, the subpixel movement, although present on my todo list, will be postponed a little. I want to get the collisions and the execution order right. Then I’ll deal with the subpixel drawing. I think it’s completely possible to do that and I’m committed to find a (sane) way to do all that.

      As for the wrong comment in the script, you’re right, it returns true/false. I fixed the download link with the correct code. Thanks for noticing it; much appreciated. Please let me know if you notice other oddities, typos or plain wrong code. Thank you

  2. >>>Have you already opened a ticket with YoYo?<<>>I want to get the collisions and the execution order right. Then I’ll deal with the subpixel drawing.<<<
    Ok. In my opinion when we dealing with moving stuff which can push & carry each other, proper subpixel movement is the most hardest part (and the challenge, present only in Gamemaker, unfortunately).

  3. Oh, the site broke my reply, so I repost it again.

    “Have you already opened a ticket with YoYo?”
    No. If you allow me to send full project (as a repro case) to YoYo I will do that.

    “I want to get the collisions and the execution order right. Then I’ll deal with the subpixel drawing.”
    Ok. In my opinion when we dealing with moving stuff which can push & carry each other, proper subpixel movement is the most hardest part (and the challenge, present only in gamemaker, unfortunately).

    1. Of course you can attach the full project; it’s basically public. I’d open the ticket myself but I don’t have a Mac and I wouldn’t know what details to provide.

      I’ll try very hard to get all those subpixel movement right in the next iterations. We’ll see how it goes.

    1. Thanks! I wish I could put more time into it 🙂 Anyway soon there’s gonna be a new article 🙂

  4. Thanks for doing all this – I’m learning loads of great stuff!
    I found one little bug in this – if you take a slope block and stretch it vertically so it’s extra steep, then try walking up it, you end up kind of walking into it instead of sticking to the top. This looks to be because in slope_move(), we check once if we’re “in the slope”, and then just move up a pixel. This isn’t enough to push you to the top of the steep slope though, so all I did was change the first if to a while.
    This might cause problems later, but for now it’s fine. Anyway, this behaviour is a bit weird because now you whiz up the slope really quickly, so later down the line I doubt anyone would want this!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.