Log in with to leave a comment.

Hi Yal, thanks for making this. I know it's "old" but it really helped me in my learning journey with using 3D in Game Maker.

If possible I need a little help with something: I'm trying to make it so the sprite that generates "slopes/ramps" can have any image_angle value and still work as a ramp from that direction.

I have the code to create vertex buffers for the slope at any angle so that aspect works fine and generated 3D model is nicely rotated. But I can't figure out how I can use this so the collision with ramp works properly at any angle.

This is your code for ramp collision that should return player's z position on the ramp:

function func_CollisionTopSlanted(xx, yy) {
hlerpT = clamp(lerp(z_tlc, z_trc, xx / sprite_width), min(z_tlc, z_trc), max(z_tlc, z_trc));
hlerpB = clamp(lerp(z_blc, z_brc, xx / sprite_width), min(z_blc, z_brc), max(z_blc, z_brc));
bilerp = clamp(lerp(hlerpT, hlerpB, yy / sprite_height), min(hlerpT, hlerpB), max(hlerpT,hlerpB));
return bilerp;

And as it is it works great for "non-rotated" ramps (image_angle is 0).

I figured I should probably replace "xx  / sprite_width" and "yy / sprite_height" with something that takes into account the rotation of the sprite that generates slope but am not sure. Any help, hints or tips are greatly appreciated!

Thank you!

(3 edits)

The gist of it is that the Z value is obtained by doing a bilinear interpolation between the Z values of the 4 corners. (TLC is short for Top Left Corner, and so on). It works with rotated things as well, but the code is simplified since I'm abusing the fact everything is parallel to the X and Y axes.

Even if you rotate an object sprite_width will be its width and sprite_height will be its height, so I think the issue is that you're not computing xx/yy in "rotated space". So you'd need some code along these lines:

(where "terrain" is the ID of the slope object you want to collide with, and "player" is the player object... I don't have the source code at hand right now so I've forgotten what names are actually used in the collision logic, lol)

(The way this works is, dot product basically multiplies two vectors taking their relative alignment into account, so when one vector has length 1 the dot product will 'project' the other onto its direction... so we use this property to turn the regular x/y coordinates into coordinates relative to the rotated slope.)

The other thing that might be needed here is to make sure collisions only happen when the player is over the slope object even when it's rotated, by default Game Maker will just scale up the bounding box when you rotate something (so it is a rectangle that fully encapsulates the sprite after applying rotation) so you might trigger collisions just by being near the rotated slope since you technically collide with it.

You specifically need to have the slope object's sprite use the "rectangle with rotation" collision mode (since it is a rectangle you rotate, this is the fastest option) and probably use the "precise" flag when doing the collision checks as well - I'm not 100% sure if the rotated rectangle collision mode counts as precise or imprecise but I think it's precise.

(2 edits) (+1)

Thank you Yal you are a gem, it worked perfectly! Yeah, I've already taken care of collision with the rotated ramp (used rectangle with rotation as you mentioned), I was just missing this final piece of the puzzle.

One thing is my frame rate takes quite a hit now when walking on ramps, is dot_product just a very expensive function? 
^Disregard - my collision code was causing a bottleneck.

Thanks again!

No problem, glad it worked out so quickly!

Dot product is a very simple operation, it's just the sum of every vector component multiplied with the same component of the other vector (so the 2D case is 2 multiplications and 1 addition), so it should be faster than e.g. doing a geometric solution with trigonometry most of the time. The only thing it really does is tell you how parallel two vectors are, but it's the best choice if you need that exact thing!

Hello, I'm from Poland. I'm currently playing Heart of ruins final Columbus.  So far I have acquired 8 weapons and 48 knowledge.

 However, I don't know how to destroy the block with blue lightning.  I also don't know how to solve the puzzles for which I have hints.  I solved one with the letters "a" "b" "y" but I don't know if it's correct because they keep flashing alternately.

 I would like to ask you to help me in this game, for which I will be very grateful.  I know you've probably forgotten about this game, but I hope you'll remember something


 My email is


Do this and the YaruFPS engine ( have any sort of intercompatibility? I have started on a project running Yaru3D, and would like to integrate the weapon and ammunition systems from the latter engine.

They're completely different systems that just happen to look similar, it most likely is impossible to combine them. (The YaruFPS weapon system has a bunch of assumptions about being in a FPS game as well, not sure how well it would work in a platformer)

I see. Thanks for the answer!

Hello there! Weren't you the one that had made years ago that 3D Sonic engine for Game Maker 8? Nice to see you doing stuff again! (I used to be "Matrox" in Yoyogames Sandbox if you do remember that name)


The very same! Also, "making stuff AGAIN"? I never stopped, lol :P (A lot of my Sandbox stuff isn't up here because it either was pretty bad or doesn't run properly anymore, and I've cut out all the content infringerino stuff as well)

hello the enemy are not implemented in this engine? i see the are obj_goom but I can not make it work thanks

Yeah, the object has no code and there's no graphics for it either. I probably planned to add enemies at some point, then scrapped those plans but forgot to remove the object.

There is some way, that the camera follows the character always from behind automatically and you don't have to be accommodating the camera with the letter WASD sorry for my bad english thanks

Not built-in, but you could always just add in code that automatically controls the camera angle and remove the WASD camera control code. It's a really difficult subject to tackle and it's very game-dependent, so there's no universal way to do this and it felt out of scope for this engine.

I'll recommend checking out this GDC talk on the subject, it's really helpful (they go through algorithms and stuff for things like camera whiskers):

Very cool! One thing though: When I place slopes they seem to only randomly work? Like I can place one vertical slope next to a normal terrain that goes to an "up 1" terrain, then another vertical slope from that to an "up 2" terrain, and only the first slope appears?

(1 edit) (+1)

I dug into this a bit and I believe I've found what causes it... Z-coordinates are stored in a grid based around 32x32 blocks, so if you accidentally place a slope or a block off this grid, the slopes will get the wrong Z value because the correct cell might not be set (or the slopes access the next cell rather than the appropriate cell). Either make sure your room grid is set to 32x32 when placing terrain, or change the value of the GRIDSIZE_PX macro to 16.


Oh wow, thanks for the super quick reply! Good stuff!


Wouldn't really be good customer support if I let someone wait several weeks for a mistake this simple, now would it? :P

Glad you got it working~