• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion "Optimization" —A New Guy's Take-Aways... [SOLVED]

I've been reading a heck of a lot lately on the forums, trying to get a grip on how to go forward with my project. "Optimization" seems to be the most prevalent, important subject I'm seeing... Here is a numbered list of points that I'm either confused about, or am way off in terms of context/understanding for GMS2:

1.) Texture page sizes. It seems like everywhere I've read in the forums, and even in the game manual, the size limit is said to be 2048x2048. Am I confusing "texture page size" with "sprite size?" I ask because I noticed that one may choose in "options/graphics" menu all the way up to 8192x8192 for a texture page size. I actually chose the largest size once, I made a sprite that big and plopped it on a room of the same size... When I debugged, everything worked and there were no output messages stating that the sprite needed to be rescaled...

2.) Tiles vs. sprite (objects) vs. "sprite as background" —what is best? So these are the 3 choices, it would seem, for one to "decorate" a room. I've read that tiles are the most efficient when it comes to putting down scenery, but that they are slow to be drawn. I've read that objects in a room are very inefficient, and I haven't seen a lot of discussion regarding the use of a sprite as a room background. What would be anyone's opinion on the following:
* I draw a sprite that is 8192x6144.
* I chop that up into 4 pieces, each being 4096x3072.
* I make objects for each (no code whatsoever for them).
* I put them on a room that is 8192x6144 like a puzzle in there own exclusive instance layer. And btw, the room editor will show faint lines between those pieces, but you do not see that when game is running... Are there any negative, unseen effects? I read somewhere of a guy "stitching" his pieces together in a similar situation (with code), why would he do that?
What about this:
* I make a sprite of 8192x6144 and assign it as a background for a room of the same size... It does work, but what might be the negative effects that I'm not seeing, as fps run in the 5000 range with that approach?

3.) Game as a whole vs. room-to-room approaches. Unless I'm mistaken, one could make Avery vast and complex game as long as they optimize. It seems that optimization —from everything I've read— comes down to how rooms are individually dealt with... Let's say I make a massive game that consists of 40 rooms each at a size of 8192x6144. My understanding is that as long as one does there best to minimize "texture swapping" they will be pretty well off by having many many rooms of many many instances. It's all about keeping the resources together for each room. Why for example does "YoYo Dungeon" not run at 3000 fps or more given that the assets in that game are so neat (so few texture pages, relatively speaking)? Is it because of the many layers in the room? Do multiple layers play a big role in optimization (more so than other things)?

Just a few final mentions... I know that coding itself is a very major determinant regarding optimization. I should also point out that I use DnD with some added GML. I'm at the beginning though, and I need to settle these "resource-based" issues before going too far forward.
 

Kaliam

Member
Sprite Size:
The maximum sprite size is what you set it to be in your options/graphics. if you set it to 2048x2048 (which is the default), that will be the max sprite size you will be able to display properly. But likewise if you set it to 8192x8192, you can have sprites of that size. If you add a sprite larger than 8192x8192, by default, gamemaker will actually resize/scale your sprite to some size below 8192x8192 (or whatever your setting is) and your game should run properly. However the sprite will have actually been resized to fit within the 8192x8192 limit. You can actually see this happening when you compile a project if you read the Output. Obviously sprite size will affect performance, but that's another topic.

Room Background:
When it comes to a room background, unless your background is supposed to be made up of tiles, I wouldn't use the tile layer. Using a sprite should work just fine for the background and you can use an object to draw it for you. The the advantages of this is that you can use the draw event in that object to manipulate the background. The performance drawback of using one or even 4 objects for your background will be minimal. The overhead cost of having an object only really starts to affect performance once you have 1000+ objects in a room. You could also use the room background, or the asset layer which lets you place sprites directly in a room. But these won't offer as much control over the background as having an object would. If you want to draw the background in parts, you can actually do this with just one object, you would just need to use the following method/code:

Code:
draw_sprite_ext(sprite, subimg, x, y, xscale, yscale, rot, colour, alpha);
Room Size:
As far as number of rooms, and size of rooms, neither of these things will affect the performance of a game, rooms exist independently of one another and gamemaker can only have one room active at a time. So whatever is in that room is what's taking up performance. I would recommend not creating rooms larger than 100,000x100,000 because of how gamemaker draws things to the screen. going above that limit will cause graphical glitching, but it won't affect performance.

Running your Game:
One big thing that affects performance is using YYC (YoYoCompiler) vs using VM (Virtual Machine). YYC will have around double the performance over VM, but VM will compile your game faster and is far better for quick testing and programming because you don't need to wait as long for the game to compile. You can change this setting in the top Right of GMS2's interface.

Yoyo Dungeon
As far as YoYo Dungeon goes, it uses quite a few layers, animated tiles, but also shaders for lights and other effects. If you run if on YYC my laptop with intel integrated graphics will get around 600fps. But clearly the game is nowhere near it's limits. If you doubled everything, I would get around 300fps, and it kind of increments like that. I could probably run around 8x of what YoYo dungeon has at around 70fps on my integrated chip which is pretty good dang good.

YoYo might disagree with me on this, but the reason why the performance of YoYo Dungeon isn't super amazing is because of the way that gamemaker works. Even when an object is off screen in gamemaker, it's drawing cost doesn't change in terms of the effect it has on performance. So you could have 1000 objects off screen and they would still cause your game to lag because of the cost of running their draw events. This is the same for tile sets, it doesn't matter where you are they will always take up draw time. You can get around this by deactivating objects when they aren't on screen, or by setting their visibility to false. Doing this will cause an object's draw event to not even run, which increases performance drastically when an object is off screen and is probably something YoYo should implement natively in GMS2.

Collisions:
One other thing that kills performance in gamemaker is collisions. Gamemaker is programmed in such a way that everything is global. What this means is if I have an object at 100 x and 100 y, and another object at 50000 x and 50000 y, gamemaker would still check their collisions despite them being extremely far away from each other. So in a game where you have 1000 objects that need to check if they are colliding with each other, each object is going to test all the other 999 objects for a collision. This means that every game frame there are 1000*999 collision checks being done, that's 999000 collision checks, and it has to do that 30 or 60 times per second. You can get around this by creating sectors in a room, and then only checking collision in those areas, but the bottom line is that GMS2 wasn't really made for large scale games, and if you want to do that, your going to need to a lot of work creating your own system to handle collisions.

Some Simple Tips:
If you want good performance without doing lots of optimization, use lower resolution sprites, less texture swaps, and fewer objects.
If your planning a big game, but don't want to have to write code to insure good performance, use lots of rooms to limit the object and draw counts.
If you are using tilesets, don't make rooms too large or that will cause poor performance.
If you want to use large sprites, don't draw too many of them on the screen at once.
Don't draw sprites at a super large scale, scaling sprites very large will cause lag.
You can have a high resolution background, just don't draw too many high resolution sprites on the screen at once.
If something doesn't need to be active, deactivate that object and reactivate it when it's on screen or close enough to the player.

Sorry for the wall of text, but I hoped some of this helped. I know your new, but I highly recommend learning more GML, it will help you with performance once you understand things better. For now, if you are still using DnD, I wouldn't worry too much about highly technical things. Focus your efforts on learning more about gamemaker itself and how things work and how to use them, then worry about performance.

If you have any other questions, feel free to ask.
 
Last edited:
Thank you for all of this info. I do have some questions... How does having lots of rooms limit object and draw counts? Regarding tilesets; let's say I had 20 of them, but only one of those sets was used per each room... Would the game loose momentum to those tile sets that are not on screen at a given time? What is your opinion of having 16 sprites at a size of 2048x1536 on a room that is 8192x6144? thx
 
I almost forgot to mention... I was working a little earlier and tried making five rooms the size of 8192x6144. I made sprites the same size and used them as backgrounds. When I debugged, I got these messages: Screen Shot 2018-01-06 at 3.23.03 PM.png Screen Shot 2018-01-06 at 3.14.49 PM.png
So when this happened, my mouse became out of control. I didnt send that error report because i was worried it was some glitch or something. The weird thing is that I properly set my texture size to the 8192x8192. As far as the memory, it was somewhere around 47 mb.
 
You know that texture is crazy big! (~256Mb)

4K TV UHD-1 resolution is only 3840 × 2160 pixels.

For your purposes, and for the protection of pixels everywhere, reduce your texture sizes!

The error means what it says, you're system is running out of memory trying to create those textures.

If you had just 4 of them in your game loaded, that is over 1Gb of memory!
 
Thanks, IB, but it seems as though I get more confused the more I find out. It's strange you mention the 4K because I set my camera to 3840x2160 and the port to 1920x1080. I have plenty of ram on my system (32bg)... I have an app that I watch while I'm working to show how much I'm using and I was only up to about 7 when I got that message. I need to somehow find out how much data is the limit for the actual engine. The game I'm trying to make is gonna be meant for people with a bit higher-end hardware specs/displays. Btw, I'm glad to be getting advise. thx.
 
I just finished running some test comparisons; sprite-as-background vs tile sets approach...

Sprite-as-background test is 5 rooms at 8192x6144 which each have backgrounds set to sprites that are the same size. The result is roughly 5000 fps, and about 45 mb of memory. I get the warning that I'm out of memory, and the "bitmap size" warning.

The tile set test is 10 rooms at 8192x6144. Each room has it's own tile set which are no larger than 2048x2048. The result is roughly 1400 fps, and about 23 mb of memory. Everything runs fine.

My sense is that although there is a great cost to fps using tile sets, this is how GMS2 is built to run. It seems to do best accessing tile sets, and so on, as apposed to grabbing sprites that are either set as backgrounds at a huge scale, or spites that are cut up into sizes of 2048x2048 and are placed in room as objects. I've noticed motion blur and stuttering of my test players in such environments —plenty of left over fps though... So yes, it did seem too good to be true that I could paint rooms with big sprites while having awesome fps (and no performance troubles). As for game memory, it would seem to be very clear —unless I'm misunderstanding— that the memory displayed during debugging does not represent the entirety of resources/programming in a game, but the resources/programming it requires to run it. If the former were true, my first test would be displaying well of 1gb during debugging. Am I mistaken?
 
I've been doing more tests with tiles for room sizes of 8192x6144. Yes, it works, but it is tedious. Does anybody why texture page at the maximum allowed size of 8192x8192 do not work for backgrounds of rooms? What is the memory cap for the engine? Some has got to know this... :)
 

kupo15

Member
What this means is if I have an object at 100 x and 100 y, and another object at 50000 x and 50000 y, gamemaker would still check their collisions despite them being extremely far away from each other. So in a game where you have 1000 objects that need to check if they are colliding with each other, each object has to test all the other 999 objects for a collision. This means that every game frame there are 1000*999 collision checks being done, that's 999000 collision checks, and it has to do that 30 or 60 times per second. You can get around this by creating sectors in a room, and then only checking collision in those areas, but the bottom line is that GMS2 wasn't really made for large scale games, and if you want to do that, your going to need to a lot of working around.
I don't think this is correct actually. I read that the new collision system has proximity checking as a pretest before actually checking the collisions. I think it only actually does a collision check if the boundary boxes are overlapping
 
I don't think this is correct actually. I read that the new collision system has proximity checking as a pretest before actually checking the collisions. I think it only actually does a collision check if the boundary boxes are overlapping
Even checking boundary boxes is checking collisions, though, and probably gets expensive with tons of objects. Something slightly better would probably be checking simple distance first. Chunking collisions together by area like Kaliam suggested is probably even better still - if two objects are across the room from each other, why check their collisions with one another at all?

I'm not a pro on this (my game only has like ten enemies on screen at once max, so I've never looked into it), but my intuition says you can probably do a lot in your code to save on collisions if you need to. =)
 

Mike

nobody important
GMC Elder
YoYo might disagree with me on this, but the reason why the performance of YoYoDungeon isn't super amazing is because of the way that gamemaker works. Even when an object is off screen in gamemaker, it's drawing cost doesn't change in terms of the effect it has on performance. So you could have 1000 objects off screen and they would still cause your game to lag because of the cost of drawing them. This is the same for tile sets, it doesn't matter where you are they will always take up draw time. You can get around this by deactivating objects when they aren't on screen, or by setting their visibility to false. Doing this will cause an object's draw even to not even run, which increases performance drastically when an object is off screen and is probably something YoYo should implement natively in GMS2.
You're right - I do :)

If something is off screen, it is software clipped. We don't send it to the hardware at all.

Tile rendering in GMS2 is much more officiant. It also does matter where you are. If you have a sparse tilemap that is mostly empty in places, then these will render quicker than those that are full, although the difference is now negligible.

In GMS1.x ALL tiles in the level - every last one, was software clipped to the viewport. This was due to the fact they weren't all a fixed size, and they weren't all on fixed boundaries.
In GMS2.x this issue has been resolved, so even if you have a room that is 400,000x400,000 using 8x8 tiles, only the tiles that are actually visible are now even considered. So for example, using this massive room size with a view of (say 512x512), there would be around 65x65 tiles actually visible on a single layer (64x64 with 1 extra row/column for scrolling), which is 4,225 tiles. GMS1.x would loop over ALL 2,500,000,000 (50,000x50,000) tiles in that room! GMS2 will go directly to the 65x65 "window" and only draw the 4,225 tiles you can see.

As you can imagine...this is monumentally faster.


If after ALL this you're not seeing any speed differences, then chances are rendering is so quick, minor changes are not being noticed and that all time is spent in processing/collision checking etc.
 
Mike, not to hound you, as I appreciate your participation... But are you able to explain why the 8192x8192 texture sizes don't work when it is set to that spec? I've done everything I could in regards to clearing my assets cache, using texture groups... I would much rather use a sprite as background as apposed to making tilesets. Thx.
 

Mike

nobody important
GMC Elder
It depends on the hardware. Not every graphics card can use 8K textures. My guess is you're card can only create textures up to 4096x4096.
You lose a lot of performance doing this - not to mention memory. Being able to reuse tiles keeps memory right down. a 4kx4k texture takes up 64megs - at least.
 

GMWolf

aka fel666
My input would be: Unless you understand how modern graphics pipelines work, dont worry too much about optimization.
The main thing would be to organize your resource per texture page. (If things are being drawn at the same time, put them on the same texture page).

Be careful with deactivation too. I see people mis using it way too often, which can actually degrade your performance.
 
Thanks for the response, brother. :) I'm using AMD Firepro D500 on mac pro. Intel Xeon E5 6-core 3.5, 32Gb 1866 MHz DDDR3. I'm able to draw really well in sprite editor at that size, problem is when trying to clean, run, or debug.
 
Fel666: Thanks dude, that deactivation approach would be over my head anyways, I would think. I did finally learn the texture group approach. I see the logic of it. I come from the art world/acedemia and I'm learning all of this tech stuff brand new.
 

kupo15

Member
Even checking boundary boxes is checking collisions, though, and probably gets expensive with tons of objects. Something slightly better would probably be checking simple distance first. Chunking collisions together by area like Kaliam suggested is probably even better still - if two objects are across the room from each other, why check their collisions with one another at all?
Yep that is what I thought too. I can't recall the recent thread I was in last month where we were talking about this. I mentioned to throw a distance check before the collision check and I believe the response I got back was that it didn't really matter because of the new collision system. I'll have to see if I can find it to see exactly what was said
 
Yep that is what I thought too. I can't recall the recent thread I was in last month where we were talking about this. I mentioned to throw a distance check before the collision check and I believe the response I got back was that it didn't really matter because of the new collision system. I'll have to see if I can find it to see exactly what was said
Well, @Mike just dunked on Kaliam for his drawing advice, but didn't say anything about his collision advice, unfortunately. Mike did say that collisions could be the problem, though.

If you find the other thread, definitely let me know. I'm curious too now!
 
Last edited:

Mike

nobody important
GMC Elder
Well, @Mike just dunked on Kaliam for his drawing advice, but didn't say anything about his collision advice, unfortunately. Mike did say that collisions could be the problem, though.
If you find the other thread, definitely let me know. I'm curious too now!
Collisions are now much faster as it uses a K-Tree (I think), so things at one side of the screen won't be checked with those at the other. In 1.x, this is an "option" under "new collision somewhere", but in 2.x it's the default (and only) option.

However.... collisions are always a costly thing to do, specially if you're doing lots of GML place_meeting checks, these add up like your wouldn't believe....
 
P

psyke

Guest
About the collisions, what I've done on my game is to fill a list of visible platforms and create some scripts to check the collision only with the visible platforms like CheckPlatformCollision and so on... This works very well, but of course it depends on the style of the game as well. There are probably better ways to do it.
 

Kaliam

Member
Collisions:
Collisions are now much faster as it uses a K-Tree (I think), so things at one side of the screen won't be checked with those at the other. In 1.x, this is an "option" under "new collision somewhere", but in 2.x it's the default (and only) option.

However.... collisions are always a costly thing to do, specially if you're doing lots of GML place_meeting checks, these add up like your wouldn't believe....
Thanks for all the replies @Mike, this thread sure exploded. I'm going to have to disagree with some of the things that you said, or at least in specific situations. In my project ships need to check several things frequently, such as: selecting the closest ship as target, the collision with another ship, or projectile collisions with targets. Because my project has such a large game world with many instances of ships, I had to rework my project because methods like "instance_nearest()" and the built in collision event were causing so much performance draw that I had to come up with my own system in order to manage the performance and the collision calls. It could be that I am just trying to do too many things, but i'm not the only one who has had this problem when using great numbers of collisions.

If this wasn't an issue, assets such as the
TMC SGS Fast Collision System
by The Mojo Collective
https://marketplace.yoyogames.com/assets/244/tmc-sgs-fast-collision-system
wouldn't exist, and work so well!

I don't blame YoYo for how things work, the types games that GMS2 focuses on typically don't require thousands of instances. So if something of that nature is your goal, I have found that there are some things that need to be worked around to achieve better performance.

Drawing:
Thanks @Mike for the info in tilesets and how they work, it's helpful to know that tilesets aren't limited by room size which is great!

I didn't word what I had intended to say about instances/objects properly. GMS2 doesn't draw stuff when it's off screen, and I have experienced this. When the screen is full of high resolution sprites, the processing speed it takes to process the draw event, according to the in game debug_overlay, doesn't change in comparison to when they are off screen. However, the FPS can and will drop to single digits. What this means at least to me is that the graphics card is being fully utilized but the CPU still has excess processing per step. What GMS2 doesn't do when an instance is off screen is reduce the CPU cost of methods called inside the draw event. When I draw a sprite in the draw event, even when the instance is off screen, the cost of the draw event overall doesn't change. This is easy to see with the debug overlay, the yellow bar showing the draw event processes time doesn't change when instances are on or off screen. However, if you set the objects visibility to false when they are off screen (Thus turning off the draw even completely when they are off screen) this will decrease the performance costs drastically and reduce that yellow bar by a significant margin. This is what I had meant to say, but I was a little pressed for time.

Thanks for all the info everyone!
 

Mike

nobody important
GMC Elder
....I'm going to have to disagree with some of the things that you said....
Knock yourself out! doesn't make it not true. I'm not making any of it up.

This collision system was written before the new collision system was added. The new one should easily keep pace - or outpace this add-on.

However.... any game can beat a totally general collision systems by having more domain knowledge of their game and it's needs.

For example, doing generic collision tests will pale in performance to doing something based on grids if the game can do so. Each game will be able to take specific shortcuts for them, that probably wouldn't work for others.
 
Last edited:
Speaking of optimization, could anyone tell me the best way to deal with rooms..? Specifically, I’m wondering if they need to some how be linked, or at least set temporarily to false or soemthing like that when debugging? Does the inherit feature help optimazation, or is that just a way to cut busy work down?
 

GMWolf

aka fel666
Speaking of optimization, could anyone tell me the best way to deal with rooms..? Specifically, I’m wondering if they need to some how be linked, or at least set temporarily to false or soemthing like that when debugging? Does the inherit feature help optimazation, or is that just a way to cut busy work down?
Nah. Only one room is processed at a time.

And imheritance only cuts on busy work.
 
Also, I understand the concept of deactivating/setting objects to false or invisible when not on screen; but what about all of the other resource objects in the game that are not even in the particular room that is in play...? Do all of those need to be set to something when not being used? I ask because I did another experiment where I made 65 objects and 18 rooms. Each room contained 4 of thos objects (if my math is right, sorry). Each time I created more rooms and objects, my memory ballooned; which makes my original thought incorrect, that the memory only represents whats playing... I hope my weird auestions aren’t irritating, as I try only to ask what I can absolutely not find in the manual or elsewhere :)
 
I thought of something else, and I hope I'm right about it... Would 16 sprites of 2046x1536 take up more, less, or the same memory as one sprite of 8192x6144? Does memory scale in equivalencies?
 

Mike

nobody important
GMC Elder
I thought of something else, and I hope I'm right about it... Would 16 sprites of 2046x1536 take up more, less, or the same memory as one sprite of 8192x6144? Does memory scale in equivalencies?
Totally depends on the sprites and how much "empty" space there is.

If there is empty space around them, then GMS automatically crops that out and reduces the size - so it'd be smaller

If they are all squares that "fill" the sprite size, then they be bigger, as each sprite has a border added to aid correct rendering. (which you can remove)
 
Regarding borders, should I have them on or off when puzzling in 16 sprites into a big room through assets layer? This goes again to my "stitching" question at the beginning of this thread... I'd read a post that a guy was stitching his sprites together for some reason/ some method...
 

GMWolf

aka fel666
Regarding borders, should I have them on or off when puzzling in 16 sprites into a big room through assets layer? This goes again to my "stitching" question at the beginning of this thread... I'd read a post that a guy was stitching his sprites together for some reason/ some method...
I'm not sure stitching sprites together will give you better performance (unless it's massive and will span across multiple view sizes).

As for borders... Either way it won't really work.
Keep your sprite as a single sprite, and then use draw sprite part.
 

GMWolf

aka fel666
I've been reading a heck of a lot lately on the forums, trying to get a grip on how to go forward with my project. "Optimization" seems to be the most prevalent,
People on these forums worry WAY TOO MUCH about optimization.
Not only that, but they suck at it; they will look at the cost of accessing variables, instead of looking at their often very naive algorithms.

just do somthing, you dont even know what gm offers you yet you ask such questions.
Blacklemon is right. Just get on with your game. Optimization is something you worry about once you get performance problems.
 

GMWolf

aka fel666

kupo15

Member
I'm not sure stitching sprites together will give you better performance (unless it's massive and will span across multiple view sizes).

As for borders... Either way it won't really work.
Keep your sprite as a single sprite, and then use draw sprite part.
What I gathered from the responses to my background optimizations questions:
-Draw_sprite_part is worse for optimization and instead you should just draw the whole thing using draw_sprite
-Stitching graphics together should only happen when its bigger than the texture page size and required. Less draw calls is king

People on these forums worry WAY TOO MUCH about optimization.
*sigh* yeahhh :( A thought occurred to me about trying to optimize things, what's the point in optimizing if there is a situation in your game where your optimization system doesn't run? For example in my case I tried to hide parts of my background not in view to "optimize." However seeing the complete background is a very probably occurrence so hiding backgrounds not in view doesn't mean anything if the performance suffers in the full view.
Optimizing in this way could mask an issue in the game...though you could simply argue that in this example I picked the wrong aspect or method of optimization. One shouldn't optimize for the sake of optimizing like in my above example

I wonder if I'm that "some guy" mentioned in the OP haha o_O
 
Last edited:
I needed the latest "mono," which I downloaded and installed a short time ago. The version I had previous was only 32 bit, which I noticed in my activity monitor —this would explain the constant mono framework error lines I'd been getting. So the reason I couldn't simply go forward and make the game first was because I couldn't test anything beyond 24 mb. So I was scrambling to find some way to scale down to accommodate that. As of this morning, I've gone up to as many as 130 mb. Now I can do my artwork and not worry about it fitting. Thanks to everybody and their advice.
 

Mike

nobody important
GMC Elder
yeah... it's a "something-Tree", I can never remember which one it is :confused:

But the main thing is that it does carve up space for much faster collision testing :)
 
Top