Sean Catherine
Member
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.
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.