Happy to hear it!
Pixelated Pope
Creator of
Recent community posts
Haven't ran into too many issues myself performance wise. Typically shader performance is "gated" by how often you are calling shader_set and shader_reset more than just about anything else. Vertex batch count isn't usually a good measure of how "performant" anything is. I've had something running at 60fps with my batch count in the thousands.
Other issues can be your application surface size. Your art may be low res, but if you've upscaled your app surface size to get sub pixels, you are doing more work. You could be swapping 4 to 16 times the number of pixels than you really need to. Other concerns are palette sizes. If your palette has tons of colors, then that's more colors the shader needs to search through to find a match (or it ends up going through all of them when there is nothing to match)
There are lots of ways to improve performance, but it's all going to be very, very specific to your project. I'd recommend asking on the GM Discord server when you have time to sit down and work on it. Lots of people there that can help you figure out exactly what is slowing you down and how to improve it. Best case scenario would be you working on said "lower end" machine, or setting up a use case where you are experiencing the performance issues yourself.
It is possible, yes.
The thing about any collision system is it ultimately comes down to "can I move here? Yes or no." right? That's what place_meeting is.
TDMC allows you to define your own place_meeting function, which you can make as complicated as you want. So: yes, totally possible. Obviously not something that it does "out of the box" but changing how you define the collision check function is all it really takes.
Yeah, that is one of the downsides of the State Machine pattern. Because each state fully encapsulates everything that object is doing in any one step, that means anything that is shared is duplicated.
I often write functions like "move_and_collide" which would handle gravity and collision and all that. These "helper functions" are defined globally and available in any state on any object. Sometimes I'll allow those functions to accept arguments such as "in this state the gravity is .2, where as in this state the gravity is .3" or have them return results such as "I've hit the ground or a wall" so that the state can react accordingly.
I could be, but it really depends on what you want changed. The system is pretty "locked in" so something that might seem like a modification or an adjustment could mean a full re-write. Feel free to hit me up on Discord to chat. My DMs are open to those who are members of the GM Discord server: https://discord.gg/gamemaker
Technically true, but pinhole is maybe even a bit of an exaggeration.
The system is sort of designed to be instantiated on game start and then just... stay in place for the duration of the game. So you should never re-init the system, and you don't need to clean up the stack when the game is closed because the OS will clean up any and all memory the game is using.
You are welcome to call ds_priority_destroy in the game_end event if you'd like, but I just thought it unnecessary.
So, check out this tweet:
https://twitter.com/Pixelated_Pope/status/1516815617109635073?s=20&t=VWha6dl9I8t...
Just call that function in your step event before movement_and_collision (or after or both, honestly) and you'll never get stuck in a wall and freeze the game ever again
Oh, yeah. If you drop the player on a wall, it's likely not gonna move. Seems to happen to me for both keyboard and controller... because the player is stuck in the wall you dropped them on.
This is something you can solve with a "get out of the wall" function easily enough, and not really something I plan on fixing as part of this package.
No, you don't need the first one. Just the ones labeled HTML. In fact, if you build for HTML with the non-html shader in your project, there's a good chance the game will yell at you. You'll have to remove it from your project completely because Yoyo doesn't allow you to specify assets per export, unfortunately.
I was hoping that the issue would sort of "auto resolve" with the new floating point collision detection. Though I haven't tested recently with those changes. I had a solution in the past, but it was very complicated, and it's much easier to set your speed to 1.251 or something.
And as a rule, we don't worry about performance until there is a tangible issue. So as far as I know, there is nothing to be concerned about performance wise.