yal do you possibly have a 3D collision engine for legacy game maker? Like GMS 1.4? I’m very impressed with this engine but for some reason I can’t get it running, all I would want is a 3D collision engine
The file labelled Source code (Legacy) (GMS 1.4) is what you're looking for, does that not work for you? Which version are you on?
(Also interested in how it doesn't work, more exactly - if it seems to freeze when you load up a level, it's worth pointing out generating all the geometry in the test level takes a while. If there's some error message you need to tell me what it is and I'll see if I can figure out how to fix it)
wait, scratch that, I got it to work, it couldn’t load the file cause I was running it from winrar. I just wanted to test it to see if I wanted to buy it, I can’t for the life of me get a 3D collision engine to work properly in GMS1.4. Tell me, does the geometry of the level have to be uploaded in separately from a 3D file? Or would your 3D collision code work for things that are modeled in GMS1.4? Like if I had some floating islands separate from the terrain but also a unique shape?
All of the collision in this engine is based on simple shapes (which are generated in-engine): axis-parallel cylinders, axis-parallel cubes, and axis-parallel blocks whose top and bottom are bilinear interpolated planes ("slopes" for short). There's no support to load 3D models externally, all geometry in the GMS1 version is generated in-engine using path assets to describe shapes. (Very inefficient, but this was before I learned Blender and I desperately wanted to avoid 3D modelling if I could)
The GMS2 version also adds a global terrain which is generated using an image heightmap (the idea is to cut down on the number of base shapes needed to represent the level geometry, since generating them is so slow) and a more exotic "path" terrain type which is basically a sequence of connected quads with arbitrary positioning - perfect for roads and paths (if they're not very tall and closely aligned to the ground) and curved walls (when they are tall).
Collision checking is the biggest performance hog so ideally you should use cubes and the like as hitboxes whenever possible - even with the stuff done to make this more efficient (using a precomputed hashmap for static terrain) the sheer number of points that needs to be checked makes it take up a lot of processing power.
I mean, there's a free demo which has all the benefits of a video + lets you check things more closely instead of only getting my perfectly edited version that hides all the obvious flaws....
I can't reproduce this on my end, but I'm noticing weird git diffs where the data of the included files get their "CopyToMask" set to "-1", which looks like it could be the issue. I'll upload the latest file I exported (in case whatever happened didn't happen because it was fixed?), if that fails I've also uploaded the level sources separately ("Level source files"), please try manually re-importing them as included files if they still don't load properly.
Updated the project to 2.3. It seems to work without changes (except performance is slightly worse - this is most notable in the level editor when editing a huge level)
I'm really loving this engine, as I do all of your stuff! I'm learning a lot as I go, taking notes about where various things are controlled from. I just have a few questions:
1. How do you add more placeable objects into the stage editor, like items and decorations? I figure it has something to do with yashow_menu and the variables like misc_item_str that is read in the user events in obj_editoroverlay.
2. What would be the most efficient way of adding gamepad controls? I see where to change the keyboard inputs in get_keys and in the camera objects.
3. Do you plan on adding any documentation down the line to make it a little less confusing to create new models using the simple shapes and paths? Genius method, by the way!
Side note: I'm getting around 50-60 fps consistently on the test level in GM 1.4.9999.
Thank you so much for all your work, in this and many other engines!
1: Scripts --> Editor --> Data Definitions is full of scripts that set up these menus. Some metadata needs to be stored on the side, so the strings you've seen really only exist for the menu itself (it's a compatibility function for now-deprecated show_menu that showed a Windows popup menu of the same type you get when right-clicking something)
2: I'd add a new global variable input_device which defaults to a new constant inputdevice_KEYBOARD which is negative. In Asynchronous Event: System events added to the main control objects, set the input device to the new gamepad ID when a gamepad is discovered and back to inputdevice_KEYBOARD if the current gamepad is lost. (Read up on the Asynchronous Event List page for the details on this step). In get_keys, check whether input_device is equal to inpupdevice_KEYBOARD and if so run the current code, else if it's >= 0, read status from gamepad index input_device using gamepad_button_check for buttons and gamepad_axis_value for sticks, with appropriate values for buttons and axes (axes 0 and 1 are the left stick, 2 and 3 the right stick, and there's named constants for all standard buttons).
(You'd probably want to put the gamepad check in a script and have every major menu controller have one of these so the events can't get lost if you change to a room without the player object setup... including putting one in the setup room, perhaps? Not sure how GM will treat that event since it's supposed to trigger at the start of the game but the first room has no objects...)
3: Not really, the system turned out to have terrible performance and I'd do everyone a disservice if I encouraged using it :P The gist of it is that the silhouette described by the path is rotated in 3D space to create the model, and if you have multiple paths the shape will be blended between them. Paths are listed together with an angle; that angle is where the shape will be 100% that path (if you only have a single path to define the shape, you can just use an angle of zero). Finally, the body part is stretched over a radius/height pair, so you get more fine-grained control over its final size (GM paths get kinda wonky when you make them too small so they're several hundred pixels big and then downscaled).
Thank you so much, Yal! The method for creating models may not be the most efficient performance-wise, but it really is an incredibly smart way to get around the need of importing them from outside!
Everything runs in stable 60fps on my end, I wouldn't ship something that I know is broken. But it's definitely demanding a lot of resources.
One of the biggest CPU and GPU bottlenecks is the custom skeletal animation system (re-computing the coordinates for every limb is pretty expensive and then there's dozens of draw calls that each require rebuilding the world matrix), so I'd recommend getting something like Sndir's Model Format instead if you can (which is free!). My skeletal animation system is a bit of a disappointment because of the performance issues and inherent limitations, so I mostly intend it to be a placeholder so the asset can have characters at all... GM's built-in 3D modelling support is very limited to begin with, and I have no experience with 3D modelling tools, but I know how to use paths and trigonometry so I stick to my guns :P
The second biggest resource hog is me using a sort-of-pillbox-style hitbox for the player, doing a lot of collision checks to make sure they work smoothly with all sorts of terrain... but the collision amount gets increased a lot because I essentially do one raycast along every axis to handle movement, so this balloons exponentially in performance requirements. Depending on level architecture, you could get away with a much simpler hitbox which would improve this.
If you're interested in the gritty details, here's the results of the profiling I did of the game's performance:
(The control draw event isn't expanded, but essentially the bulk of it is drawing character models)
Another fine asset from Yal! I just wanted to let you know I am also getting 15-20 FPS on the provided demo level in the GM:S 1.4 version. The GM:S 2 version ran around 25-30 FPS. I have a GTX 1070 gpu and a great processor so my rig shouldn't bean issue. Probably just the limitations of Game Maker in 3d I would assume. Keep up the amazing work!
Interesting... I'm on a GTX 1060 / i5-8300 rig these days so I would've expected your performance to be better than mine. (Bigger numbers means better hardware, right...?)
At least the "GMS2 has better performance than GMS1" result is congruent with my testing - it's not as noticeable when both run relatively stable 60fps but the difference is gigantic - something like 500 fps_real for GMS1 vs 800 fps_real for GMS2.
← Return to asset pack
Comments
Log in with itch.io to leave a comment.
yal do you possibly have a 3D collision engine for legacy game maker? Like GMS 1.4? I’m very impressed with this engine but for some reason I can’t get it running, all I would want is a 3D collision engine
The file labelled Source code (Legacy) (GMS 1.4) is what you're looking for, does that not work for you? Which version are you on?
(Also interested in how it doesn't work, more exactly - if it seems to freeze when you load up a level, it's worth pointing out generating all the geometry in the test level takes a while. If there's some error message you need to tell me what it is and I'll see if I can figure out how to fix it)
wait, scratch that, I got it to work, it couldn’t load the file cause I was running it from winrar. I just wanted to test it to see if I wanted to buy it, I can’t for the life of me get a 3D collision engine to work properly in GMS1.4. Tell me, does the geometry of the level have to be uploaded in separately from a 3D file? Or would your 3D collision code work for things that are modeled in GMS1.4? Like if I had some floating islands separate from the terrain but also a unique shape?
All of the collision in this engine is based on simple shapes (which are generated in-engine): axis-parallel cylinders, axis-parallel cubes, and axis-parallel blocks whose top and bottom are bilinear interpolated planes ("slopes" for short). There's no support to load 3D models externally, all geometry in the GMS1 version is generated in-engine using path assets to describe shapes. (Very inefficient, but this was before I learned Blender and I desperately wanted to avoid 3D modelling if I could)
The GMS2 version also adds a global terrain which is generated using an image heightmap (the idea is to cut down on the number of base shapes needed to represent the level geometry, since generating them is so slow) and a more exotic "path" terrain type which is basically a sequence of connected quads with arbitrary positioning - perfect for roads and paths (if they're not very tall and closely aligned to the ground) and curved walls (when they are tall).
Collision checking is the biggest performance hog so ideally you should use cubes and the like as hitboxes whenever possible - even with the stuff done to make this more efficient (using a precomputed hashmap for static terrain) the sheer number of points that needs to be checked makes it take up a lot of processing power.
Needs a video to demonstrate selling points.
I mean, there's a free demo which has all the benefits of a video + lets you check things more closely instead of only getting my perfectly edited version that hides all the obvious flaws....
Getting this error after importing the recent update you made
___________________________________________
############################################################################################
ERROR in
action number 1
of Alarm Event for alarm 0
for object obj_titlescreen:
Cannot locate external level file <titlescreen.s3dit>...
at gml_Script_load_level_game (line 32) - show_error("Cannot locate external level file <" + argument0 + ">...",true)
############################################################################################
gml_Script_load_level_game (line 32)
gml_Object_obj_titlescreen_Alarm_0 (line 3) - load_level_game("titlescreen.s3dit")
I can't reproduce this on my end, but I'm noticing weird git diffs where the data of the included files get their "CopyToMask" set to "-1", which looks like it could be the issue. I'll upload the latest file I exported (in case whatever happened didn't happen because it was fixed?), if that fails I've also uploaded the level sources separately ("Level source files"), please try manually re-importing them as included files if they still don't load properly.
Updated the project to 2.3. It seems to work without changes (except performance is slightly worse - this is most notable in the level editor when editing a huge level)
I'm really loving this engine, as I do all of your stuff! I'm learning a lot as I go, taking notes about where various things are controlled from. I just have a few questions:
1. How do you add more placeable objects into the stage editor, like items and decorations? I figure it has something to do with yashow_menu and the variables like misc_item_str that is read in the user events in obj_editoroverlay.
2. What would be the most efficient way of adding gamepad controls? I see where to change the keyboard inputs in get_keys and in the camera objects.
3. Do you plan on adding any documentation down the line to make it a little less confusing to create new models using the simple shapes and paths? Genius method, by the way!
Side note: I'm getting around 50-60 fps consistently on the test level in GM 1.4.9999.
Thank you so much for all your work, in this and many other engines!
Thanks, glad you like it! ^__^
1: Scripts --> Editor --> Data Definitions is full of scripts that set up these menus. Some metadata needs to be stored on the side, so the strings you've seen really only exist for the menu itself (it's a compatibility function for now-deprecated show_menu that showed a Windows popup menu of the same type you get when right-clicking something)
2: I'd add a new global variable input_device which defaults to a new constant inputdevice_KEYBOARD which is negative. In Asynchronous Event: System events added to the main control objects, set the input device to the new gamepad ID when a gamepad is discovered and back to inputdevice_KEYBOARD if the current gamepad is lost. (Read up on the Asynchronous Event List page for the details on this step). In get_keys, check whether input_device is equal to inpupdevice_KEYBOARD and if so run the current code, else if it's >= 0, read status from gamepad index input_device using gamepad_button_check for buttons and gamepad_axis_value for sticks, with appropriate values for buttons and axes (axes 0 and 1 are the left stick, 2 and 3 the right stick, and there's named constants for all standard buttons).
(You'd probably want to put the gamepad check in a script and have every major menu controller have one of these so the events can't get lost if you change to a room without the player object setup... including putting one in the setup room, perhaps? Not sure how GM will treat that event since it's supposed to trigger at the start of the game but the first room has no objects...)
3: Not really, the system turned out to have terrible performance and I'd do everyone a disservice if I encouraged using it :P The gist of it is that the silhouette described by the path is rotated in 3D space to create the model, and if you have multiple paths the shape will be blended between them. Paths are listed together with an angle; that angle is where the shape will be 100% that path (if you only have a single path to define the shape, you can just use an angle of zero). Finally, the body part is stretched over a radius/height pair, so you get more fine-grained control over its final size (GM paths get kinda wonky when you make them too small so they're several hundred pixels big and then downscaled).
Thank you so much, Yal! The method for creating models may not be the most efficient performance-wise, but it really is an incredibly smart way to get around the need of importing them from outside!
This is incredible, and will take a bit for me to decipher but hats off to you!
What's been your experience with FPS? I'm getting 15-20 FPS on the demo level.
Everything runs in stable 60fps on my end, I wouldn't ship something that I know is broken. But it's definitely demanding a lot of resources.
One of the biggest CPU and GPU bottlenecks is the custom skeletal animation system (re-computing the coordinates for every limb is pretty expensive and then there's dozens of draw calls that each require rebuilding the world matrix), so I'd recommend getting something like Sndir's Model Format instead if you can (which is free!). My skeletal animation system is a bit of a disappointment because of the performance issues and inherent limitations, so I mostly intend it to be a placeholder so the asset can have characters at all... GM's built-in 3D modelling support is very limited to begin with, and I have no experience with 3D modelling tools, but I know how to use paths and trigonometry so I stick to my guns :P
The second biggest resource hog is me using a sort-of-pillbox-style hitbox for the player, doing a lot of collision checks to make sure they work smoothly with all sorts of terrain... but the collision amount gets increased a lot because I essentially do one raycast along every axis to handle movement, so this balloons exponentially in performance requirements. Depending on level architecture, you could get away with a much simpler hitbox which would improve this.
If you're interested in the gritty details, here's the results of the profiling I did of the game's performance:
(The control draw event isn't expanded, but essentially the bulk of it is drawing character models)
Another fine asset from Yal! I just wanted to let you know I am also getting 15-20 FPS on the provided demo level in the GM:S 1.4 version. The GM:S 2 version ran around 25-30 FPS. I have a GTX 1070 gpu and a great processor so my rig shouldn't be an issue. Probably just the limitations of Game Maker in 3d I would assume. Keep up the amazing work!
Interesting... I'm on a GTX 1060 / i5-8300 rig these days so I would've expected your performance to be better than mine. (Bigger numbers means better hardware, right...?)
At least the "GMS2 has better performance than GMS1" result is congruent with my testing - it's not as noticeable when both run relatively stable 60fps but the difference is gigantic - something like 500 fps_real for GMS1 vs 800 fps_real for GMS2.
Hoping for jiggly Z-Buffer!
The hits keep coming!
I'll see if I can integrate a few features here into the FPS Engine.
That should be an interesting experiment. :)
WOW Yal.
Oh my gawd. Instant buy just to support awesome works like this.