Log in with to leave a comment.

Sorry for a noob question, but I downloaded the 3D code and tried to play in gamemaker 2 and it doesnt seem to render correctly, half the screen is clouds and the bottom is ground, but can't see the car. I can drive though as i move the track change and it seems to follow. All i did was download the new gamemaker2 and then import new. is thre something i am missing? TY

Hiya! Sorry for taking so long to reply.

It sounds like there's an issue with the depth sorting between obj_skyboxcontrol and the other objects... drawing has a bunch of odd quirks in GMS2 compared to previous versions, e.g. depth sorting doesn't work in Draw GUI event. Looks like ortho and perspective drawing are drawn in separate passes so ortho always is drawn last. To just get the track to draw properly, you could try commenting out the code in the Draw event of the obj_skyboxcontrol object. (You might wanna set up a background color in the room instead as a placeholder so that the window gets cleared each draw frame).

Not sure what the best way to solve the problem is, depends a bit on what graphical style you wanna go for in your game. If you want a stylish celshaded look you could keep a solid background color, for a more realistic style you could add some code in e.g. stage_model_create() so that it creates a skybox as well (the simplest approach would be to just add walls at the X and Y boundaries but it might look a bit flat). You can make texture atlases bigger than 2x2 (to add in some new sky textures etc), just don't forget to update the atlas-size arguments to stage_model_create() so that it gets the correct size - there's no info in the graphic asset that can be used for this so it needs to be provided off-band.

(2 edits)

[SOLVED: read down below]

Awesome engine! It works quite well. The only problem I've found is that the car starts to move forward at a certain velocity, in my case it start to move at 7 units of the variable movespd... It depends on track length and step... The funny thing is it doesn't happen if the car is perpendicular to the track direction. I need your help, Yal!

Does it happen instantly or only when certain actions are performed? If it only happens when you're pointing in the direction of the track, it sounds like it could be the maths to translate between track position and room coordinates that glitch out.

Could you please answer the following questions? It'll help making it easier to narrow down the problem...

  • What version of GameMaker are you using, GMS1 or GMS2?
  • Did you make any changes to the movement logic or are you using it unchanged?
  • How do you cause this effect to happen? (the best would be a list of reproduction steps that makes it happen with 100% certainty, but any and all information is helpful)

It happens instantly only when pointing in the direction of the track. Take a close look at the demo, it also happens in there but is not easy to notice. If you enlarge the track you will see it well.

Your questions:

  • I'm using GMS2
  • No big changes. Only the way the "accel" variable is modified when pressing the up key to make it non linear (I'm trying to recreate an engine power curve). No changes were made to the d3d logics.
  • This effect happens when the car is stopped or under certain velocity, it just stops moving forward but keeps moving to both sides depending on direction. I've tried this with the source code unchanged with a larger track. 

Thanks, managed to get a 100% reproduction method working now... angle slightly, stand still, then tap 'accelerate'. I'll see i I can figure out what causes it.

I think I've figured out what's happening, but not WHY... the U position (how far you're along the track) seems to only update in increments of a set size, so at small speeds it get snapped back after updating. The W position (sidewaysness) isn't affected by this, so you can move sideways just fine.

Okay, I think I've figured it out! It's GM's float numbers being too imprecise, essentially. I added a bit of a hack to make the track position bigger to have more decimals around, and that solved the problem.

Here's the changes you need to do:

  • In obj_trackcontrol's create event, below the line that sets "global.ufactor", add something like global.uufactor     = 1000/global.tracklength
  • When trackcontrol creates cars, below the line "n.u = u", add the line n.uu= n.u*1000
  • In player_apply_movement, remove the line that sets u and replace it with the following two lines:
    • uu         += lengthdir_x(argument1*global.uufactor,alpha)
      u = uu/1000

You could substitute the 1000 for any number you want, I'll do that with a macro and then export an updated version of the engine file.

Fixed version is uploaded! It's just a change of like 3 lines, so it might be easier to just manually apply the git diff to your existing project:

diff --git a/ b/
index 622e83f..59e20a7 100644
--- a/
+++ b/
@@ -105 +105 @@
-  <constants number="8">
+  <constants number="9">
@@ -108,0 +109 @@
+    <constant name="TRACK_U_PRECISION">10000</constant>
diff --git a/ b/
index 3073c84..0d4bd06 100644
--- a/
+++ b/
@@ -36,0 +37 @@ u = 1.00//Forward coordinate
diff --git a/ b/
index c55c5c8..c8882e3 100644
--- a/
+++ b/
@@ -73 +73,2 @@ global.ufactor      = 1/global.tracklength
+global.uufactor     = TRACK_U_PRECISION/global.tracklength
@@ -105,0 +107 @@ for(car = 0; car < global.cars_total; car++){
+    n.uu= n.u*TRACK_U_PRECISION
diff --git a/ b/
index 3e6cf06..3f204c1 100644
--- a/
+++ b/
@@ -16 +16,2 @@ alpha       = angle_difference(trackdir,argument0)
-u          += lengthdir_x(argument1*global.ufactor,alpha)
+uu         += lengthdir_x(argument1*global.uufactor,alpha)

Perfect!! It works like a charm now! Thanks Yal!! 

I must ask for something else if you don't mind: can you upload some documentation  about how to import 3d models into the engine? I mean, if that is possible. If don't, a tutorial explaining how to create them from paths, how to apply some textures and set the proper collision mask.

Thanks again, Yal!! You've made a wonderful job here!!

The models all are created from paths, I have no experience with "proper" 3D modelling (Blender etc) so I wouldn't really know how to import new ones.

  • Path0, 1 and 2 respectively are the silhouette of the car at the center, a bit outside the center, and at the left/right sides.
  • PxLengthFactor is the downscaling factor from path coordinates to model coordinates (the paths are pretty big thanks to how the grid is defaulted).
  • W0, W1, W2 and W3 are how far left/right from the center the paths are placed when used as a guide for the model. These are raw model coordinates, they don't use the PxLengthFactor. So for instance having a higher W0 means the cockpit is wider, having a W3 much higher than W2 makes the car have bigger wings, and so on.
  • W3 must always be greater than W2, W2 greater than W1, and so on. (You don't NEED them to be greater, but the model will clip into itself if not).
  • The texture is mapped like this: every horizontal 25% of the texture is used for the section between two W*s. So the first 25% of the texture are used for the section between -W0 and +W0, the next 25% are used for the section between W0 and W1 on both sides, and so on. It's stretched evenly from the front of the vehicle to the back (the top of the texture maps to the start of the path, the bottom to the end of the path)
  • Currently the model doesn't affect the collision mask at all, the cars all use the car sprite as a mask. You could extract the car's length from the modelling script by storing the "xx" variable of the first and last iteration (first iteration's lower value + last iteration's higher value, it's an array) and the W3 (outermost width)... those will give you the bounds of the car's model's bounding box, and then if you used an ellipsoid collision you'd get an okayish result. Probably would be the easiest to make a circle-shaped sprite for collision masks (with Ellipse collision mask settings, sprites default to "rectangle") and then scale image_xscale / image_yscale based on the bounding box size so the sprite covers the same region (e.g. if W3 is 8 and the sprite is 32x32, image_yscale should be 0.5 because (8*2)/32 = 0.5)

Hope this helps :)

This is neat.

Thanks ^__^