Moving over to GameMaker from Unity. Have a few questions (sprite sizes, rooms, physics).

G

Guest User

Guest
Hi everyone. New to the forums, apologies if this is the wrong place to post.

I've been making a 2D platformer for awhile now using the Unity engine, but I'm thinking it might be best to look at some other alternatives due to the current state of Unity. I've boiled it down to two other engines, those being GameMaker and Godot. I've picked GameMaker first since I'm already somewhat familiar with it, including actually releasing a game a few years ago with the first GameMaker Studio. It was a tiny game made more for learning, but a game nonetheless.

I've been spending the last week or so learning GMS 2 and how it's changed from the original. I want to get started porting over parts of my game to test it out, but I have a handful of questions I'm still unsure on and was hoping to get some clear answers.

For context, the game I'm making is, again, a 2D platformer heavily inspired by games like Smash Bros. and Kirby, but unlike what seems like most other games, it uses high resolution, hand-drawn sprites and I'm looking to release on PC and maybe consoles in the future. In other words, no pixel art, no mobile. Aiming for a 1080p resolution.
  • How good is GMS at handling big sprites? I'm more of an artist than a coder, so I'm really particular about these. My default sprite size is 512x512 (Characters and terrain tiles are at this size for example). I make sprites in an external painting program at a minimum resolution of 2048x2048 or bigger when needed, but I never go below those numbers. I then scale them down to a smaller size before exporting the sprite/animation as individual PNG images. This approach worked fine with Unity, but I'm unsure if it'll work with GMS. I know the engine is capable of doing HD sprites, but can it handle multiple sprites with sizes around 512 to 1024, or possibly even bigger (some of my bosses might be huge)? If not, what's the best way to go about it? I read the manual on things like texture groups and pages, but I'm not sure if I completely understand them.
  • How big should room sizes and the camera be? From what I've read, I think it's okay to have the camera be 1920x1080 for an HD resolution and if that's the case, some of my rooms are probably going to be really big then. Is that sort of thing going to be compatible with my sprites or is there going to be some problems?
  • Finally, do I need to use GameMaker physics? I briefly saw this topic in the manual, but have only skimmed over it. From what I understand, is it like realistic kind of physics, sort of like how Unity works? If it is, I'm guessing I wouldn't want to use it in my game if I'm going for a classic platformer feel, right? I know this is probably a dumb question, but I figured it's best to know anyway just in case.
Any feedback on this is appreciated! If there's something I said that's not clear, let me know.
 
1) GMS does an average-to-good job of handling large sprites by itself. However, depending on exactly how many large sprites and what you are doing with them, you might get better performance by handling more things yourself, which can get kinda technical. Bigger sprites mean more texture pages which means more texture page swaps which, in turn, means less "wiggle room" before things start to slow down. This is impacted by all sorts of things, the kind and amount of logic you want running in each frame (as in, AI, data processing, etc), how efficient your code is, the specs of the computer running the game, etc, etc. Whether the amount of texture swaps you will need is going to actually impact the game enough to cause slowdown isn't necessarily something you can know beforehand. Testing and benchmarking are your friends. Once your FPS starts dipping below 60, start using the profiler to see what the heaviest thing is in the game and optimise that. It might be texture swaps or it might be some super un-optimised code you've written. Refactoring, rewriting and restructuring are all necessary parts of game dev...You will have to do it at some point, so don't feel too bad if you get partway through a project and have to go back and restructure how the graphics are handled or something because of slowdown.

2) Room sizes can really be any size, but if you have an absolutely massive room with a lot of instances, at least expect maybe some slowdown in GMS itself (I dunno about in-game, I tend to run in proc-gen crowds so I'm not really using "room size" in the traditional sense). You might want to look into "chunking" (loading parts of the level on demand, rather than loading the whole level at once at the room start), though again, this kind of comes down to exactly what you are trying to do. You might be able to get away with the default way GMS handles rooms, or you might have to chunk, depending on the size and complexity of the level combined with the specs of the PC running it. If GMS itself starts to slowdown, you might want to write a custom level editor (depending on how big your game is and how long you intend to work on it) which can generally be optimised much better for your specific needs (meaning it will both run faster than the GMS editor (not actually in-game, but while editing, is what I mean) and you will be able to build levels faster in it as it is targeted towards what you need in your game).

3) No, don't use GMS physics. It's basically targeted at one thing: Physics Games. Think angry birds, etc. You can do other interesting stuff with it, but for anything "traditional" like a platformer, top-down-shooter, RTS, whatever, you don't want to use physics.
 

NightFrost

Member
Rooms can be as big as you want them. Most of the load on CPU comes from the amount of content you put in. Unless you're starting to approach thousands of instances running lots of code in the room, you probably don't need to initially pay too much attention to it. Profiler is your friend at finding performance bottlenecks. When doing platformers, there's alternatives to purely instance-based terrain too. GMS can check for tileset collisions for example. And you can do the instancing-only-what-is-necessary aka chunking mentioned above, but that makes level building a bit more tedious.

GMS uses Box2D physics engine, which I think is the same in Unity. Generally, 2D projects in GMS don't go for physics engine unless there is real need for various physics-related mechanics. Using "cartoon physics" where you simulate some small aspect yourself, like gravity in a platformer, is usually good enough. You don't bring a sledgehammer to pound a nail.
 

kburkhart84

Firehammer Games
How good is GMS at handling big sprites?
GMS can handle all of this. There is a texture paging system that makes things more efficient so that you don't hog up all the VRAM. GMS puts all the graphics onto pages(think texture atlas), so several frames of one of your 512x512 sprites would end up on a single 4096x4096 texture page, and the sprite drawing system automatically handles the UVs for that so you don't mess with it. This is certainly more efficient than having to have bunches of smaller textures being sent to the GPU.

What was mentioned above is that you can directly control which textures are on the GPU for efficiency. You group your sprites into texture groups, and then you can pre-load these groups as needed so there is no hiccup when you first try to draw them. And you can flush out the graphics you don't need between levels as well. So for example for a smash bros game, you could group each level's specific graphics into a group, maybe have each character in a group, and all things that will always be needed(items, GUI stuff, special effects), put those on another group. Then before loading a level, load that level's group, all the characters' groups that are participating, and the group with all the other needed stuff. Then when the level is done, you can flush out all of those for going back to the menu system. This way, when you go to a different level, the other level's graphics aren't in the GPU taking up VRAM.

In general, GMS will upload the textures to VRAM as they get used. I'm sure they get taken out and swapped as needed, and if VRAM gets full, they have no choice but to swap out. Since you are on PC, you can count on higher specs than on mobile, so in reality you may not actually ever have an issue with your textures and even need to mess with grouping, etc... especially if you are specifically targetting gaming PCs with dedicated GPUs. It is certainly worth doing for lower end users though if you take the time to learn the system.

How big should room sizes and the camera be?
Rooms can be any size in the IDE....but in game they technically don't have a size in some ways. If you have object instances outside of the room they are still there, and if the camera moves to that region they would still draw...the room size is more for the IDE than for the run-time, though there are certain events and variables that use the size you set in the IDE. If you want to target 1920x1080, then yes, that's the size of the camera you probably want. The camera is technically a separate thing from the viewport though, and what the camera sees can be scaled to the actual screen where it is being drawn, meaning you could draw everything at half size and scale up to 1080p if you wanted. It also means if you do everything at 1080p, GMS can handle it just fine if someone has a smaller resolution, although if you don't handle it yourself you will get either some stretching or some black bars depending on the settings. And as far as your sprites go....you only need to make sure the sprite sizes make sense for the world you are doing and the sizes of other sprites, and the total target rendering resolution. If you are at 1080p, then a 512x512 sprite will take up roughly one-eighth of the screen, and that is the only part you need to determine and worry about as far as the sprites go when discussing the cameras and views.

Finally, do I need to use GameMaker physics?
Just like the other engines, it's optional. As others have said, use it only if you need it for your game. I'd say probably 95% of games don't use it but I don't have any research to backup that stat.
 
Last edited by a moderator:

Rayek

Member
I would refer you to the related discussion about Cuphead (and whether it would be doable in GM):

You mention another alternative game making platform. I'd like to mention that G offers VRAM compression for images in video memory - which I think would potentially become important in your case. VRAM compression is (as far as I am aware, and discussed in the aforementioned article) not directly supported in GM. In G it is a simple import option and slider.

Just something to consider and test. It makes quite a difference in VRAM usage.

This said, VRAM compression might be possible with shaders or other work-arounds in GM. But it does mean doing the hard work yourself. (Perhaps VRAM compression for graphics is on the radar for GM? Not sure - perhaps someone can chime in here.)
 
G

Guest User

Guest
Thanks for the replies so far everyone!
I would refer you to the related discussion about Cuphead (and whether it would be doable in GM):

You mention another alternative game making platform. I'd like to mention that G offers VRAM compression for images in video memory - which I think would potentially become important in your case. VRAM compression is (as far as I am aware, and discussed in the aforementioned article) not directly supported in GM. In G it is a simple import option and slider.

Just something to consider and test. It makes quite a difference in VRAM usage.

This said, VRAM compression might be possible with shaders or other work-arounds in GM. But it does mean doing the hard work yourself. (Perhaps VRAM compression for graphics is on the radar for GM? Not sure - perhaps someone can chime in here.)
It sounds like it might be a bit of a pain to get my game working in GM then. On average, my animations can be anywhere around 10-30 frames (sometimes more, sometimes less) and I did use Unity's built-in compression, which managed to get low build sizes while still performing flawlessly. Is the lack of native compression the only thing that's preventing it with GM then? I went through that thread and from what I'm getting is that it's doable, but will require a ton of extra work to make it happen efficiently.

EDIT: Couple of words

EDIT 2: I'm digging a little deeper into texture pages and groups and got a few other questions. Given my target platforms, how much do I need to worry about texture swaps? And does having bigger texture pages lead to more memory usage? (I'm assuming it does, but it never hurts to ask just in case). I'm not sure if it would be better to have bigger pages due to the size of my sprites or if I should just not worry about swaps too much. There's probably a few hundred frames of animation on my player alone and I imagine that would cause a lot of swapping on a 2048 sized page.

Also, I just tried testing the project with the debugger and I'm getting an average fps count of 20000 - 27000 and an average memory usage of 7.3 MB (at least I'm assuming that what that means). Granted, not everything is set up with GM yet, it's currently a 1920x1080 room with the player's standard idle loop going off which has 30 frames of animation on it. No code or anything.

And just to clarify: does the camera directly affect the resolution of the game? If so, I'm guessing I wouldn't want to make the camera bigger just to make everything look smaller, right? Because right now, my sprites do take up a lot of screen space.
 
Last edited by a moderator:

Yal

🐧 *penguin noises*
GMC Elder
And just to clarify: does the camera directly affect the resolution of the game? If so, I'm guessing I wouldn't want to make the camera bigger just to make everything look smaller, right? Because right now, my sprites do take up a lot of screen space.
The window size of the game is set to the total viewport size of all views that are visible when the first room is loaded (or the room size, if views aren't enabled) and by default the window size and internal resolution are the same. So if you want your game to have a 1920x1080 resolution, make the first room at least 1920x1080 pixels big, enable views, make view 0 visible and make it have "view in room" and "port on screen" sizes that both are 1920x1080. To shrink the internal view down, you'd e.g. make the "view in room" 3840x2160 big while keeping the "port on screen" 1920x1080.

Not sure if you still need answers for your original questions, but here goes:
  • All engines start having issues when you need to have smoothly animated HD (500px+) sprites, the Skullgirls devs had a GDC talk detailing all the hoops they had to jump through to even get the game to run (it loads and unloads sprites dynamically all the time because there's not enough VRAM to have everything in memory all the time, one of the ways it masks it is by having a lower-rez version of the entire spritesheet and then just drawing that upscaled a bunch if the "real" sprites aren't available). You'll get more manageable VRAM usage using vector sprites (GM has SVG support) which also have basically infinitely sharp lines no matter the zoom level.
  • For best results, the view size should be equal to your intended resolution, and then you'd make room sizes based on that. For instance an idle game would have rooms 1 screen big, platformer levels usually are like 30-60 screens wide and 1-2 screens tall, etc. Things can exist outside the room boundaries just fine, so you don't need to worry about it if you procedurally generate level contents; it's mainly useful for the Room Editor and for the built-in camera systems (a camera set to follow an object automatically will not go outside the room boundaries)
  • GM's physics system is Box2D, and it's used for physics games like Angry Birds or Cut The Rope. Unless you're doing something like that, don't use it; it only makes basic movement and collisions more complicated (since you need to worry about density, inertia and things like that).
 
Last edited by a moderator:
G

Guest User

Guest
The window size of the game is set to the total viewport size of all views that are visible when the first room is loaded (or the room size, if views aren't enabled) and by default the window size and internal resolution are the same. So if you want your game to have a 1920x1080 resolution, make the first room at least 1920x1080 pixels big, enable views, make view 0 visible and make it have "view in room" and "port on screen" sizes that both are 1920x1080. To shrink the internal view down, you'd e.g. make the "view in room" 3840x2160 big while keeping the "port on screen" 1920x1080.
So, correct me if I'm not understanding this right: I'd want to make the camera properties values bigger while keeping the viewport at 1920x1080? I experimented by making the camera 5760x3240 and keeping the viewport 1920x1080 and it does seem to give the results I'm looking for, but is that an okay way to go about it? The only issue I've found so far with it is that sprites have this weird "wavy" effect when they move around. I also did another debug test (got a few more things in the room) and I'm getting frames from anywhere between as low as 1400 to as high as 20000 - 30000 with an average of around 9000 (average memory was also around 5.7). Is that sort of thing normal when testing?


  • All engines start having issues when you need to have smoothly animated HD (500px+) sprites, the Skullgirls devs had a GDC talk detailing all the hoops they had to jump through to even get the game to run (it loads and unloads sprites dynamically all the time because there's not enough VRAM to have everything in memory all the time, one of the ways it masks it is by having a lower-rez version of the entire spritesheet and then just drawing that upscaled a bunch if the "real" sprites aren't available). You'll get more manageable VRAM usage using vector sprites (GM has SVG support) which also have basically infinitely sharp lines no matter the zoom level.
Is it worth it to try and convert all my sprites to vector sprites? I make everything in Krita, which uses raster graphics.
 
Top