How to properly scale your game!

W

Wraithious

Guest
the difference between me and you is that my game is for android
Same exact thing here, ive read those blogs 50 times, tried the 'pixel perfect' aproach, nothing works, either the game is scaled correctly and the objects aren't scaled correctly, or the objects are scaled correctly and the game is not, and in both cases when you save an image to reload and use it the image is 50x bigger than it was when i saved it, heres a pic of what the pixel perfect example did to my game
Screenshot_20160914-202220.png
Notice the white bars? They are virtual buttons that are supposed to line up with the arrow buttons and enter and end buttons, and the application background is tiny and not even centered, i have no idea what to do, i followed that tutorial exactly as well as trying all of the ideas on the 2 blogs

code for room0:
application_surface_draw_enable(false);
window_set_fullscreen(true);
dw=display_get_width();
dh=display_get_height();
if(dw<=512 && dh<=384)
{surface_resize(application_surface,512,384);
global.xo=(dw-512)/2;
global.yo=(dh-384)/2;
}
if(dw>512 && dh>384 && dw<=1024 && dh<=768)
{surface_resize(application_surface,1024,768);
global.xo=(dw-1024)/2;
global.yo=(dh-768)/2;
}
if(dw>1024 && dh>768 && dw<=2048 && dh<=1536)
{surface_resize(application_surface,2048,1536);
global.xo=(dw-2048)/2;
global.yo=(dh-1536)/2;
}
if(dw>2048 && dh>1536 && dw<=3072 && dh<=2304)
{surface_resize(application_surface,3072,2304);
global.xo=(dw-3072)/2;
global.yo=(dh-2304)/2;
}
if(dw>3072 && dh>2304 && dw<=4096 && dh<=3072)
{surface_resize(application_surface,4096,3072);
global.xo=(dw-4096)/2;
global.yo=(dh-3072)/2;
}
if(dw>4096 && dh>3072 && dw<=5120 && dh<=3840)
{surface_resize(application_surface,5120,3840);
global.xo=(dw-5120)/2;
global.yo=(dh-3840)/2;
}
if(dw>5120 && dh>3840 && dw<=6144 && dh<=4608)
{surface_resize(application_surface,6144,4608);
global.xo=(dw-6144)/2;
global.yo=(dh-4608)/2;
}
if(dw>5120 && dh>3840 && dw<=7168 && dh<=5376)
{surface_resize(application_surface,7168,5376);
global.xo=(dw-7168)/2;
global.yo=(dh-5376)/2;
}
code for post draw event in the game room (room1)
Code:
draw_surface_ext(application_surface,global.xo,global.yo,1,1,0,-1,1);
and the code for the virtual buttons in the create event of the drawing object (same object that uses the buttons)
Code:
global.vikey1=virtual_key_add(x,y,32,32,vk_up);
global.vikey2=virtual_key_add(x+32,y,32,32,vk_down);
global.vikey3=virtual_key_add(x+160,y,32,32,vk_enter);
global.vikey4=virtual_key_add(x+192,y,32,32,vk_end);
virtual_key_show(global.vikey1);
virtual_key_show(global.vikey2);
virtual_key_show(global.vikey3);
virtual_key_show(global.vikey4);
 
Last edited by a moderator:
J

JDSTIGER

Guest
Thanks for the guide. Which would work best for flat 2D vectored games?
 

RangerX

Member
Same exact thing here, ive read those blogs 50 times, tried the 'pixel perfect' aproach, nothing works, either the game is scaled correctly and the objects aren't scaled correctly, or the objects are scaled correctly and the game is not, and in both cases when you save an image to reload and use it the image is 50x bigger than it was when i saved it, heres a pic of what the pixel perfect example did to my game
View attachment 2794
You need to scale up the application only if there's space for it.
+ Your multiplications were wrong.
There might be further problems but there's at least how it should be for resizing your application surface:

code for room0:
application_surface_draw_enable(false);
window_set_fullscreen(true);
dw=display_get_width();
dh=display_get_height();
surface_resize(application_surface,512,384);
global.xo=(dw-512)/2;
global.yo=(dh-384)/2;

if(dw>=1024 && dh>=768) // x2 scale
{surface_resize(application_surface,1024,768);
global.xo=(dw-1024)/2;
global.yo=(dh-768)/2;
}

if(dw>=1536 && dh>=1152) // x3 scale
{surface_resize(application_surface,1536,1152);
global.xo=(dw-1536)/2;
global.yo=(dh-1152)/2;
}

if(dw>=2048 && dh>=1536) // x4 scale
{surface_resize(application_surface,2048,1536);
global.xo=(dw-2048)/2;
global.yo=(dh-1536)/2;
}

if(dw>=2560 && dh>=1920) // x5 scale
{surface_resize(application_surface,2560,1920);
global.xo=(dw-2560)/2;
global.yo=(dh-1920)/2;
}

if(dw>=3072 && dh>=2304) // x6 scale
{surface_resize(application_surface,3072,2304);
global.xo=(dw-3072)/2;
global.yo=(dh-2304)/2;
}
 
W

Wraithious

Guest
You need to scale up the application only if there's space for it.
+ Your multiplications were wrong.
My game is 1024 x 768 so my multiplications were correct. I used 512 x 480 to downscale if the screen was smaller

so after that i changed my room size to 512 x 480 to test your code and it didn't work, altho the game is centered the virtual keys are still wayyyyyyy off, and the game is still smaller than the screen, a landscape based game should at least be as tall as the screen. So i tried at least 10 different ways to set the virtual keys positions, and when i finnaly got them to line up i tried the game on a different sized phone and it was totally completely different, just to give you an idea of what i mean heres's 6 of the things i tried, with the last one working ok on a galaxy 6 but completely messed up on a galaxy 3 with a smaller screen.
room0 creation code
application_surface_draw_enable(false);
window_set_fullscreen(true);
dw=display_get_width();
dh=display_get_height();
surface_resize(application_surface,512,384);
display_set_gui_size(512,384);
global.xo=(dw-512)/2;
global.yo=(dh-384)/2;
global.ap=application_get_position();
global.fap[0]=global.ap[0];
global.fap[1]=global.ap[1];
global.fap[2]=global.ap[2];
global.fap[3]=global.ap[3];
global.so=0.5;
if(dw>=1024 && dh>=768) // x2 scale
{surface_resize(application_surface,1024,768);
display_set_gui_size(1024,768);
global.xo=(dw-1024)/2;
global.yo=(dh-768)/2;
global.ap=application_get_position();
global.fap[0]=global.ap[0];
global.fap[1]=global.ap[1];
global.fap[2]=global.ap[2];
global.fap[3]=global.ap[3];
global.so=1;
}
if(dw>=1536 && dh>=1152) // x3 scale
{surface_resize(application_surface,1536,1152);
display_set_gui_size(1536,1152);
global.xo=(dw-1536)/2;
global.yo=(dh-1152)/2;
global.ap=application_get_position();
global.fap[0]=global.ap[0];
global.fap[1]=global.ap[1];
global.fap[2]=global.ap[2];
global.fap[3]=global.ap[3];
global.so=2;
}
if(dw>=2048 && dh>=1536) // x4 scale
{surface_resize(application_surface,2048,1536);
display_set_gui_size(2048,1536);
global.xo=(dw-2048)/2;
global.yo=(dh-1536)/2;
global.ap=application_get_position();
global.fap[0]=global.ap[0];
global.fap[1]=global.ap[1];
global.fap[2]=global.ap[2];
global.fap[3]=global.ap[3];
global.so=3;
}
if(dw>=2560 && dh>=1920) // x5 scale
{surface_resize(application_surface,2560,1920);
display_set_gui_size(2560,1920);
global.xo=(dw-2560)/2;
global.yo=(dh-1920)/2;
global.ap=application_get_position();
global.fap[0]=global.ap[0];
global.fap[1]=global.ap[1];
global.fap[2]=global.ap[2];
global.fap[3]=global.ap[3];
global.so=4;
}
if(dw>=3072 && dh>=2304) // x6 scale
{surface_resize(application_surface,3072,2304);
display_set_gui_size(3072,2304);
global.xo=(dw-3072)/2;
global.yo=(dh-2304)/2;
global.ap=application_get_position();
global.fap[0]=global.ap[0];
global.fap[1]=global.ap[1];
global.fap[2]=global.ap[2];
global.fap[3]=global.ap[3];
global.so=5;
}
create event:
global.vikey1=virtual_key_add(x+(global.xo/3.25),y+(global.yo/1.25),32*(global.so*1.25),32*(global.so*1.25),vk_up); //works on one size screen ONLY
global.vikey2=virtual_key_add(x+(32*2.5)+(global.xo/3.25),y+(global.yo/1.25),32*(global.so*1.25),32*(global.so*1.25),vk_down);
global.vikey3=virtual_key_add(x+(190*2.5)+(global.xo/3.25),y+(global.yo/1.25),32*(global.so*1.25),32*(global.so*1.25),vk_enter);
global.vikey4=virtual_key_add(x+(224*2.5)+(global.xo/3.25),y+(global.yo/1.25),32*(global.so*1.25),32*(global.so*1.25),vk_end);
virtual_key_show(global.vikey1);
virtual_key_show(global.vikey2);
virtual_key_show(global.vikey3);
virtual_key_show(global.vikey4);
/*
global.vikey1=virtual_key_add(global.xo,global.yo,32*global.so,32*global.so,vk_up); //draws keys to low by 1/3 and too close together and too far right
global.vikey2=virtual_key_add(global.xo+32,global.yo,32*global.so,32*global.so,vk_down); //and no difference using window_set_fullscreen(false or true);
global.vikey3=virtual_key_add(global.xo+190,global.yo,32*global.so,32*global.so,vk_enter);
global.vikey4=virtual_key_add(global.xo+224,global.yo,32*global.so,32*global.so,vk_end);

global.vikey1=virtual_key_add(global.fap[0],global.fap[1],32*global.so,32*global.so,vk_up); //draws keys at top of display and too close together
global.vikey2=virtual_key_add(global.fap[0]+32,global.fap[1],32*global.so,32*global.so,vk_down); //and no difference using window_set_fullscreen(false or true);
global.vikey3=virtual_key_add(global.fap[0]+190,global.fap[1],32*global.so,32*global.so,vk_enter);
global.vikey4=virtual_key_add(global.fap[0]+224,global.fap[1],32*global.so,32*global.so,vk_end);

global.vikey1=virtual_key_add(x,y,32*global.so,32*global.so,vk_up); //draws keys at top of display and too close together and too far left
global.vikey2=virtual_key_add(x+32,y,32*global.so,32*global.so,vk_down); //and no difference using window_set_fullscreen(false or true);
global.vikey3=virtual_key_add(x+190,y,32*global.so,32*global.so,vk_enter);
global.vikey4=virtual_key_add(x+224,y,32*global.so,32*global.so,vk_end);

global.vikey1=virtual_key_add(x-global.xo,y-global.yo,32*global.so,32*global.so,vk_up); //gone. not even visible on the screen
global.vikey2=virtual_key_add(x+32-global.xo,y-global.yo,32*global.so,32*global.so,vk_down);
global.vikey3=virtual_key_add(x+190-global.xo,y-global.yo,32*global.so,32*global.so,vk_enter);
global.vikey4=virtual_key_add(x+224-global.xo,y-global.yo,32*global.so,32*global.so,vk_end);

global.vikey1=virtual_key_add(x-global.xo,y+global.yo,32*global.so,32*global.so,vk_up); //wayyy to far left but y axis is alligned correctly
global.vikey2=virtual_key_add(x+32-global.xo,y+global.yo,32*global.so,32*global.so,vk_down);
global.vikey3=virtual_key_add(x+190-global.xo,y+global.yo,32*global.so,32*global.so,vk_enter);
global.vikey4=virtual_key_add(x+224-global.xo,y+global.yo,32*global.so,32*global.so,vk_end);
*/
draw event
Code:
if global.palrgb=1 draw_sprite(shadepick,0,x,y);   //this draws exactly where it's supposed to, any screen,
if global.palrgb=2 draw_sprite(shadepick,1,x,y);   //Why doesn't the virtual keys???????????????????????????
if global.palrgb=3 draw_sprite(shadepick,2,x,y);
if global.palrgb=4 draw_sprite(shadepick,3,x,y);
if global.palrgb=5 draw_sprite(shadepick,4,x,y);
if global.palrgb=6 draw_sprite(shadepick,5,x,y);
Post draw event:
Code:
draw_surface_ext(application_surface,global.xo,global.yo,1,1,0,-1,1);
 

RangerX

Member
"smaller than the screen" you mean there's still black bars? If that's what you mean, its probably normal. What's the resolution of the first phone you tested with?
 
W

Wraithious

Guest
Theres black bars all the way around the game, the resolution on the small phone is a lot less than the phone that i got the virtual keys to line up on, i dont know what the actual resolution is on either phone tho, i have no idea what the problem is or what im doing wrong or what im overlooking
 
W

Wraithious

Guest
Tip of the day: Use a 3D perspective camera.
is this what you mean? for now I ended up using and modifying the room creation code in the blog66 post, using the keep aspect ratio, and for saving and loading I used a surface to draw and surface save to save, then add_sprite to load and it works fine, even the virtual keys go where i wanted and the right size with minimal extra code needed, I made a demo .gmz to be used with android if anyone wants to check it out, it works in both portrait and landscape mode. to use it, use a stylus to click the buttons because I made them kinda small. The arrow buttons move the image up and down, the text box when clicked shows or hides the virtual keys, the enter button makes the original image invisible then creates a surface then draws the image exactly next to the original image then draws 2 lines- an 'x' starting exactly top left to bottom right / bottom left to top right over the space where the original image was and the new image then saves it (you can find it in GM Studio folder in phone) then loads the image to a different object and sets it's sprite image to the loaded file, the end button destroys the new image and makes the original image visible again.
Download link: https://drive.google.com/open?id=0B4uEFC9Ii8BnNXlSZzVtOUJTaWs 72kb

EDIT:
I still had a problem with the virtual buttons, but it's now fixed, I added 2 global variables then defined them in the room0 create event, they define the scale amount as compared with the game size and the output to screen size, then used those variables in creating the virtual keys. I tested this on 3 different android phones with 3 different screen sizes and 2 different api's and everything is smooth now. .gmz also updated.
 
Last edited by a moderator:

RangerX

Member
My tutorial is factoring a game you want to play fullscreen but at the end of the day, you can have a windowed game too.
Best would be to give the player the option to play fullscreen or not. A game that only let me play windowed would piss me off. I would actually stop playing no matter how good it is.
 
A

argagonky

Guest
I can't seem to get mine to work. I have a game that's natively in 640x480 and I want it to at least scale up to 1280x960.I tried putting the code in, but I keep getting a black screen.
 
A

argagonky

Guest
Create Event (in first room)
Code:
application_surface_draw_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;

surface_resize(application_surface,1280,960)
global.Xoffset=(global.MonitorW-1280)/2;
global.Yoffset=(global.MonitorH-960)/2;
PostDraw
Code:
draw_surface_ext(application_surface,global.Xoffset,global.Yoffset,1,1,0,c_white,1);
I got rid of the screen size test so it would force the screen dimensions of 1280x960.

Sorry if I missed something obvious. Not an expert at GML quite yet!

EDIT: lol the object was set to invisible. works fine now. sorry for the trouble!

by the way, The Life Ruby looks great! Is there a Twitter or something I can follow for updates on it?
 
Last edited by a moderator:

RangerX

Member
Hard to tell just like that.
- Make sure you don't clear the surface for whatever reason before drawing it
- Draw it once per step. Only one object taking care of that
- Have all the objects that needs to draw something have a draw event with "draw_self()" in it. This way you're making absolutely sure everything is drawn.
- Make double sure your drawing object is active
- You can try having global.MonitorW and global.MonitorH =1 and check if your see something.

Am curious about something too; which target are you currently using?
 

RangerX

Member
Last edited:
S

Sake_v2

Guest
OK, so I have a question. Not gonna put any screenshots or code cause I don't think its necessary, but something is bugging me out about this whole resolution thing. I've got a game going, could turn to be something really cool, and its base "resolution" is 640x480 (view size). Its a fixed resolution, no view size changing. I'm pratically advanced on GML cause I'm able to do most things by myself on the language, only this resolution thing is bugging me.

So let's say my monitor is 1024x768 size. What this method does, is it takes the 640x480 and check if multiplying it by 2 its still lower than 1024x768 or matches it, it will double the view size, no stretching, game looks good. But if its not, it will keep the size. Here is the thing: it works, game is not stretched, graphics are great, BUT, a 640x480 view size to a 1024x768, the black bars both on the sides and top/bottom are just tremendously huge, its pratically not fullscreen, even though it is. Monitor being small isn't the problem too, because if someone has, for say, a 1600x900 monitor, it wouldn't double either because 480x2=960.

I've already thought this through and I think a basic solution would be to decrease the view size so it can match more monitors or have smaller black bars. (Setting the view size to be the same as the monitor wouldn't work for my game). But is there any other way to make this work? I'm really, really guessing the only thing I could do is this, decreasing the view size to decrease the problem.

I'm just wondering this because I've played Undertale myself and watched some playthroughs on different channels, so probably different monitor sizes, and the game is pratically ALWAYS able to match the height of the monitor with no black borders on top or bottom at all, only on the sides, which would be ideal in my opinion cause black borders on 4 sides of the screen is a bad gaming experience. That's why I was wondering if there is any other ways to do this, other than making the view smaller. Thanks if anyone reads.
 
Last edited by a moderator:

RangerX

Member
My answer is really boring because it entirely depends on your game needs and what you want to achieve.
Yes it creates big borders for a 640x480 game to be displayed "pixel perfect" into a 1024x768 monitor. But does your game need to be pixel perfect? Is it a pixel art game for a start? Because if its not a pixel art game, you might as well just go with the "Keep aspect ratio" method and GMS will letterbox the game for you, no need to code anything. Other stuff you need to think through.... why 640x480? This is a 4:3 resolution and there's only 3 people left in this world with a 4:3 screen monitor. This means you deliberately create black bars for like 99% of your audience! why?

You should start by having a game resolution that is 16:9 in ratio. This is the most popular ratio in the world and it will stay that way for a long time. Almost nobody will play your game in a 1024x768 monitor anyways. The 2 most popular resolutions in the world right now are 1366x768 (16:9) and 1920x1080 ("full hd" 16:9). Amongst gamers (like if you look at Steam stats) its 1920x1080 that is the most popular resolution so you might want to your game to be optimised for scaling to that size!
Another thing you could look at is the Pixel Pope method that I am linking at the end of the tutorial (amongst other useful things). It mainly for windowed games but it might work for you. Heck you could even use the overscan method if your hud is drawn in the GUI layer that could be a strategy (game is overscanned a bit at certain sizes, HUD always fit because on Gui layer)

As for when you see a video of a game, the person can resize the video and you will never know if there was black bars. Its super easy to do and you wouldn't notice easily its been crop and resized.
 
  • Like
Reactions: bml
S

Sake_v2

Guest
Yeah, about the game in a video thing, I thought about it later and I know it would be easy to just resize it in video editing so it wouldn't have any black borders on the top/bottom. I asked a guy who made some of these videos if he resized it or not, just to be sure. But if there was black borders on 4 sides, well I'm surprised people don't care about it as much as I do, apparently, lol. But anyways, I also thought about what you said, the 16:9 thing, but that part is on me because I made a mistake. I already made most of the scenarios of the game (and it took a lot of work) so changing the view size now could lead me into some problems. The game was made and projected already on that resolution and changing it could take some work to get everything right. I imagine messing with the size of it by code could also lead me into some problems because of the different center positions of the sprites. I will do some tests now with the 16:9 ratio thing to see what I can do. (640x360 is 16:9, right? I guess its not that different and its the best solution I can use at the moment).
But still, there is still people with 4:3 or other sizes (idk) that could get a đź’©đź’©đź’©đź’©ty experience if the black bars were too big, right? Wouldn't be good to receive negative reviews because of that, and I do care. Guess I should make a... custom size... for that screen ration? I don't know. Lots of work.
 
Last edited by a moderator:

RangerX

Member
Its is lots of work and videogame development is about choice. You can please everyone, you can fix everything. And that goes for pro games too. You have to acomodate and fix what is worth it only because your product will never get finished and there will ALWAYS be someone that will complain about something. You need to work by priorities and aim to acomodate most people, not all. With The Life Ruby I had a similar problem where people playing in 1440x900 did have a ridiculously large black bars because honestly, this size didn't work well with my base size, its near 1.5 times my resolution (800x450). I don't want people to play with the game resized 1,5 times because I want it to be pixel perfect. So I went into research in order to find if there's many people using that resolution and the percentage was really low. So what I decided to do is to add "1.5" in my the "Forced Scaling" option in the game so if those 3 people playing in 1440 are annoyed by the huge black bars, they might as well play the game in 1.5 and get minimal blackbars at the cost of not being "pixel perfect". You know, tuff choices in life. lol
 
S

Sake_v2

Guest
But 1440x900 is a 16:10. Is it that much different from 16:9? Or your game isn't 16:9? I'm not very used to these sizes thing just yet. Well, it would be nice to have monitors in every aspect ratio so I could test if its looking fine for everyone. I'm afraid of publishing my game and receiving an apocalypse of complaints because the black bars are too big for a lot of people. This scaling thing is a pain in the ass. But I am very curious though, with what Toby Fox did with Undertale. My computer screen is a little 4:3 (very rumble) and his game fits my screen completely, no black bars, no stretching. I would imagine the original resolution of his game was made to fit a 4:3 then? But then again, it doesn't look like he had many problems making it pixel perfect for other ratios too. Hmm.
 

RangerX

Member
I did not play that game. He might change view size. His game might be displayed on a 3D plane and resized/corrected by a shader. He might overscan. He might combine multiple solutions or use different solutions depending the resolution, etc.
Its all about how much work you want to put in this and if its worth it. And tell you that, if there's 0,7% of your audience that will have huge black bars, how would you receive an apocalypse of complaints?? This doesn't make sense.

EDIT:
Looks like the scaling is pretty standard. That's what it looks like when you look at certain screenshots:
Here the game is clearly 4:3 and seems to fit the whole screen. Just like what you obvisouly experienced. Its seems he also scale up the game's assets because when you look at bottom button, they look more high res than the rest.



Here the game is 16:9 and its still displayed 4:3. So there's some quite huge blackbars.
Also, the graphics in that screenshot isn't even pixel perfect so he might just be scaling with "keep aspect ratio" and call it a day.

 
Last edited:
S

Sake_v2

Guest
Well, I didn't research a lot, only a very quick search but by what I found, its not like 99% of people on Steam that uses a 16:9 screen size, its the majority but there are still a lot of different sizes, isn't it? Maybe I looked it wrong. I'm quite skeptical about the fact that just having the game base resolution be a 16:9 would be a solution to 99% of people. I'm skeptical about everything but if you say so.

EDIT:
I already got that there's no making it perfect for every single person, geez. I'm just checking my options to both optimize my game development AND game.
 
Last edited by a moderator:

RangerX

Member
99% is manner of speaking there. 16:9 is the most used screen ratio by a large majority of people. Therefore I don't why I would make a 4:3, this just creates black bars for a majority of people for no good.
Most popular resolution in the world is 1366x768 and the most used resolution for gaming 1920x1080. This makes sense to optimise your game for those sizes (which are both 16:9). This doesn't mean some people cannot be using other resolutions, I never went there. I am trying to make you understand there's no magical size and you should go with "pleasing a majority of users" so you don't lose too much time. You can't and will never please everyone. Even just pleasing most people asks us of a tremendously accurate and detailed sense of priorities already.
 
S

Sake_v2

Guest
Wouldn't there be vertical letterboxing on that second screenshot?
 

RangerX

Member
Yes I think there is. The screenshot is 1366x678 and the game looks 4:3.
We can never trust screenshot perfectly either though since they can be cropped, resized, etc
 

Zuljaras

Member
Could you also add a part for the pixel perfect scaling where you set the gui to the size of the surface. I am asking of that because when I use your method of scaling then I will not be able to use my mouse functionality.
 

RangerX

Member
Scaling your game doesn't prevent you to do anything.
Its just that my tutorial does not cover the related GUI layer management. Besides, you always have the option to use it if that's easier for you.
I decided that I wasn't good enough with the GUI layer (since I don't use it for my games) to include it in the tutorial. But the tutorial does not prevent the use and correct use of the GUI layer.
 

Zuljaras

Member
Thank you everything works perfect except the mouse_x and mouse_y not finding the buttons properly since the game is rescaled.
 
R

RetroNuva10

Guest
So I'm trying to do a pixel-perfect scaling method that's different than yours (I believe). What I'm doing is,
1.) Get the Width and Height of the display.
2.) Scale the viewport scaling Width and Height at integer values incrementally until they are <= the respective Width and Height of the display.

Do you have any insight on how I could do this?
 

RangerX

Member
You can scale by the viewport but that's useless. It brings nothing on the table. You do that only if you don't use the application surface.
 
R

RetroNuva10

Guest
I might not be explaining it well. This is what I mean, with the original size and the scaled size:

upload_2017-1-25_14-50-10.png
 

Xer0botXer0

Senpai
Printing this, because I dont want to mess around with scaling tonight, I'm working on views next because my game is going to be bigger.. so I can just as well add full screen and read this in the mean while. Thanks
 

Hysler

Member
Thanks for the tutorial, I have a question.

I'm making a game in the style of an Apple II game and created my assets based on its specs. It's a super low resolution (280 x 192) and I'm using the pixel perfect solution to scale it up as much as possible. The main problem is that when scaled even at only 2X, it makes my backgrounds and sprites look like I put a blur filter over them. Is this just a case of the assets being way too low res or is there a work-around? I'm new to GM but have made some small games in the vain of the Sega Genesis using SFML over the past few years and never had a problem scaling up from 320 x 224 so I'm not sure what the problem is.

Edit: Never mind, as soon as I posted this I checked the global game settings and noticed that "Interpolate colors between pixels" was on.
 

RangerX

Member
I am wondering still....
If you scale perfectly, there's no reason for the interpolation to kick in. Are you sure you're scaling properly? (I mean, in regard of the pixel perfect method)
 

Hysler

Member
I'm pretty sure, here's my test code (Monitor Res: 1920x1080, scaling at 5X):
Code:
application_surface_draw_enable(false);

window_set_fullscreen(true);

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

surface_resize(application_surface,1400,960);
global.Xoffset = (global.MonitorW - 1400) / 2;
global.Yoffset = (global.MonitorH - 960) / 2;
I then used the 'draw_surface_ext()' in a pre-draw event on my player object.
 
Last edited:

RangerX

Member
It looks alright.
Anyhow, blur didn't comeback since you disabled the interpolation and you got no deformation in your pixel art right?
If its all good its all good ;)
 
  • Like
Reactions: 607

hijong park

Member
i decided to give up my cheap greed and go with black letters if the computer's resolution is smaller than 1920x1080.(if not, fullscreen with max scale.)
but one question, how can i make the game to return to the window mode properly when i applied pixel perfect scaling tutorial ?
when i use window_set_fullscreen(0); in disabling fullscreeen event it just shows black screen... i'm not so familiar with post Draw event yet.
 

RangerX

Member
You see to set everything back how you want it in the window.
- You need to resize the app surface
- Remove the X and Y offset you did use for centering your game when fullscreen
- Resize the window itself (window_set_size)

Remember that for the pixel perfect method, the automatic drawing on screen of the application surface is not done by GMS anymore but you. This means you need to handle every single change you want to occur.
 
I am actually having trouble with scaling and resolution myself. I would like to have my game screen size down to 848x480 for HTML5 to be put on a website and then have Windows export screen size be the highest adapted resolution with the option of turning on/off full screen. I don't have a clue on how to do both.

I am new to GMS2 so I don't know the right solutions. My game's screen doesn't move at all, it is basically a click button to go to the next room kind of game.
 
Z

Zandooma

Guest
So with GMS2 when I apply your technique for getting pixel perfect rendering sprites that I have placed in an asset layer do not draw. Do you know of a way to fix this?
 

RangerX

Member
I never used GMS2 yet. The logic still apply of course but you might need to adapt he execution.
If you follow my link (in the opening post) for PixelPope's tutorials, I THINK he added a video for GMS2 if I remember right. It might be worth checking.
 

Zuljaras

Member
I never used GMS2 yet. The logic still apply of course but you might need to adapt he execution.
If you follow my link (in the opening post) for PixelPope's tutorials, I THINK he added a video for GMS2 if I remember right. It might be worth checking.
I am using the pixel perfect method. I ported my game to GMS2 but I still develop it on GMS1.4 because there are some bugs in GMS2 that still need to be addressed I hope they fix them in the next update.

However I did not have to change a thing about the pixel perfect method for it to work in GMS2. It worked just perfect like in GMS1.4.
 
D

David Ruttan

Guest
Will this act as a "stretch to fit" and circumvent the fps loss from gamemaker drawing each individual pixel with it's native full screen option?
 
Top