Topic: GameMaker users, you may use sprite_collision_mask() now

[TheouAegis]

The manual says it doesn't work right. Today I was like, "why the hell doesn't it work right?" It works just fine if you use 0 (automatic) or 1 (full) for the bounding box type, but not if you use 2 (manual). I was like, "why is this?" Then it occurred to me, Mark programmed in X,Y pairs -- left,top and right,bottom. This is how you specify the vertices of a rectangle in a lot of functions in GM. But with sprite_collision_mask, you specify the vertices of the bounding box by left,right and top,bottom -- at least according to the manual and the function description that appears at the bottom of the window in GM.

Drawing a sprite's bounding box and running in debug mode, I tried using sprite_collision_mask() on that sprite to see what kind of bugs occur. I was expecting to see the bounding box just disappear or become a little pixel. When I tested with a FULL box type, it worked just fine. When I tried to use sprite_collision_mask(sprite_index,0,2,0,31,8,31,1,0) to draw the sprite with the top of the bounding box 8 pixels lower, the issue was obvious. So I tried again, swapping bbright's value with bbtop's and it worked just fine.

So long story short, to use sprite_collision_mask( ) with manually adjusted vertices, remember that in GameMaker, TOP always comes before RIGHT.


... With that said, I still don't see any really good reason to use it with an active sprite. Maybe in an isometric game, where the shape of the bbox changes with each frame and you want to avoid flooding the game with extra sprites that function solely for collisions. ... So why was I messing with it? ... Trying to simulate a bug in CV3.... 

[Gunlord]

Coding is hard...;_;

[TheouAegis]

Ha ha, I hate myself. Oh well, learn what you can.

The bug from CV3 I was trying to recreate was exactly what I suspected it was. I can still use sprite_collision_mask( ) to simulate it, but technically I should be using an invisible sprite with a bounding box (god, I hate those, so wasteful) while drawing everything to the background. That's a lot more work and I was hoping to avoid that by cheating. With GM's limitations, it's one of the aspects of the NES I can't simulate:

The crushers - those spiked platforms that slam down then slowly go back up - are actually background entities. They're controlled by an invisible object that draws to the background. So whatever palette is currently assigned to the name table is the palette used by the crusher (you can see this if you open ReVamp, go to Sypha's stage, and move the crushers left or right - green crushers are cool looking). You can't do that in GM. Further more, the object that you stand on when you jump on a crusher has an offset range from what is drawn. A crusher background might move from y:64 to y:128, but the invisible platform object will move from y:56 to y:128. What this means is when the crusher is at its peak, you're not actually standing on it, and when it's at its lowest, you're actually standing on it. So when it moves up, you're on it, but when it drops down, you're not on it. And I decided to cheat and just treat it as a sprite instead of as a tile. It wasn't so much that I was lazy, but that it would require a sprite for the crusher's object AND a set of background tiles for the crusher's visuals.

With that said, my crusher turned out pretty darned well, if I do say so myself. And I do.