This sounds like it would actually solve a bunch of problems I was having with a particular game. Partly because I just didn't fully understand how bounding boxes worked before.
Dude I’m ngl I haven’t watched ur vids since like 2014/2015 and this randomly popped up in my feed. I haven’t even done game developing since then thats wild I had no idea you still made content! :)
My last game i was flipping the image_x_scale whenever the player turned around, and realized it would for whatever reason make it get stuck in walls, this was why. And now it's fixed woo
i recently started learning GMS this past month after getting my year license from humble bundle. You were one of the first tutorial channels i got reccmended to watch from a facebook group i joined. :)
This is such a good addition and will really make collision a much simpler task for people. I was trying to make moving platforms the other day and they just werent working. Apparently its because I had collision compatability mode now. Floats are certainly much more flexible.
This is a plus - it allows for some more precise collision checking on our part (Dark Souls?). I've tested the new system and what you've mentioned is right. It works much closer to how other engines (Unity, Godot, etc) check for collisions which may make the transition between engines much easier. It might be worthwhile looking into teaching these guys some AABB?
Thanks for the update Shaun! Though, I'm left wondering if you have any recommendations for fixing off-by-one errors when using bbox_bottom and bbox_right outside of just turning on the compatibility mode.
I would just use the compatibility mode if its code you've already written. For future code... it sort of depends which functions you're using and whether or not the tolerance value is being applied which is unfortunately a bit unclear on YoYo's end without doing a bunch of different tests. But generally it just means you might have to move one pixel more, or move to the site *of* the collision rather than the pixel before the collision as we used to. It really depends exactly what you're doing.
Hey Shaun. I know this video is a lil old now but I hope you're still reading the comments here. I used your slopes/tile tutorial and came up with a quick (and dirty) solution to the off by one pixel problem. I replaced all "bbox_right" instances with "(bbox_right - 1)". I did the same with "bbox_bottom". Is this a good solution in the long term?
hey, I started to code in gamemaker recently and I found uot your channel and been seeing basically all of the videos, in the past video you show a RTS game you make, I wonder if it's possible that maybe you do it a series of tutorial, I always wanted to make a RTS game
So is this the kind of update I shouldn't add to a GameMaker project I've been working on for a while? Or do you think the compatibility is 100% good enough?
Generally this won't help with things getting "stuck", if they got stuck then collision ended up overlapping somehow. Most of the issues this fixes are where collisions and rendering don't match up, so you're technically not touching the floor but you're some decimal amount into the pixel above the floor that you render one pixel inside it, and so on.
I followed your Platformer tutorial for my game, would I need to change anything? I used your "if -while" method (just like in the video). I asked primarily because you do not use bbox and I see that this change affects bbox.
Does subtracting -1 to bbox_right and bbox_bottom and using round() on all sides generally produce the same result as the old way? Maybe floor() would work better?
For some of them it will. The slopes/tiles one in particular. I'll be redoing them in the future, for now they can be followed though if you use the compatibility mode in global game settings.
If your deep into a project is it generally better not to update, due to the possibility of it messing up the project in a way that will (for the lack of a better word) "corrupt" your project??
If you're backing up your project or using source control then "corruption" is never a concern. If something goes wrong you can roll back your GM version and project appropriately. But under some circumstances, yes you might not want to update just because of fundamental changes that are hard to bring the project in line with. An example of this was when a large number of GML changes, structs, etc came in 2.2 and would require you to rewrite large chunks of the project. It's kind of a case by case thing.
For me, GM1.4999 is allright with me! Just like photoshop, I still use CS3.. Software developers always add too much prefab stuff and too many options, but isn't it about the developer what he can squeeze out of a basic and solid framework? 'Cut away the unessential'
Unfortunately, I found your tilemap collision tutorial to be too confusing and when trying to adapt it to a slightly different model (a beat em up with x/y movement like say Double Dragon) it was really buggy.
finally no more collision issues for making platformers
haha good one
Hi there, 2024 here, there's still problems.... Back to your wonderfully blissful past!
i recently started using GMS and i already had a lot of problems dealing with that collision issue. here's hoping my troubles will come to an end!
This sounds like it would actually solve a bunch of problems I was having with a particular game. Partly because I just didn't fully understand how bounding boxes worked before.
Dude I’m ngl I haven’t watched ur vids since like 2014/2015 and this randomly popped up in my feed. I haven’t even done game developing since then thats wild I had no idea you still made content! :)
Even if it does mean reworking anything, the thing will be much better for it. Thanks for posting. 👍
My last game i was flipping the image_x_scale whenever the player turned around, and realized it would for whatever reason make it get stuck in walls, this was why. And now it's fixed woo
oh my god! finally! That's great news! Hope they also apply this to the sprite origin point
i recently started learning GMS this past month after getting my year license from humble bundle. You were one of the first tutorial channels i got reccmended to watch from a facebook group i joined. :)
Thanks for the update, Shaun!
I'm glad I saw this video before updating GMS, as I generally just worked with what game maker did
This is such a good addition and will really make collision a much simpler task for people. I was trying to make moving platforms the other day and they just werent working. Apparently its because I had collision compatability mode now. Floats are certainly much more flexible.
FINALLY, I would spend days trying to prefect collision. It was nearly impossible..
This is a plus - it allows for some more precise collision checking on our part (Dark Souls?). I've tested the new system and what you've mentioned is right. It works much closer to how other engines (Unity, Godot, etc) check for collisions which may make the transition between engines much easier. It might be worthwhile looking into teaching these guys some AABB?
Wow this'll help a ton! Ok I'm downloading pronto.
YESSSS
Thanks for the update good sir
Awesome, time to redo my entire game 🤯
Thanks for the update Shaun! Though, I'm left wondering if you have any recommendations for fixing off-by-one errors when using bbox_bottom and bbox_right outside of just turning on the compatibility mode.
I would just use the compatibility mode if its code you've already written.
For future code... it sort of depends which functions you're using and whether or not the tolerance value is being applied which is unfortunately a bit unclear on YoYo's end
without doing a bunch of different tests.
But generally it just means you might have to move one pixel more, or move to the site *of* the collision rather than the pixel before the collision as we used to. It really depends exactly what you're doing.
thanks for the video!
I am hoping it's truly stable. I stopped updating like 8 months ago because every new official release introduced a new bug in the IDE.
Hey Shaun. I know this video is a lil old now but I hope you're still reading the comments here. I used your slopes/tile tutorial and came up with a quick (and dirty) solution to the off by one pixel problem. I replaced all "bbox_right" instances with "(bbox_right - 1)". I did the same with "bbox_bottom". Is this a good solution in the long term?
Nice
hey, I started to code in gamemaker recently and I found uot your channel and been seeing basically all of the videos, in the past video you show a RTS game you make, I wonder if it's possible that maybe you do it a series of tutorial, I always wanted to make a RTS game
So is this the kind of update I shouldn't add to a GameMaker project I've been working on for a while? Or do you think the compatibility is 100% good enough?
Yeah just use the compatibility mode.
I'm still a noob after dabbling with GM for years, I wonder if this will make my older projects have less issues with characters getting stuck.
Generally this won't help with things getting "stuck", if they got stuck then collision ended up overlapping somehow. Most of the issues this fixes are where collisions and rendering don't match up, so you're technically not touching the floor but you're some decimal amount into the pixel above the floor that you render one pixel inside it, and so on.
I followed your Platformer tutorial for my game, would I need to change anything? I used your "if -while" method (just like in the video). I asked primarily because you do not use bbox and I see that this change affects bbox.
Generally speaking no, if anything you should see less issues with that now rather than more.
Does subtracting -1 to bbox_right and bbox_bottom and using round() on all sides generally produce the same result as the old way? Maybe floor() would work better?
does this change your collision system? of the tutorials
For some of them it will. The slopes/tiles one in particular. I'll be redoing them in the future, for now they can be followed though if you use the compatibility mode in global game settings.
@@SaraSpalding thank you , your videos are great
Common sense starting to prevail in 2022! The future is finally here!
If your deep into a project is it generally better not to update, due to the possibility of it messing up the project in a way that will (for the lack of a better word) "corrupt" your project??
If you're backing up your project or using source control then "corruption" is never a concern. If something goes wrong you can roll back your GM version and project appropriately.
But under some circumstances, yes you might not want to update just because of fundamental changes that are hard to bring the project in line with. An example of this was when a large number of GML changes, structs, etc came in 2.2 and would require you to rewrite large chunks of the project. It's kind of a case by case thing.
@@SaraSpalding thank you, that was extremely helpful.
You're awesome!!!
oh thank god, we are saved! the pain of collision masks are over!
This is why collisions should be resolved with math and not "while loops". Far faster and accurate before and after this change.
ok
did they add cropping sprites yet? it's literally all i care about
Can't you just use draw_sprite_part?
For me, GM1.4999 is allright with me! Just like photoshop, I still use CS3..
Software developers always add too much prefab stuff and too many options, but isn't it about the developer what he
can squeeze out of a basic and solid framework? 'Cut away the unessential'
Unfortunately, I found your tilemap collision tutorial to be too confusing and when trying to adapt it to a slightly different model (a beat em up with x/y movement like say Double Dragon) it was really buggy.
Well I guess it's fortunate really as it doesn't work properly with the new bounding boxes anyway!
1st view haha