Sure, but remember this isn't a boiler plate solution because you will have to tailor and tweak the code:

Many GM games use a setup or "initialization" room; in this room they put objects that run code necessary to tweak some settings; a less code heavy approach would be to setup a view and room size for this room and the rest of the game tends to match those settings. What I do is use an object, placed in the setup room, that runs code in its create event:

// resize game surface

surface_resize(application_surface,res.w,res.h);

// resize window

var _w=res.w*res.s;

var _h=res.h*res.s;

window_set_size(_w,_h);

// set video applied settings time

alarm[0]=1;

This code resizes the game drawing surface in order to scale the game without funky artifacts. The lines that reference res.w*res.s and res.h*res.s is just an enum that I made to contain the size of the window (width=w, height=h) which is multiplied by how much you want to scale the window (scale=s); making enums for this purpose is easy, but make sure you define the enum BEFORE this code, you can even put it right above the code that I'm currently explaining (in the create event of the object); my enum for the window size looks like this:

enum res

{

w=352,

h=224,

s=4,

}

Width (w) is the width of the window at 352 pixels (unscaled); height (h) is the height of the window at 224 pixels (unscaled); these two numbers are multiplied by the scale (s) which is four; this results in an actual window size of 1408x896. Remember, this code is placed before the code previously mentioned (or at least called before it).

window_set_size will actually set the window's new size (referencing the _w and _h variables which were used to hold the scaled window dimensions. This function won't take effect right away, which is why the next line sets an alarm in the same object; the code in the alarm event is:

window_center();

// start game

room_goto_next();

This code is simple: the window is centered on your computer screen and then the next room is loaded. Having an alarm delay after the window is resized and before the game progresses to the next room ensures that the window is setup and centered properly before the actual game starts.

Lastly, in order for the change to be usable in-game, you have to setup a view; you can either do this in the room editor or in code; I like to do it in code because it makes me feel big and powerful. I make a camera object and either leave the sprite blank or make it invisible. In the camera object's create event I setup the view:

// create view camera

var _camera=camera_create_view(0,0,res.w,res.h,0,id,-1,-1,res.w/2,res.h/2);

// setup view

view_enabled=true;

view_visible[0]=true;

// set view to camera

view_set_camera(0,_camera);

In this code, a camera is created using the enum values that I explained previously (creating a camera this way means that you will only have to change the enum values in order for the entire system to be affected) and is stored in the _camera variable. Setting view_enabled to true enables the use of views for the current room, in which the camera is present. Setting view_visible (for view "0", which is the view to which the camera is attached) will enable the camera's view. Lastly, view_set_camera attaches the camera (which is stored in the _camera variable) to the view (in this case view "0").

Remember, with this code, the view follows the camera object only, so you have to make the camera object follow the player; you can do this easily by just setting the camera object's x and y position to the player's x and y position in the step event of the camera object; if you encounter unwanted lag or choppy movement, experiment with begin step and end step in addition to the normal step event.

You can create the camera object instance in the player's create event or set the camera object to persistent and place it in the setup room (be mindful of referencing the player object before it is created; I usually just put all player referenced code in an if "player exists" type comparison to be safe).

Lastly, delete your camera with camera_destroy(view_camera[0]) when changing rooms or ending the game, otherwise it will cause a memory leak which will slow your game, due to repeated test-playing, until it eventually crashes and you have to reboot your computer.

Also, if you have weird position based drawing artifacts such as vanishing pixels on object sprites, in your scaled game you can round the drawing position in the drawing event of the object; this keeps the game from attempting to scale pixels when the object's position doesn't quite match up with the display position in a scaled room. This isn't a problem that everyone has.

Check your GM manual for explanations of all of the functions that I have written about, this will give you insight into their various parameters (especially since I didn't give a more in-depth explanation of why I threw in random -1 parameters and such). Take this process one step at a time; this seems way more difficult than it actually is.