A lot of fun. Spent the past few days checking it out. If you want to go off road you can, with some extra steps Under car physics removing w = clamp(w,-1,1) You can go anywhere. Issue is the only thing with a 'height map' is the road generated from the Paths.
You can create a global 2D Array to store a height map and capture points during the 'stage_model_create' phase.
1. get the length of the total grass line
2. divide it by the grid size for the height map. so a 96 width line with a 32 pixel grid gives us 3 'segments'
3. find the total z-depth by taking the known Z of the track (max) and the known z-depth of the ground (min). So a zdpeth of 100 would be 100 -0
4. we know we need to descend 100 pixels in 3 segments. or 100/33 (33)
5. for each segment calculate the point of the road to each segmented point.
basically doing
100-33 = 77 z depth
100-66 = 44
100-99 = 1
Pseudo code
...
var newXForInBetweenWall = txx + lengthdir_x(Dist,Dir);
var newYForInBetweenWall = tyy + lengthdir_y(Dist,Dir);
One of the reasons I stop you from going offroad is because it removes the need to worry about the player taking big shortcuts by skipping parts of the track, you'll probably want to add walls (or e.g. clamp w to -2,2 instead and programmatically create different walls at that point) to avoid that becoming a problem.
yea that makes sense. Could keep the road pathing system for walls, or zones similar to mario kart where something puts you back on course. Could reduce speed based on clamp distance to not necessarily stop the players from going off course, but have no advantage for it.free roaming like wave racers was a lot of fun. do you have any tutorials on doing water / changing textures on the d3d models?
Water is kinda tricky, doing waves the "regular" way (a dynamic 3D primitive that gets resubmitted every step) is slow - you can speed it up by having a special shader (the vertex shader moves each vertex up/down using a wave equation) but doing that means you need to make a lot of evenly spaced triangles instead of using a single 2-triangle plane with a repeated texture.
The gist of it is relatively simple, at least: each "corner" moves up and down using a sinewave function, whose argument is a sum of x coordinate * horizontal speed + y coordinate * vertical speed + time. For the texture you'd just add those speeds to the texture coordinate. Some games sample the water texture multiple times at different resolution (and different scroll speeds per resolution) and then add them together, to simulate there being multiple "layers" to the water.
Hello,big fan since SoftEngine. However, my racers crash into each other at the very first corner, any idea how we can avoid that? They do in both versions, 2d and 3d
The big issue here probably is that all racers try to follow the center of the racetrack exactly, especially if they all have the same speed and turning values that also means they try to take the same turn. There's a bunch of ways you could adjust csc_ai to fix this...
Give each AI new variables for angle tolerances instead of using hardcoded 45, 90 and 5 degrees as breakpoints, these should be set using random_range() in the create event of obj_car and then used in csc_ai.
Another idea is to add a random coordinate (x,y pair) which is added to the target position (when setting tgdir) so the car doesn't try to move towards the same point all the time, you'd set them to 0 in the car's create event and then re-randomize them occasionally using an alarm.
You could also adapt csc_ai to check for nearby cars ahead of you (using the regular Game Maker collision functions) and try to avoid them by adding/subtracting from tgdir depending on the angle/distance to the car ahead. I don't have a quick fix idea for how to do this but a simple starting point would be to raycast a couple of times (using collision_line), starting at 0 degrees relative to the current facing angle and gradually moving outwards, and then add a value in the other direction to the desired movement angle if there's a car in the way.
Good fun! Not sure if you’re still maintaining this or not, but somewhere along the line GMS2 changed the way depth works, causing the skybox to get drawn over half of the screen. (It looks like someone else had a similar problem, but I don’t know if it was caused by the same issue or not).
Anyway, when you draw the skybox, you now need to force the depth buffer off (gpu_set_zwriteenable, as well as gpu_set_ztestenable if you really want) to prevent the background from persisting in 3D space after it’s been drawn. Not sure when GameMaker changed this, since it works just fine in GMS1. ¯_(ツ)_/¯
Also, I’m impressed that you managed to model everything in the game using exclusively paths. I would have just gone straight to 3D object files, lol.
GMS2 still doesn't have built-in support for loading OBJ files, and I don't want to include code I didn't make myself in any of my asset packs. I didn't start using Blender until a few months ago, so paths was the closest thing I had available at the time I made this. (Certainly better than having to hardcode vertex coordinates for every object, which I used in a previous project...)
There's no code for it built into the engine, and right now there's basically invisible walls at the track edges, so it's going to need some work to add in.
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
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.
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.
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)
← Return to engine
Comments
Log in with itch.io to leave a comment.
A lot of fun.
Spent the past few days checking it out.
If you want to go off road you can, with some extra steps
Under car physics removing
w = clamp(w,-1,1)
You can go anywhere.
Issue is the only thing with a 'height map' is the road generated from the Paths.
You can create a global 2D Array to store a height map and capture points during the 'stage_model_create' phase.
1. get the length of the total grass line
2. divide it by the grid size for the height map. so a 96 width line with a 32 pixel grid gives us 3 'segments'
3. find the total z-depth by taking the known Z of the track (max) and the known z-depth of the ground (min). So a zdpeth of 100 would be 100 -0
4. we know we need to descend 100 pixels in 3 segments. or 100/33 (33)
5. for each segment calculate the point of the road to each segmented point.
basically doing
100-33 = 77 z depth
100-66 = 44
100-99 = 1
Pseudo code
...
var newXForInBetweenWall = txx + lengthdir_x(Dist,Dir);
var newYForInBetweenWall = tyy + lengthdir_y(Dist,Dir);
// round to our grid for height map
newXForInBetweenWall = round(newXForInBetweenWall/spacings)*spacings;
newYForInBetweenWall = round(newYForInBetweenWall/spacings)*spacings;
.....
global.heightm[newXForInBetweenWall, newYForInBetweenWall] = (zz/totalSegmentsOfWall) * (wallCtr);
One of the reasons I stop you from going offroad is because it removes the need to worry about the player taking big shortcuts by skipping parts of the track, you'll probably want to add walls (or e.g. clamp w to -2,2 instead and programmatically create different walls at that point) to avoid that becoming a problem.
yea that makes sense.
Could keep the road pathing system for walls, or zones similar to mario kart where something puts you back on course.
Could reduce speed based on clamp distance to not necessarily stop the players from going off course, but have no advantage for it.free roaming like wave racers was a lot of fun.
do you have any tutorials on doing water / changing textures on the d3d models?
Water is kinda tricky, doing waves the "regular" way (a dynamic 3D primitive that gets resubmitted every step) is slow - you can speed it up by having a special shader (the vertex shader moves each vertex up/down using a wave equation) but doing that means you need to make a lot of evenly spaced triangles instead of using a single 2-triangle plane with a repeated texture.
The gist of it is relatively simple, at least: each "corner" moves up and down using a sinewave function, whose argument is a sum of x coordinate * horizontal speed + y coordinate * vertical speed + time. For the texture you'd just add those speeds to the texture coordinate. Some games sample the water texture multiple times at different resolution (and different scroll speeds per resolution) and then add them together, to simulate there being multiple "layers" to the water.
Hello,big fan since SoftEngine. However, my racers crash into each other at the very first corner, any idea how we can avoid that? They do in both versions, 2d and 3d
Oh wow, that's a blast from the past!
The big issue here probably is that all racers try to follow the center of the racetrack exactly, especially if they all have the same speed and turning values that also means they try to take the same turn. There's a bunch of ways you could adjust csc_ai to fix this...
Good fun! Not sure if you’re still maintaining this or not, but somewhere along the line GMS2 changed the way depth works, causing the skybox to get drawn over half of the screen. (It looks like someone else had a similar problem, but I don’t know if it was caused by the same issue or not).
Anyway, when you draw the skybox, you now need to force the depth buffer off (gpu_set_zwriteenable, as well as gpu_set_ztestenable if you really want) to prevent the background from persisting in 3D space after it’s been drawn. Not sure when GameMaker changed this, since it works just fine in GMS1. ¯_(ツ)_/¯
Also, I’m impressed that you managed to model everything in the game using exclusively paths. I would have just gone straight to 3D object files, lol.
GMS2 still doesn't have built-in support for loading OBJ files, and I don't want to include code I didn't make myself in any of my asset packs. I didn't start using Blender until a few months ago, so paths was the closest thing I had available at the time I made this. (Certainly better than having to hardcode vertex coordinates for every object, which I used in a previous project...)
There’s a compatibility script for the old GameMaker models, depending on how far you want to go with that (.d3d is a pretty obscure format).
Nice engine! I was wondering, can this be used for broken sections of track?
There's no code for it built into the engine, and right now there's basically invisible walls at the track edges, so it's going to need some work to add in.
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.
[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...
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:
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:
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/SimpleRacingEngine_3D_carmodels.gmx/SimpleRacingEngine_3D_carmodels.project.gmx b/SimpleRacingEngine_3D_carmodels.gmx/SimpleRacingEngine_3D_carmodels.project.gmx index 622e83f..59e20a7 100644 --- a/SimpleRacingEngine_3D_carmodels.gmx/SimpleRacingEngine_3D_carmodels.project.gmx +++ b/SimpleRacingEngine_3D_carmodels.gmx/SimpleRacingEngine_3D_carmodels.project.gmx @@ -105 +105 @@ - <constants number="8"> + <constants number="9"> @@ -108,0 +109 @@ + <constant name="TRACK_U_PRECISION">10000</constant> diff --git a/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_car.object.gmx b/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_car.object.gmx index 3073c84..0d4bd06 100644 --- a/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_car.object.gmx +++ b/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_car.object.gmx @@ -36,0 +37 @@ u = 1.00//Forward coordinate +uu = TRACK_U_PRECISION diff --git a/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_trackcontrol.object.gmx b/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_trackcontrol.object.gmx index c55c5c8..c8882e3 100644 --- a/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_trackcontrol.object.gmx +++ b/SimpleRacingEngine_3D_carmodels.gmx/objects/obj_trackcontrol.object.gmx @@ -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/SimpleRacingEngine_3D_carmodels.gmx/scripts/player_apply_movement.gml b/SimpleRacingEngine_3D_carmodels.gmx/scripts/player_apply_movement.gml index 3e6cf06..3f204c1 100644 --- a/SimpleRacingEngine_3D_carmodels.gmx/scripts/player_apply_movement.gml +++ b/SimpleRacingEngine_3D_carmodels.gmx/scripts/player_apply_movement.gml @@ -16 +16,2 @@ alpha = angle_difference(trackdir,argument0) -u += lengthdir_x(argument1*global.ufactor,alpha) +uu += lengthdir_x(argument1*global.uufactor,alpha) +u = uu/TRACK_U_PRECISIONPerfect!! 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.
Hope this helps :)
This is neat.
Thanks ^__^