Object instances are for things like actual game entities and graphics moving in complex patterns.
#Gamemaker studio 2 room speed code#
If you have animations that are static, have an object call all of them by drawing sprites (with code you might be able to make them move as well). One golden rule in GM is: If it's a static graphic that you may at most create/destroy/set-depth on the fly, use tiles. No, tiles can't be checked directly for collision, and I'm not sure if you could do it with code, but it wouldn't hurt to try. Objects instances need to be used as little as possible. The FPS went down to around 10 or so, proving that even if an object isn't doing much, just for it being there it bogs down your game. Then I did 1000 object instances doing one collision detection each step each. The FPS was around 100 at most (set the room FPS to 9999 or something to see how fast it can go). I did a GM example where one object called a collision detection function 1000 times in a step. If you really want to know GM's limits, experiment. At the moment I am drawing it as a two-frame sprite but would it be better to do it as two backgrounds? Or to draw it from primitives?Īlso - it's probably a good idea to use low-colour images rather than 24 bit ones, since the game will be smaller and load faster but does it make any difference to drawing speed? It has a typewriter ribbon in it, which is quite big on the screen (maybe 100*200), but which is simple and only has two frames of animation. This question has come up for me in the game I am working on for the commonplace competition. But maybe I'm misunderstanding things here. What is the difference between sprites, surfaces and backgrounds? And aren't they all done as textures through 3d cards, these days? If so, it seems to me they should be drawn quickly, even if they are big but what limits you will be the texture memory on the graphics card and how long it takes to copy to it. Are lots of instances a problem if they aren't doing anything on screen, and don't have any step events, but are just being used as data storage somewhere in the background?ĥ. If you don't have to do it every step, then don't! Whenever possible, reduce the size of your Step Events, and also the number.
so the more you do in the Step Event, the slower your game will be. Step Events are, of course, called every step.
Whenever possible, turn off "Precise collision checking," which is a per-pixel collision detection method. If you need to look up the return value of any slow function more than once, consider putting the value of the collision in a variable and check the variable instead. Make sure you're not doing the same collision check more than once in a single step. make sure that event goes in the player object instead of the bullet.Ĭollision functions (and trig calculations) in general are pretty heavy, so it's a good idea to have as few of them as possible. You obviously have to do a collision check between the two objects. A good example is the player versus the 100 bullets. So place those events in the objects which will have the fewest instances. Objects that have collision events are much slower than objects that don't. They're not completely static.īackground details that you don't actually interact with are perfect tile material. You can actually do a lot of things with tiles, like create and destroy them, set their depth, get their position, etc. Tiles are much, MUCH faster than objects, so you should use them in place of objects whenever you can. If you set the argument "notme" to true, the object will ignore itself in the deactivation. Make sure you don't deactivate important objects (like the object calling the code!). Instance_activate_region(view_xview, view_yview, view_wview, view_hview, true) Instance_deactivate_region(view_xview, view_wview, view_hview, false, true) Try deactivating anything that's outside of the player's view, and destroy anything that's outside of the room.įor example, put this in the Step Event of an invisible object that sits in each level: To that effect, instance_destroy() and instance_deactivate() are your friends.
And the more work an object is doing each step, the slower it will be, so take care to make sure nothing is awake if it's not needed. I've heard that ~50 instances is the most that you should have awake at once. Object instances slow down Game Maker a LOT. Here are some tips, from what I think is the most important, to leaster. And now I pass that knowledge down to you! But with a little research, and some good advice from experienced GM users, I started to make some optimizations to my game that significantly increased its speed. Game Maker is kind of notorious for being slow anyway, so it didn't take long for me to hit its limits. Intro: Since I'm a pretty mediocre programmer, I often go for an easy solution to my coding problems rather than an efficient one.
0 kommentar(er)
