Dev Log Entry 10: Viewport is verb now – part 2

This is a dev log about creating a game called Newtius in GameMaker Studio 2 (Indie edition). Starting with entry one might make this easier to follow.

In entry 9, I really just went through cameras and viewports conceptually without doing a whole lot of coding.

As always, the Official newtius project page on is up, featuring the last playable version.

Back the truck up

I was having a few…difficulties…with that Space mods tutorial so I decided to take a step back by creating another git repo called GMS2 Skunkworks. Skunkworks in this context is supposed to be shorthand for “experimental things I throw in a bucket to try out”. I did the repo smarter this time though by making the first project in this repo a sub folder so I can add more projects later. I called my first skunkworks project Fun with cameras and viewports and started a complete blank/fresh GMS 2 GML project.

Since I had already seen that second space mods video so many times I decided this time I would just fast forward to the coding parts of the video and leave it paused on that screen.

I made a basic project with a random player object and assigned the controls to it. And I named the default room rm_game. Then created a new object called obj_camera and made it “persistent” (via the checkbox). I then proceeded to go line by line through each event and add in the code. But this time I looked up each of the functions used in each event and tried to understand what each function did and why it was being used where it was. I also used the GMS sprite editor to create a very bad star scape background sprite and assigned that the game room. And it worked without any problems at all. No idea why (see the pervious post for what I’m referring to).

When I got to the end of the second video this time, I could in fact follow the player object around as cosmonaut does in the video with space mods.

Then I tried an experiment where I thought I could export the camera object and import into my version of space mods (that’s apparently broken) but it turns out the exporting/importing doesn’t work like that.

So I just deleted the camera object from my Meteor-invasion-mods-in-space project and created a fresh one from scratch. Then copy/pasted my code event-by-event. When I tried it out the camera actually worked. The game doesn’t, because the obj_game is some kind of broken, but without that game object the camera follows the ship. [update: actually, I had just started video three and not finished it so there was just a variable reference I hadn’t defined yet. With that commented out it works fine.]

Setting a camera and viewport

I decided to just go step by step through the camera object. I’ll use my own notes as a reference.

Conceptually, the viewport or “screen” is the entire room (say 1000 by 1000 pixels) and camera is the small part of that screen you can see at any one time, say 300 by 300 pixels (or whatever).

First is the Game Start event.

Object: obj_camera
Event: Game Start

//start with some variable declarations
cameraX = 0;
cameraY = 0;
target = obj_ship;

// I was having issues with how cosmonaut did it so I just
// gave them straight up integer values
displayWidth = 1000; // I'll just hard set this
displayHeight = 1000; // I'll just hard set this

cameraWidth = 600; // I'll keep this for later
cameraHeight = 1000; // I'll keep this for later

// next is a check for a couple of things. I actually got the
// idea for this from the manual page
// these are reserved value variables: view_enabled and view_visible
if ( !view_enabled &&  view_visible[0] != true ) {
	view_visible[0] = true; 
	view_enabled = true;

// next is setting the size of the camera
camera_set_view_size( view_camera[0], cameraWidth, cameraHeight  );

// I didn't have a reference for this one but it appears to just
// set the game window size so I just "went with it"
window_set_size( displayWidth, displayHeight );

// I had do do some reading on "surface" and "application surface"
// long story short it's kind of a generic OS generated window,
// like a basic win 32 C API way of creating a simple window
// (as far as I can figure)
surface_resize( application_surface, displayWidth, displayHeight );

// this is to use the code in alarm 0 1 frame into the game starting
alarm[0] = 1;

// this is supposed to help later with draw events. 
// so the "lives" and "score" text stay consistently up in the 
// upper left corner regardless of window size
// i'll leave it in case i need it later
// obviously the variables are from the top of the event code
display_set_gui_maximize( cameraWidth, cameraHeight );

Reference links:

The next obvious question would be “what’s in the alarm 0 event?”. Well not a lot as it turns out.

Object: obj_camera
Event: alarm 0


This was added because in the video the window wasn’t centering on the screen. But with mine it does center on its own. So I’m just putting this here for completeness.

Object: obj_camera
Event: Step

//the if probably isn't necessary in this case but 
// i don't think it hurts either
if ( instance_exists(target) ) {
// this just sets the camera to be centered over the top of the ship 
// since target was just set to obj_ship
	cameraX = target.x - ( cameraWidth / 2 );
	cameraY = target.y - ( cameraHeight / 2 );
// the "clamp function I think just makes sure an integer comes out
// the other side. So in every "step" which is effectively 60 times
// a second, CameraX and CameraY are set to both the ships x and y
// and centered over the top then also set to the nearest whole number.	
	cameraX = clamp( cameraX, 0, room_width - cameraWidth );
	cameraY = clamp( cameraY, 0, room_height - cameraHeight );

// Then at the very end is this camera set view position line
// using the camera we made and the CameraX and CameraY we setup 
// above
camera_set_view_pos( view_camera[0], cameraX, cameraY );

Just one the reference this time, for camera_set_view_pos.

So that’s it then. I don’t think I could re-produce the camera system from scratch or anything. But that’s a working version of a camera that follows the player.

I’m also not sure if I could set it up for Newtius. I mean I probably could. I was going to make a room that’s a static height while having a very long horizontal. It is a horizontal shooter, after all. And dimensions something evenly divisible by 5120×1440 so it will scale up to that resolution. I have the screen with that size, may as well optimize for it. Right?

I should probably clarify what I mean by “static height”: unlike in my not-asteroids game where I can explore the width and height of the “room”, in Newtius the top and bottom are visible at all times. So going down doesn’t make some part of the top of the view obscured in anyway. Veristically it’s always all visible.

The latest version/progress of Newtius can always be found at my GitHub repo:

One thought on “Dev Log Entry 10: Viewport is verb now – part 2

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s