• 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 [Solved] GMS 2 For a 1080p Game?

R

Robzoid

Guest
My next game is going to be 1080p and I really want to use Gamemaker 2 for it but I've heard that there are performance issues when using Gamemaker for 1080p. Is this still the case? Can Gamemaker handle a 1080p base resolution without performance issues? I understand I'll need to do optimization. I just want to make sure Gamemaker can handle the game I'm going to make before I get started on it. The game is going to be an RPG for PC, Xbox, PS4 and Switch. Any help is appreciated.
 
What performance issues did you hear about? You can set any resolution you like, it's what you actually do that needs to be optimized.
 

TsukaYuriko

☄️
Forum Staff
Moderator
I'm not sure which performance issues you're talking about and I don't remember this ever being the case. There is nothing that prevents you from making 1080p games. 4K works fine too. Can test 16K if desired.
 
R

Robzoid

Guest
The main thing is this video (I linked to the exact moment he discusses 1080p):

https://www.youtube.com/watch?v=G1WxKEk6Wrw&t=6m46s

He's pretty emphatic about not using 1080p. He says that all the texture pages resulting from larger sprites would bog down the game. Is this true? or am I good to go with the 1080p game in GMS?
 
H

Homunculus

Guest
Note that he specifically says "pixel art games", and that's not because GM isn't capable of handling that resolution, but because making a pixel art games at 1080p is generally a silly idea.

He also specifies in a comment below that 1080p for non pixel art games is totally fine, but due to the possibly very long building times (due to "compiling" graphical assets) it's not advised unless you have a reason to target that resolution (meaning that if your game is targeted towards low end devices, it's probably a good idea to go with a lower res). Even in this case, it's not related to performance nor limitations posed by GM itself.
 
The key words being "pixel art". GM can also do vector-based and 3D graphics. Those make it much easier to deal with higher resolutions than pixel art. What the video is getting at is that the higher resolution your pixel art is, the greater the effort it will take to maintain quality. You're drawing each pixel by hand, so increasing res increases your workload exponentially. Much, much easier to make a 320x180 image look good and then blow it up to 1080p.
 

TsukaYuriko

☄️
Forum Staff
Moderator
I'd assume that "pixel art" really refers to "small sprites", as sprites of any size are technically pixel art. Imagine if your game was laid out in a 16 by 16 pixel grid and you had rooms which are at least of 1080p size - it would take ages to fill out that space.

High resolution graphics or a lot of graphic resources existing do not contribute to "bogging down the game". What matters is what you're actually drawing to the screen, and in what order (amount of draw calls and texture swaps, respectively).

Compile times resulting from texture pages are among the lesser issues. Your game is more likely to suffer from long compile times due to other causes. Even then, pre-compiling your game's texture pages and loading them dynamically pretty much eliminates the compile time overhead of texture pages for test builds. When doing a release build, you can let the texture packer do its default job, and the majority of the compile time at that point should be caused by YYCing your code, anyway.
 
R

Robzoid

Guest
Note that he specifically says "pixel art games", and that's not because GM isn't capable of handling that resolution, but because making a pixel art games at 1080p is generally a silly idea.
Even though I see the term used a fair amount, I'm not 100% sure what pixel art actually means. My assumption is the same as TsukaYuriko's. I take pixel art to mean sprites that are small enough that they look pixely. Large sprites that look smooth would not be considered pixel art - even though they are still composed of pixels. Is that correct? If that's the definition of pixel art, then it makes sense to me not have a 1080p game full of these little sprites. That would indeed be silly.
 
H

Homunculus

Guest
Yes that’s also my definition of pixel art, and I’m sure that’s also what pixelated pope meant in his case
 

JackTurbo

Member
The main concern for a 1080p game in gms would be ram and vram management I'd have thought? Kupo could probably provide some insight to that as I know he's spent a decent amount of time on such systems for his fighting game
 

Ricardo

Member
I have a 1080p HTML5 game that run smooth even on mobile's browsers. There's nothing wrong with GMS2 and the way it handles resolution or texture pages, always and when you know what you are doing - and that apply to any game engine really.
 

JeffJ

Member
Just as a test, I set my current game to run in 4K on a native 4K monitor. It ran like a charm. 1080 is obviously more than doable too.

It really has everything to do with the game. The bigger the resolution, the more stuff you can see at any one time, which means more things have to be rendered and maybe processed. It is up to you how to handle that.
 

MeBoingus

Member
Here's a short write up on stuff that one should take away from those "15 commandments."

1. Thou shalt read the manual and seek guidance within before asking others.
Read the GMS manual for the specific thing you're battling with. Look around on the web to see if your question has been asked, and if a solution was found.

2. Thou shalt not use Drag and Drop.
This is completely dependent on the user. Telling someone who hasn't got the slightest clue about GML that they should never use D&D, is about as useful as it sounds. When you're starting out in GM, using D&D is absolutely fine. A lot of the best games you've played (that were made in GM, at least) had some D&D in them, somewhere or another. D&D is essentially just shorthand for code. It's not the best way to achieve what you're trying to do, but if it's the only way you know, work with it for now.

3. Thou shalt manage thy white space.
Tab your code out nicely. It doesn't have to follow any kind of exactly style, as long as it's consistent and readable for future you. If it's code that you're giving to other people, try to make it understandable for them, too.
In fact, it does have to follow an exact style. Every time you put a curly bracket {} on the same line as the statement that precedes it (I.E "if (a==b) {") and angel loses their wings and a portion of your RAM is sold into crypto-mining slavery.

4. Thou shalt name thy variables descriptively and consistently.
Self explanatory, really. Name your variables after sh*t you'll understand later on. Duh.

5. Thou shalt not use persistent rooms.
This absolutely depends on what you're doing. Making a mini game where someone has to walk between two rooms and pick up a couple of items - go wild. This really only pertains to SAVING later on, but it's only an issue if you don't understand what GM is doing 'under the hood.' Avoid using it, but if it were something that was never meant to be used, and had thousands of issues... it wouldn't be in the engine.

6. Thou shalt not use the physics engine if your game does not require a physics simulation.
A lot of people may agree with this. There are much better ways to handle collisions without the use of Box2D... but if you want to, and you understand what you're doing, then go nuts. This is really more about personal preference and understanding of how Box2D works with GM.

7. Thou shalt not make thy pixel art game any larger than 960 x 540
This is because it isn't necessary in most cases.When it comes to pixel art, the goal is for the game to look and feel retro, most of the time. GM is not going to crash and burn if you use a greater resolution than this. Most of the stuff I make in GM is 1920 x 1080, running at 60FPS. And hell, this is also entirely dependent on what type of game you're making. I've made pixel-art games that run at 1080p, 60FPS with absolutely no issues whatsoever. This is just a really weird thing to pick on.

8. Thou shalt not use Object Following for your game's camera.
This is also perfectly acceptable. There are ways to do it through code, but if you're just doing something fairly simple, that isn't going to require anything more than what Object Following has to offer... why would it be an issue? If it works, it works.

9. Thou shalt use double equals (==) when comparing values.
Yes.

10. Thou shalt not use 1 in place of True nor 0 in place of False.
This one is just ridiculous. If you cannot look at a 0 where a true or false would be expected and instantly go "Oh, that clearly means false!" Then you shouldn't have taken up this gig. 0 - false. 1 - true. It's not rocket science. There is absolutely no difference at the machine level. This is purely an aesthetic thing.

11. Thou shalt not use magic numbers.
This is good advice, overall... but once again, it depends on the situation. If I'm making a tool, or a bit of software in GM, and I know that 100% of the time, I'm going to need to draw something at a very specific position... why would I want to assign variables to that? In that case, you're just wasting memory.

12. Thou shalt not use the "self" keyword.
Sure. It's basically just here for legacy support. It's never REALLY necessary anyways.

13. Thou shalt not preemptively worry about performance issues.
Absolutely awful advice. Why would anyone EVER tell people not to worry about optimizing their games as they're coding them. Sure, don't fret over the super minor stuff... but optimize your code where possible, while you're writing it. It'll save you literal hours of work down the road, trying to find where the bottle neck in your game is coming from. Awful, awful advice. If this 'commandment' was a human being, I'd throw it down a well and build a high rise on top of it.

14. Thou shalt not use the "Solid" checkbox, nor the associated scripts.
If you're writing an entire, massive game - this is probably some great advice. However, once again, if you're just working on a small project, or you understand how GM handles this setting and its related scripts... go ahead. If you know what you're doing, and understand how to change things later on, if you REALLY want to, then use this method.

15. Thou shalt use the Draw GUI event to draw things relative to your game window.
This is also completely dependent on your specific needs. There are many situations where using Draw GUI is helpful, and there are many where you may want to approach the problem from another angle. I.E. Draw GUI does not take depth into account. It draws on top of everything, in order of each object's time of creation. If you understand how Draw GUI works, use it. If you don't, learn about it, or stick to the way you know how. Because it makes very little difference to the overall outcome of your game, or the performance as a whole.
 
Last edited:

kupo15

Member
And hell, this is also entirely dependent on what type of game you're making. I've made pixel-art games that run at 1080p, 60FPS with absolutely no issues whatsoever. This is just a really weird thing to pick on.
Your pixel art game can be displayed at 1080 resolution, however drawing pixel art at true 1080 scale defeats the purpose of making it pixel art. Pixel art looks that way because the resolution is smaller which makes the jaggies more pronounced. If your game art looks like ms paint, making them at true 1080 scale is not a good idea nor is it necessary. Better to make them smaller in the actual resolution those graphics actually need and simply image scale your objects/draw event

To add to the ram discussion... there is a cool function texture_scale (something to that effect) where you can manually load into vram tex pages of reduced size. So you could make your game at true 4k if you wanted to and only if your graphics need that, throw that code to reduce your tex pages by half to bring it down to 1080 size. Add it as an option and then people with supercomputers can take advantage of the full glory. Pretty cool! Though I tested it against manual shrinking down and it seems like the quality of the downsizing from the function isn't as good which I find odd.
 

Mert

Member
As an atheist, lemme step in:
6. Thou shalt not use the physics engine if your game does not require a physics simulation.
A lot of people may agree with this. There are much better ways to handle collisions without the use of Box2D... but if you want to, and you understand what you're doing, then go nuts. This is really more about personal preference and understanding of how Box2D works with GM.
Wrong. You can achieve a really catchy main menu with physics based theme even though your game is not a physics game! Remember that physics system includes some codes and variables to your game, but in a wider look, it really doesn't cost you much. So, don't be afraid to use physics system. I highly encourage you to use the "Soft Body Particles" physics_particle... to get awesome UX in your game.

10. Thou shalt not use 1 in place of True nor 0 in place of False.
This one is just ridiculous. If you cannot look at a 0 where a true or false would be expected and instantly go "Oh, that clearly means false!" Then you shouldn't have taken up this gig. 0 - false. 1 - true. It's not rocket science. There is absolutely no difference at the machine level. This is purely an aesthetic thing.
All variables in GM are either String or Double. True is actually = 1 (double), so when you write TRUE in your game, Game Maker actually turns it into 1 when compiling.

As you said, only aestethic, but 0 and 1 are aestethic too, at least for me :)

8. Thou shalt not use Object Following for your game's camera.
This is also perfectly acceptable. There are ways to do it through code, but if you're just doing something fairly simple, that isn't going to require anything more than what Object Following has to offer... why would it be an issue? If it works, it works.
Idk if you suggest it or explain to avoid it. You can "follow your main object" and act to set it as a camera. After all, it uses built-in x and y variables, right ;)
 
Wrong. You can achieve a really catchy main menu with physics based theme even though your game is not a physics game! Remember that physics system includes some codes and variables to your game, but in a wider look, it really doesn't cost you much. So, don't be afraid to use physics system. I highly encourage you to use the "Soft Body Particles" physics_particle... to get awesome UX in your game.
Doing a physics-based UI, hmm... Sounds like your game requires a physics simulation ;)

That "commandment" was basically just ragging on Heartbeast's RPG movement tutorial where he used the physics engine to do very basic 2D movement. Extremely unnecessary, and can cause newbies tons of headaches. IIRC, about a year or two ago the Programming forum here was flooded with people having errors because they were following the tutorial and using physics to do simple movement.
 
R

Robzoid

Guest
People need to stop giving excessive credibility to stuff "they hear".

Make you decisions based on your experiences, with your your assets and your skills. Should you encounter challenges, then seek guidance relevant to your issues.
I'm all about testing things out myself before asking questions, but this is something that I can't test with my given knowledge. My concern was that, as the 1080p project grew with more and more sprites, it would eventually get bogged down from texture page swaps which would potentially make the game unplayable. I can't test this without putting in hundreds to thousands of hours into the project. It doesn't make sense to do that when I can just post the question here. I agree with what you say in general, but there are cases when testing something just isn't practical. In those cases, all you can rely on is what others tell you.

Anyway, I really appreciate all the input on this is. I was worried I was going to have to switch to Unity, which I find to be a very boring, tedious engine to work with.
 
Top