How to properly scale your game!

T

The Last Random

Guest
This is quite a helpful post, Thank you.
I can finally fix my weird and warped screen sizes o_O
 
B

BloodCorn

Guest
Hi, just wondering if you could point me in the right direction in regards to scaling text - when I scale text it gets very blurry and strange.
 

RangerX

Member
If you would be scaling your game properly following a method in this thread instead of scaling your assets and text, you wouldn't have this problem to begin with.
 

woodsmoke

Member
Hi, just wondering if you could point me in the right direction in regards to scaling text - when I scale text it gets very blurry and strange.
Right click on your font (in the Gamemaker font folder). Click properties, then disable high quality. That should make it less blurry. Hope this helps.
 
R

Rukiri

Guest
The new camera in GMS2 solves a lot of the scaling issues, I even posted my camera on the GM subreddit, granted might be a month or so old so have fun. "reddit is blocked at work so can't go grab the code..."

A common base resolution is going to be 960x540 which is half of 1080p, and is perfect for 16:9.
Now, 21:9 is quite popular at least in the enthusiast community, especially gaming community "unless you only play CS:GO" so I'd think about a 21:9 option.
 
W

Wraithious

Guest
are all images busted for you guys?
Yes, please see this completely ignored post burried 8 pages deep in the programming forum, at least when scaling images to draw on a surface, save and load the resulting image into a sprite is concerned, which the only solution is the surface has to be a power of 2 to get it to work, and that completely breaks any scaling for mobile tricks when it comes to wanting to capture the application_surface, save, and do something with it because you'd have to scale your game and/or view to a power of 2 which no mobile devices i know of use that aspect ratio, I didn't even bother to report the bug because all my bug reports get ignored or swept under the rug with either a reply stating they have no intention of fixing it (loading animated gif's from file) or that it's not important enough to bother with (broken recognizerIntent in android)

Oh, and regarding this completely ignored post burried 8 pages deep , yes I tried setting the image number to 1 in the loading alarm, and -1, and 2, and 0, no effect whatsoever
 
Last edited by a moderator:

dphsw

Member
When designing to properly scale my game to any device - whether a mobile or a large tablet - it would be more helpful to know the screen size than just the resolution, so I could change the GUI accordingly, knowing how big a button has to be for the user to be able to press it. Will there be anywhere I can find that information? My only guess so far is os_get_info, but there's no information anywhere on what information that function actually gives.
 

RangerX

Member
When designing to properly scale my game to any device - whether a mobile or a large tablet - it would be more helpful to know the screen size than just the resolution, so I could change the GUI accordingly, knowing how big a button has to be for the user to be able to press it. Will there be anywhere I can find that information? My only guess so far is os_get_info, but there's no information anywhere on what information that function actually gives.
Am not aware of this nor I think there is a function to get that info.
Thing is, you don't really need to know that. When you know the resolution of the screen, you can determine how big your buttons and stuff are in relation with said screen.
Also, you can have an option to resize your GUI or GUI elements. Many games are doing that exactly because they had your current concern here. And one last thing, testing is your friend. Most phones are roughly the same size and so does most tablets. Test it. See if your GUI elements' size is right.
 
S

snowy1996

Guest
After having some real trouble getting my game to scale correctly, I found your tutorial for pixel perfect scaling and gave it a go. I created an object and put it in my "main menu" room, the room the game first opens up into. The objects code is as follows.
Code:
create event:

application_surface_enable(false);
window_set_fullscreen(true);
global.MonitorW = display_get_width();
global.MonitorH = display_get_height();
global.Xoffset = (global.MonitorW-640)/2;
global.Yoffset=(global.MonitorH-480)/2;
if(global.MonitorW>=1600 && global.MonitorH>=900)
then
{
    surface_resize(application_surface,1600,900)
    global.Xoffset=(global.MonitorW-1600)/2;
    global.Yoffset=(global.MonitorH-900)/2;
}

post-draw event:

draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
After booting the game up I get an error :
Trying to use non-existing surface.
at gml_Object_obj_game_set_Draw_77 (line 7) - draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);

disabling the code used in the post-draw event has everything work functionally, save for some pixel distortion in rooms in which the camera can move. Obviously this isn't ideal, and I've been unable to fix the error on my own.
Code:
if surface_exists(application_surface)
{
    draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
}
else
surface_create(global.MonitorW,global.MonitorH);
I tried using this to fix the surface not being found, but its only acting the same as thought I had no code in the post-draw event at all.
 

RangerX

Member
You mixed up "application_surface_enable" function and "application_surface_draw_enable". You need to use the later. Else with the previous you deactivate the application surface completely, hence why you receive the "trying to use a non-existing surface" message. :)
 
S

snowy1996

Guest
Haha woops, fixed that. It's 95 percent working now. Looks perfect is most of my rooms. Just a little bit off in my one room with a moving camera and a smaller resolution. Not sure why exactly yet but I'll keep hunting down the problem. any thoughts of your own?
The room in question is using a camera and viewport with widths of 640 and heights of 480. The pixel distortion itself is very minor, only noticeable in things like my characters eye's. Linked here :
https://imgur.com/a/DdS0i
Ignore the White, that's just poor editing.
 

RangerX

Member
All your views and port should have the same dimension in all rooms.
If you don't do that, you'll get resolution problems. And i've never ever seen a game needing multiple resolution depending where you are in the game. I game since 1983 and I probably played millions of games.
I guess you're trying to something the wrong way!
 
I

icuurd12b42

Guest
Make sure vsync is enabled if you have a nvidia card (if you get the black screen)

[edit]
Weird Forum glitch, this is in reply to a post I dont even see anymore... Forum went from 1 page to 4
 
S

snowy1996

Guest
Well after changing my resolution to be the same in every room I'm still having some very minor distortion, now pretty much only noticeable if the character is standing in the right places. For now, that's good enough for me. I'll keep experimenting in the future, and thanks a ton for getting me this far!
 

RangerX

Member
You're not supposed to have distortion. Can you give me this info please:
- what's your view size?
- what's your port size?
- what's the resolution of the monitor you're displaying your game in?
 
I

icuurd12b42

Guest
Well after changing my resolution to be the same in every room I'm still having some very minor distortion, now pretty much only noticeable if the character is standing in the right places. For now, that's good enough for me. I'll keep experimenting in the future, and thanks a ton for getting me this far!
Part 2 of the problem it not having the view position exactly on a round value.. you will get a similar sort of uneven distribution of lines thickness as you did with improper scaling because the math that progressively figures it out many lines to draw from the source data. it may be bias to choose one source line to make 2 lines on the display for a few lines and use choose one line to make 3 lines for the rest of the image. the fix is to round the view x and y so it's never fractional

Part 3 of the problem are the sprites themselves, especially moving sprite that don't fall exactly on a pixel. the distortion will be for that sprite only depending on it's position and how large the sprite is... similar fix, you round the x,y value (in the draw event, using draw_sprite_ext(..., round(x), round(y),...)
 
S

snowy1996

Guest
My camera and viewport as listed in my room properties, in each of my rooms, have the same widths and heights. Both my Camera Properties and my Viewport Properties have their width set as 512 and heir height set as 288.
My monitors resolution is set as 1600 x 900.
 

RangerX

Member
So right now if you're upscaling your game from 512x288 to 1600x900, you're scaling it up by a factor or 3,125. This is why you get distortion. You have to scale it by 3. Not 3,125. As soon as you are NOT scaling the game by an integer value, you get distortion. Your game scaled by 3 times is 1536x864.
Your code should look like this:


if(global.MonitorW>=1536 && global.MonitorH>=864)
then
{
surface_resize(application_surface,1536,864)
global.Xoffset=(global.MonitorW-1536)/2;
global.Yoffset=(global.MonitorH-864)/2;
}


Do you understand how to do it now?
Your next possible size is: 2048x1152 ---> which doesn't fit in 1920x1080 and that is the most common resolution used by gamer. Your base resolution choice is poor.
You should use 480x270 instead of 512x288 if you don't want to change your game too much.
 
S

snowy1996

Guest
OK, after one more change to the resolution it looks perfect now. I guess the one thing I'm confused on is what I was trying to scale up to. I thought my monitor's maximum was 1600x900, why can we scale to a resolution past that?
 

RangerX

Member
The idea is that you want your game to occupy the most space as possible on screen while being scaled only by an integer, therefore keeping pixel perfect, regardless the monitor size.
The size of the monitor doesn't have much to do with anything. However, you will want a base resolution that looks good into most monitor (taking the whole screen) and that resolution you want your game's resolution to be a perfect divider of is 1920x1080. (full hd).

Right now, your game is pixel perfect at those sizes:

512x288 (no scale)
1024x576 (scale x2)
1536x864 (scale x3)
2048x1152 (scale x4)
and so on...

If you notice, this doesn't correspond to any standard monitor's resolution so your game will always be letterboxed quite alot for everybody who's playing your game. Hence why I told you that your base resolution was not a good choice.
Most common resolution in the world right now is 1360x768
Your game will appear in 1024x576 if you want it pixel perfect. This is alot of black space.

Most commonly used resolution for gamers and soon to surpass 1360x768 in the overall scheme of things is 1920x1080.
Your game will appear in 1536x864 if you want it pixel perfect. This is again alot of black space.
 
S

snowy1996

Guest
OK, thanks for clearing that up for me, that was a big reason why I was having so much trouble getting everything to look perfect. I've changed the resolution to what you recommended. Again, thanks a ton for getting me here.
 
P

Petr Skornok

Guest
@RangerX great tutorial, thank you. I am following the pixel perfect method - my virtual resolution is 360p (640x360). On Macbook Pro 2017 (aspect ratio 16:10) calling
display_get_width() and display_get_height() returns the resolution 1680x1050 and thus the base resolution is scaled just twice leaving a lot of black space on X and Y axis. Would it be sensible to scale the game three times and "cut off" a parts of the screen on the X and Y axis instead of the black space? Is there any other solution to the black space?
 
Last edited by a moderator:

RangerX

Member
@RangerX great tutorial, thank you. I am following the pixel perfect method - my virtual resolution is 360p (640x360). On Macbook Pro 2017 (aspect ratio 16:10) calling
display_get_width() and display_get_height() returns the resolution 1680x1050 and thus the base resolution is scaled just twice leaving a lot of black space on X and Y axis. Would it be sensible to scale the game three times and "cut off" a parts of the screen on the X and Y axis instead of the black space? Is there any other solution to the black space?
In my opinion you have 2 solutions for this problem.

1- You choose a better base resolution.
This is much overlooked by amateurs while its extremely important. You need to ask yourself this when you start a project: What is my target audience and what is the most common resolutions this audience is using?
Per example, on PC, 80% of people that will play your game will be in 1920x1080. Guess what, this means your game better be optimised for that resolution. I suggest you search the internet for this. What are the most used resolutions for Macbooks? Is there other machines your game will play on? You need to determine who is your audience and adapt to it.

2- You use a mix of techniques.
Take like the 5 most used resolutions that your audience will have and then try to accomodate your game to them. Taking your current situation as an example. When the game starts and you detect that the person is playing in 1680x1050, you could set your game view to 560x350. Depending your game design, the difference in playfied viewed at the same time by the player might not be a problem. Another thing your could do is, as you suggested, simply overscan your game. With your current example it might not be the best thing because you lose 300-ish pixels horizontally and it might be too much. In any case, using a mix of techniques can be a real pain in the ass if you're not careful.
 
P

Petr Skornok

Guest
@RangerX thanks for the suggestions. I see your point with the research, we've spent quite some time on this topic before starting the project. The game will be released for PC & Mac which leaves us with too many different resolutions. We have opted for 360p because it has native support for 720p, 1080p, 1440p and with 1366x768 there is just a small difference. Also this table of the most used resolutions on Steam was very helpful. I don't see any advantage in using 270p like Hyper Light Drifter - no native support for 720p or 1440p.



The problem is that Macbook Pro 15" has aspect ratio 16:10 and the default resolution should be 2880x1800. According to the calculations we have done beforehand this would fit 360p perfectly in height but leaves some space in width. Anyway GM:S 2 detects the resolution as 1650x1080 (I suppose that this is caused by the density of pixels in Retina display) and thus the big black bars.

You are right that the overscan might be quite a pain with an unpredictable field of view while solving the platformer puzzles.

Do you think that settings the game view (if we detect macOS and this resolution) to 560x350 would be the most professional attitude towards this problem? We want to spend the extra time and effort to get the best out of it.
 

RangerX

Member
I think your PC version should scale a certain way (adapted to 1920x1080 per example) and Mac version adapted to MAC reality. That's the first thing.
Second thing, to answer your question, yes I would try a view of 560x350 in that specific Mac case. The field of view might not ruin your game.
 
C

Crysillion

Guest
I've went through this topic and saw a lot of people complaining about getting a black screen when using the first method. I am also getting this issue, so looked at the replies and solutions and it doesn't quite seem like any of them apply to me. I'm thinking I must've missed something, somewhere, somehow.

So, I made an init room, and inside I put this object:

CREATE EVENT:

Code:
application_surface_draw_enable(false);
window_set_fullscreen(false);

global.monitor_w=display_get_width();
global.monitor_h=display_get_height();

global.Xoffset=(global.monitor_w-480)/2;
global.Yoffset=(global.monitor_h-360)/2;

if(global.monitor_w>=960 && global.monitor_h>=720)
{
    surface_resize(application_surface,960,720)
    global.Xoffset=(global.monitor_w-960)/2;
    global.Yoffset=(global.monitor_h-720)/2;
}
PRE-DRAW:

Code:
draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);

room_goto_next();
What's going on here is that the object right now is not persistent. I tried setting it to persistent, removing the room_goto_next(); portion and simply passed that on to a separate object for that. It resulted in a black screen. The current idea is to have room_goto_next(); in the code (as shown), and then have a persistent object in the room the player is sent to.

This is that object:

PRE-DRAW:

Code:
draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
This object IS persistent. And, well, that's it. The result is the same none-the-less. A black screen.

I cannot seem to avoid having a black screen. Any ideas as to what could be causing it?
 
I

icuurd12b42

Guest
>I cannot seem to avoid having a black screen. Any ideas as to what could be causing it?
How can you have a black screen when you are in window mode?

you are supposed to draw with draw_surface_stretched using the values from application_get_position

I never use the predraw myself. there is nothing on the app surface to draw in the predraw man... as the name implies this event happens BEFORE the draw event... and the draw event is where your game is drawn (to the app surface)... conundrum.

BTW, guys, in general you should have a boot room that does nothing with the graphics for a few steps (10 minimum) before going to the next room. you cant mess with the graphics in the create event or room start in the first room. things aren't quite ready yet
 

RangerX

Member
I also never use predraw.
I am suggesting in the tutorial how you can organise your game Crysillion, why don't you try it?
 
C

Crysillion

Guest
@icuurd12b42 Now I'm lost because the first method didn't mention anything about draw_surface_stretched or application_get_position... I went ahead and tried using draw_surface_stretched instead of draw_surface_ext and the result is the same.

As for Pre-Draw, that was really just me messing around with it and trying to understand what it was really requiring. I initially tried Draw and Post-Draw.

@RangerX I must've missed this because I actually don't see that. I see you saying where things should be in the draw and where things should be in the create, and I followed that. I'm not exactly sure what you're suggesting.

______

I read through the first method again, this time a bit more carefully, and created an initialization object in the boot room.

I don't want the game to be in fullscreen, but for sake of testing and cohesiveness, I'll leave it as true.

CREATE:

Code:
application_surface_draw_enable(false);

window_set_fullscreen(true);

global.MonitorW=display_get_width();
global.MonitorH=display_get_height();

global.Xoffset=(global.MonitorW-480)/2;
global.Yoffset=(global.MonitorH-360)/2;

if(global.MonitorW>=960 && global.MonitorH>=720)
then
{
    surface_resize(application_surface,960,720)
    global.Xoffset=(global.MonitorW-960)/2;
    global.Yoffset=(global.MonitorH-720)/2;
}
STEP:

Code:
room_goto_next();
That's the end of the initializing object. It's not persistent.

In the room the player gets sent to (the actual level), there is a persistent object:

DRAW:

Code:
draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
Still a black screen. Is it possible that it's because I'm using Game Maker Studio 2?
 
Last edited by a moderator:
P

PlayThatFunkyMusic

Guest
Hi guys I just joined and starting up with game making on GMS v1.4. Lots of fun! But ran into the same problem here as Crysillion and others when trying to scale. Any ideas on what's wrong? I get a black screen, nothing happens.

Room creation:
Code:
application_surface_draw_enable(false);
window_set_fullscreen(true);

global.MonitorW=display_get_width();
global.MonitorH=display_get_height();

if (global.MonitorW>=2560 && global.MonitorH>=1440)
   {
   surface_resize(application_surface,2560,1440)
   global.Xoffset=(global.MonitorW-2560)/2;
   global.Yoffset=(global.MonitorH-1440)/2;
   }
obj_screendraw postdraw event code:
Code:
if (surface_exists(application_surface))
   {
    draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
    }
    else
    {
    surface_create(global.MonitorW,global.MonitorH);
    }
Object is set to visible, room size and View0 currently set at 1280x720 for testing purposes, vew is visible when room starts. I also tried putting the room creation code into the object's create code. Hell I even set nvidia settings to enable vSync as someone else posted before.

Edit: I also tested by commenting out the scaling code, and just draw the surface with the monitor size, I tried 1 x 1 as Ranger X suggested... It's always a black screen.

I am a broken man trying to get this right.
 
I

icuurd12b42

Guest
first off, make sure you have vsync enabled if you are getting a black screen (in full screen) because that's a nvidia + game maker bug


second, your code and the one posted before (Crysillion's) will resize the application surface every step. please refrain from resizing the app surface if it's already the size you need.

finally I already explained how to draw at the right size and offset
 
P

PlayThatFunkyMusic

Guest
Thanks @icuurd12b42 .. yeah I think it has something to do with nvidia or Win10 creators update.

When I alt+enter back into window mode it draws but in fullscreen it's black.

Googling around, I went to global game settings > windows > graphics and turn Alternate Syncronization Method to ON and surprise, it works. What a headache, but goot that it's solved now hehe.

@Crysillion have you tried this? global game settings > windows > graphics .. activate Alternate Syncronization Method

Maybe OP can add this to their post for future any game makers who run into the same problem.
 
E

elsi11

Guest
I'm having trouble deciding on what base resolution I should pick for my game. I want it to look good, but I also want it to be a bit modern. The most popular resolution is 1920. But I also want to support 4:3 resolutions like old monitors have.

What base resolution should I pick? Is Downsizing a thing?

For the 4:3 problem I thought maybe scaling the window vertically, and basically have an infinite repeating padding picture on the sides. Or if possible a giant picture, so the empty space in 16:9 feels like a part of the game.

I also once caculated the margins of 4:3 being scaled vertically, and 16:9 being scaled horizontally, and saw how much of the picture I loose on top and the sides. the middle is the area that will always be visible. Is this a viable way to do things?

What should I do? Which native resolution should I pick? My goal is 1920 16:9, with consideration for 1024 4:3 for the poorer people

Tnx!
 

RangerX

Member
In your case I would ask myself this. Is my game definetely playable and feels like the same experience if I play it both in 16:9 or 4:3
I mean, because nothing prevents your from having your game support both screen ratio afterall. But no matter what you think, a very very very large majority of players ever playing your game will play it in 16:9 so the question of "is it worth the effort to design a 4:3 mode" still stands.
 
M

Mobie

Guest
This tutorial is for Game Maker Studio 1.4 and up.
While made for the Windows target, the logic applies in general for all platforms


GM Version:
1.4, but should apply to all version
Target Platform: Window, but generally applicable to other platforms
Links: see links below for example

How to properly scale your 2D game to any screen size.



Understanding pixels

:)
Does this procedure work the same in GMS2? Thanks!
 

RangerX

Member
Does this procedure work the same in GMS2? Thanks!
Yes it should. I mean, the logic should be the same. You will have to adapt it though. Per example, view variables changed in GMS2 and they are a called a cam anyways.
Read also important other tutorials (and some already adapted to GMS2) in the link at the end for videos from Pixelpope.
 
D

Drago Supremo

Guest
This tutorial is for Game Maker Studio 1.4 and up.
While made for the Windows target, the logic applies in general for all platforms


GM Version:
1.4, but should apply to all version
Target Platform: Window, but generally applicable to other platforms
Links: see links below for example

How to properly scale your 2D game to any screen size.



Understanding pixels and pixel based displays.

To understand how to manage scaling you need to really understand what it means to display graphics in a pixel display. Heck you need to understand what pixels are for a start. Pixels are logic. The logic that builds that image you see on all your screens. They form the image you see on screen. As an example, a screen of a resolution of 1920x1080 means there's 1920 columns of 1080 pixels each in order to display what image is thrown at the screen.

Pixels are squares. They are lit up or they aren't. Each square is of one color. You clearly understand that when you draw very low res graphic, like pixel art in general. A sprite of 24x24 means its composed of 24 rows of pixels and 24 columns. It's also like my friend Bob. Yellow Bob. Don't be afraid of him he's actually quite nice while being ugly looking. He is composed of 24x24 pixels as you can see:







Why is there graphical deformation when scaling up?


The deformation occurs because you're asking the engine to resize the graphics by a fraction value instead of an integer. If you resize by integer, everything is intact. Take the example of Yellow Bob 24x24. If I upscale him by 2,he becomes 48x48 pixels. That is easy for the engine to do, it simply doubles every row and columns of pixels. A black square was one pixel of size is now 2x2. No graphical deformation occurs, everything is fine:






Now what will the engine do if I ask to resize my graphic by 1.5 instead of 2? How can you grow a pixel of "half a pixel"? Well, you can't! The engine will have a choice to make. An image like Yellow Bob that is 24x24, scaled up by 1.5 ends up 36x36. To achieve that, the engine will simply double 1 row out of two! Same for the columns (24+12=36). Only twelve columns and rows alternatively will get doubled so the image pass from 24x24 to 36x36. The result is obviously a distortion of the original:




See? That's why you want to resize your game only by an integer value (x2, x3, x4, etc). This way, your pixel art is NEVER messed up.





Different approaches to scaling depending your game's style and needs.



1) Games displayed "pixel perfect" at all time. (good for 2D games)

GMS by default is drawing your game on a surface called the application surface. GMS is doing a great deal for you by automatically setting the size of the application surface and the window the same as your view size. It centers it on screen and draws it every step for you too. This is very convenient that's for sure, but there's no options for GMS to always display your game "pixel perfect". Maybe this is odd for an engine primarily dedicated to 2D games production but at least they give you all the necessary functions in order to scale your game manually, all by yourself.

In order to be in complete control of how your game is displayed you will need to turn off GMS drawing/resizing/displaying control over the application surface and then you will resize it, center it and draw it yourself every step. I will walk you through how it's done along with some structure suggestions.

First of all, your game should have a setting room. A room for setting all your stuff when the game start. Not that its mandatory to make this whole thing work but it's convenient. With this first room you can set your view size, port size, initiate all you need to initiate an set the application surface for your game to be "pixel perfect". After that you make the real game start (splash screen, title screen, etc). So here's how we set this game to display 1:1 on any screen of this world:


Step 1:
Disable the automatic drawing of the application surface. For this you use the "application surface drawn enable" function.
https://docs.yoyogames.com/source/d...surfaces/application_surface_draw_enable.html

Step 2:
Set the game to be displayed fullscreen with "window set fullscreen" function.
https://docs.yoyogames.com/source/dadiospice/002_reference/windows and views/the game window/window_set_fullscreen.html

Step 3:
You will need to remember the monitor size in order to determine what size your game will get and to center it on screen. You can simply catch those values in variables:

global.MonitorW=display_get_width();
global.MonitorH=display_get_height();
https://docs.yoyogames.com/source/dadiospice/002_reference/windows and views/index.html

Here's how to calculate the necessary offsets you will need in order to draw the application surface centered on screen. In this example, a game with a native resolution of 800x450 (no scaling):

global.Xoffset=(global.MonitorW-800)/2;
global.Yoffset=(global.MonitorH-450)/2;

Step 4:
Determining the size your game can take in the screen and adjusting the application surface size and centering accordingly. If we follow the example of a 800x450 game, you know can already know what are the desired sizes your game can display at. (x2 - 1600x900, x3 - 2400x1350, x4 - 3200x1800, etc).

By going through some simple conditions, you will determine what size it can can take. Here's an example to know if you can scale your 800x450 game by 2:

if(global.MonitorW>=1600 && global.MonitorH>=900)
then
{
surface_resize(application_surface,1600,900)
global.Xoffset=(global.MonitorW-1600)/2;
global.Yoffset=(global.MonitorH-900)/2;
}
https://docs.yoyogames.com/source/dadiospice/002_reference/surfaces/surface_resize.html

Step 5:
Now that the application surface is the right size and that we are done with all the necessary calculations, there's one more thing to do. You have to make an object draw your application surface on screen every step. Normally I would suggest that all your objects in the game that can draw something would do it in a "pre-draw" or normal "draw" event. This way you are sure everybody is done drawing when you display the application surface in a post-draw event. Here's an example of how the code could look:

draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
https://docs.yoyogames.com/source/dadiospice/002_reference/drawing/drawing surfaces/draw_surface_ext.html




2) Games displayed scaled but always respecting the screen ratio. (good for 3D games or vector art)

No need to code anything, GMS can do this for you:





3) Games with their displayed playfield changing size. (good for some very specific cases)

With this method you would actually set the view and port size of your room according the monitor's size. It's very easy to pull off and will be useful mostly in games like SimCity or other strategy games where the gameplay is not broken due to the fact a player can see larger of a playfield than another. It's rare you see this method used in professional games though because there are some drawbacks to understand before using it:

- Different players having different view sizes depending their monitor can advantage or disadvantage them in multiplayer.

- It can also make a game harder than planned or easier than planned.

- It can influence a lot of other design aspects of the game like hiding secrets, controlling what the player sees in order to give an impression or a feeling.

- You game will be harder to balance in general and to debug.




4) Games that use the overscan method.

Similarly to the first method (pixel perfect), someone who wouldn't want to ever see their game appearing letteboxed on screen could decide to resize the application surface bigger than the game window (still at an integer size) in order to hide all the letterboxing. This is rarely used in pro games here again because it's hard to control what the player see and does not see on screen depending his/her monitor's resolution. This leads to the same kind of drawbacks as the third method described in this tutorial.




Other very useful tutorials:

http://www.yoyogames.com/blog/65 (Scaling for devices part 1)
http://www.yoyogames.com/blog/66 (Scaling for devices part 2)


Alternate scaling method entirely
(and aspect ratio tutorials + other excellent tutorials by PixelPope)
https://forum.yoyogames.com/index.p...-aspect-ratio-management-for-game-maker.7106/


:)
Does this give any trouble checking if the mouse cursor is on an instance? With the first method it doesn't give the right coordinates.
 

RangerX

Member
Its having nothing to do with it. Depends how you handle your mouse thing.
It doesn't prevents you from doing anything really.
 

Flaick

Member
Hi RangeX i've used your pixel perfect solution and it works fine. But what about GUI? When i use my custom surface the GUI remain the same and i cannot center it.
 

RangerX

Member
The GUI layer is a layer completely independant from the application surface displayed on top of application surface.
GameMaker Studio doesn't handle the GUI automatically (so you have to take care of all the resizing and stuff).
What's important to understand is that the GUI layer's coordinates are your screen. Therefore x0,y0 is top left of your screen ---- given your layer is sized properly.
Long story short, always resize your GUI layer a the same resolution as your monitor. And if you want it the same size as the game itself, resize it the same size as the application surface and offset it on screen so it appear right on top of the application surface. Normally you should be able to this all with one function: display_set_gui_maximise() (at least in GMS1)

https://docs.yoyogames.com/source/d...ndows and views/display_set_gui_maximise.html

:)
 
H

HolyLucy

Guest
i'm trying to add this to my game, but i'm using a dynamic light system.. and the shadows bugs when i draw this
Code:
draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
 

RangerX

Member
i'm trying to add this to my game, but i'm using a dynamic light system.. and the shadows bugs when i draw this
Code:
draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
Actually, that line of code only draws the application surface to screen. Nothing else. So if you have graphical problems, they happen before that.
 
H

HolyLucy

Guest
Actually, that line of code only draws the application surface to screen. Nothing else. So if you have graphical problems, they happen before that.
i'll try another light system script, i'm a novice and idk how scripts work exactly. ty
 
I am developing a game for android devices and want to choose one standard resolution of 1920x1080. Now the problem is that when it runs on devices with lower resolution displays like 1280x720, 960x640 etc. it will look jagged and interpolation do nothing much to make it better. I even tried creating surface at original 1920x1080 resolution then drawing it scaled down but still jagged since it use the same scaling down script supported by gm. Is there any way to get crisp picture on lower resolution displays without using any scaling shader (Which are probably not even supported on android)?
 
Top