How I Scale Fuzeboy Resolution on Mobile and Desktop Devices

Fuzeboy's still in development so it's only natural that sometimes I take time to rewrite stuff, to fix things, to experiment and so on. We try, we break, we fix, we extend, we change. We evolve.
A scene from Fuzeboy. There's only one way to view pixel art... and that is with pixel perfect scaling.
One issue we faced from the start, is the game resolution. What we knew was that we wanted pixel perfect scaling no matter what. Remember that this game will be both for mobile and desktop.Here's my solution as of today.

The Ideal Game Resolution

Fuzeboy cares about its height. The width depends on the monitor aspect ratio (within reasonable limits). The ideal height of Fuzeboy is around 240px. Keep this in mind.

Pixel Perfect, Full Screen, No Black Bars (didn't work)

This approach was the first I used. Since not every device has a vertical resolution that's a multiple of 240px, I allowed different devices to show more or less "game world".First I get the display vertical resolution. Then I cycle from 200px to 300px to see which one fits perfectly the device vertical resolution. If I don't find a perfect fit, I give up and just use 240px.

Fuzeboy on Devices, method 1

DeviceResolution (vertical)Game Vertical ResolutionMultiplier
Amazon Kindle Fire 7"1024 x 600 (600)3002
Samsung S3 Mini800 x 480 (480)2402
Asus MeMO Pad 71280 x 800 (800)2004
This doesn't work. It's pixel perfect most of the times, there are no black bars... but you might end up seeing an unplayable 200px vertical resolution on a 7" tablet.
We don't want this to happen... do we?
Let's have a look at an Amazon Kindle Fire 7"
This is better. Or... is it?
There's a huge 100px difference in height from the Asus to the Kindle. The Fire users would have been able to see 50% more game world than the Asus players. That's wrong. Especially since Asus has a higher screen resolution than the Amazon Fire.

Pixel Perfect, Black Bars (in use as of today)

First of all I decided to restrict the range of vertical resolution of the game. Now it's from 230px to 260px. Still a 30px difference but it's bearable.So I still ask for the device vertical resolution, of course. Then I check which number, from 230 to 260, fits best. By that I mean it either fits perfectly or has the lowest remainder.This is the initialization script. It goes inside the create event of the very first object created in the game.I also leave the view settings in the room editor as they are. Disabled. I enable them via code.

// Let's disable the drawing of the App Surface

dw = display_get_width()        // Device Display Width
dh = display_get_height()       // Device display height
ar = dw / dh                    // Aspect Ratio

min_h   = 230                   // Minimum Height
max_h   = 260                   // Maximum Height
height  = min_h                 // We start from the minimum
fract   = frac(dh / height)     // This is the fractional part
mult    = floor(dh / height)    // This is integer multiplier

// We cycle from min_h to max_h
for (var h = min_h; h < max_h + 1; h++)
    var new_fract   = frac(dh / h)
    var new_mult    = floor(dh / h)
    // If we have a lower remainder, we store
    // the multiplier and the height we're testing
    if new_fract < fract
        fract   = new_fract
        height  = h
        mult    = new_mult

// This will show you the found resolution in the debug console
show_debug_message("Found resolution: " + string(height))

// Width gets decided with a simple division
width = floor(dw / mult)

// And made divisible by 2
if width mod 2 != 0

var i   = true;
var rm  = room_next(room);
while (i)
    room_set_view(rm, 0, true, 0, 0, width, height, 0, 0, width * mult, height * mult, 0, 0, -1, -1, -1)
    room_set_view_enabled(rm, true)
    if (rm == room_last)
        i = false
        rm = room_next(rm)

// Resize the application surface
surface_resize(application_surface, width, height);

// Let the GUI layer be as big as the device screen
display_set_gui_size(dw, dh)

gw = display_get_gui_width()    // GUI width variable
gh = display_get_gui_height()   // GUI height variable

// We'll need these to figure out the touch commands coordinates
wscale = width / (dw / mult)
hscale = height / (dh / mult)

// Let's figure out the App Surface offset (we want it centered)
Xoffset = floor((dw - (width * mult)) / 2);     // Horizontal Offset
Yoffset = floor((dh - (height * mult)) / 2);    // Vertical Offset

/// Go Fullscreen on desktop
if os_type == os_windows
Then we need to draw the App Surface. So in the game controller object, I have the following code in a Post Draw event.
///Draw the App Surface with correct offset

// This line prevents strange artifacts in Fuzeboy.

// The real drawing.
draw_surface_ext(application_surface, Xoffset, Yoffset, mult, mult, 0, c_white, 1);
If I run the game on the Amazon tablet, the result is this:
The game now has a height of 260px

Fuzeboy on Devices, method 2

DeviceResolution (vertical)Game Vertical ResolutionMultiplierBlack bars top/bottom
Amazon Kindle Fire 7"1024 x 600 (600)260220px
Samsung S3 Mini800 x 480 (480)24020
Asus MeMO Pad 71280 x 800 (800)260310px
Now the game scales much better.

Let's fix the Touch Controls.

Those touch buttons share the obj_touch parent so I can do this in the controller Begin Step event.
// Add these in the display init script
xoffsetmult = (Xoffset / mult)
yoffsetmult = (Yoffset / mult)
// Touch Controls
for (var dev = 0; dev < 4; dev++)
    touch_dev       = dev
    var _xpos = (device_mouse_x_to_gui(dev) / mult) + view_xview - xoffsetmult
    var _ypos = (device_mouse_y_to_gui(dev) / mult) + view_yview - yoffsetmult
    var this_button = instance_position(_xpos, _ypos, obj_touch);
    if this_button != noone
        if device_mouse_check_button(dev, mb_left)
        if device_mouse_check_button_pressed(dev, mb_left)

        if device_mouse_check_button_released(dev, mb_left)

The Future

As of today, I still experiment with the resolution of the game. I haven't found a perfect way to scale low res pixel graphic fullscreen with no black bars and no distortion... simply because such a way doesn't exist.Things change frequently around here, so we'll see if I'm going to stick with this method or not. Feel free to let me know your ideas on this matter.

Optimizing Collision Code

As I said in a previous post about my platformer engine (the one I’m working on for Fuzeboy), I’m using Zack Bell‘s code as a base. Recently I started to look into ways to optimize such code without losing the functionality (slopes are a big feature of that simple collision/movement code).

Looks like I was able to gain some speed here…

And as someone once told me “sharing is how better games are made”… so here it is my “improved” version.

Continue reading Optimizing Collision Code

Basic Platformer Mechanics in GameMaker: Studio

I’m fond of platformers. It’s only natural that I spent the past year studying and refining platformer engines for GameMaker: Studio. Here’s what I actually use for my engine.

Fuzeboy early gameplay

Continue reading Basic Platformer Mechanics in GameMaker: Studio

Fuzeboy devlog – Fair death system

Don’t you hate it when, during a death animation/sequence, your character accidentally touches a powerup or a health pack… and then it dies anyway?!

Normal Death vs Last Chance (non)Death ™

This is what we wanted to avoid in Fuzeboy: unfairness. If you catch a heart during the final knockback, you will have another shot at it.

Fuzeboy full steam ahead!

In November 2016 I met Denis (@darftey). He’s a pixel artist. One of the best I’ve ever met, actually. We teamed up to develop Fuzeboy.

Full steam ahead! ouch!

It shouldn’t come as a surprise that since then, the development of KREN has been put on hold indefinitely.

We’re pushing hard on this mobile platformer game.

Unnecessary tricks…

There is still no official release date but we’re making progress 24/7 on every front. From music and sound to gameplay mechanics, from platform specific issues to minor graphic details.

Lots of care is being put into making this game as fun as possible. We care about details. We care about story and gameplay. We are in love with this game and we’re making sure everything goes the way we envision.

Stay tuned for more Fuzeboy news in the near future.

Devlog #1 – GameMaker: Studio new Project

This entry marks the first entry of a new Devlog Series.

I’m currently working on a couple of GameMaker projects and I thought it might be useful to document my development process. I’ve been inspired to do so by reading the Loadworld Devlog PT. 2 by @ZackBellGames

Continue reading Devlog #1 – GameMaker: Studio new Project

Metroidvania Metroid-like World Design

The Metroidvania Metroid-like game genre, from a development perspective, is quite complex to master. World and level design, for examples, are core elements of the game along with player abilities and game physics. You cannot plan one without the other. This is because player abilities, powerups and game physics, are the very elements that allow the Player to  progress and advance (or backtrack) throughout the levels. This also means that levels must be designed around the player’s abilities, powerups and game physics (among other things).

Super Metroid Map
You might get one step closer in learning how to create such a layout.

Continue reading Metroidvania Metroid-like World Design

Kren devlog #3 – basic metroidvania planning

A well developed metroidvania game should start with a solid planning phase. One of the first things to figure out is the character movement. I’m not talking about physical variables such as speed, friction and acceleration. I’m talking about figuring out what are the movements we want the Player to be able to execute during the game.

Example: crouching.

Can the character crouch? If so, should it crouch only when standing still? Can the character crouch in mid air or does it simply aim downward? Is it possible to walk while being in the crouching position?

These are serious design considerations that should be carefully planned and addressed well in advance as they define the feeling of the game. The player will act and react based on what movements are available. It’s the absolute first response to player’s inputs.

Crouching: Metroid Zero Mission vs Axiom Verge.

In both games, you can crouch. But while in Metroid you stay in that position even if you let go of the down key/button, in Axiom Verge you get up as soon as you let go of the key/button.

Also, while in Axiom Verge you can walk while being in the crouching state, you cannot do so in Metroid Zero Mission. Yet if you press the down key again, you morph into a ball.

The mechanics are different and so is the gameplay. Plan carefully what you intend to create and plan it well in advance. If you can, plan it all out even before any test level you might be tempted to sketch.

It will greatly simplify the overall development cycle (i.e. you won’t be rewriting big chunks of core mechanics code again and again, risking to break previous works).

Choosing the right resolution for a 2D Platformer

In this post I'll try to write down the thinking process I made when I chose to develop Kren at a 384x216 sceen resolution.


Everything starts with the tiles. If you make tiles your measurement unit, you're going to be able to simplify the visualization process. I made this kind of reasoning: how many 16px square tiles do I want displayed vertically?

Can you count the tiles? (hint: it's 15x10)
Can you count the tiles? (hint: it's 15x10)

I wanted to be able to show at least 10 tiles. Which then I realized was a pretty low number for a Desktop game. That meant having a vertical resolution of 160px. That was the resolution of Metroid Zero Mission, on a Game Boy Advance. Granted, it looked great even on an emulator, on a Desktop PC... but... did I really want to go with that little number of tiles? Let's look at how others approached the problem...

This is what the player sees on the monitor. Notice the small character and the whole room is in the view.
This is what the player sees on the monitor in Axiom Verge. Notice the small character. Also the whole room is in the view.

Axiom Verge, a more modern desktop platformer, is displaying almost 17 tiles vertically, at a vertical resolution of 270px. So I had to stop and ponder a little. Was it enough? Was it too much?

Too much indeed. Axiom Verge displays gigantic environments around one of the smallest player character I've ever seen. The player's height to screen height ratio is absurd. But it works, for that game.

I wanted to keep a more claustrophobic feeling. Given I didn't want to mess with tile size, I had to display less tiles. Simply by reducing the resolution.

Aspect Ratio

Metroid Zero Mission has a resolution of 240x160. It's a 3:2 aspect ratio and it's not what most computers use today (or even back in the days). In fact the 16:9 aspect ratio is now almost a universal standard. Or at least you can find it in most of the TV sets, desktops and notebooks you see around.

Back to Axiom Verge. It's 16:9, which is great. But I already chose not to go with a resolution as high as 480x270 because I want less tiles on the screen.

Don't get me wrong. If you want to be able to display a great number of 16x16 tiles on the screen, 480x270 is a really great option. I would advise you go with that resolution! It's 1/16th the pixel area of a Full HD monitor. Which means it scales pretty well without pixel interpolation artifacts (you multiply 480 and 270 by 4 and you get the 1920x1080 Full HD resolution).

Next, I looked at the closest 16:9 resolution available with almost the same vertical resolution as the Game Boy Advance: 288x162.

I made a few tests at this resolution and even though I liked it (a lot), it doesn't scale well. There's no easy way to scale the 288x162 resolution to perfectly fit a 1920x1080 monitor. That means problems. Also, even though I liked the effect, it really is a little bit ugly. And maybe a little too much claustrophobic, even for my game; there's barely enough space to fit 10 tiles, vertically. Given my player's height is a bit more than 2 tiles, it meant huge player (yes, you can draw a different character), really small "field of view" and ugly pixels.

The 384 x 216 Compromise

I finally found the optimal compromise resolution: 384x216. Multiply that by 5 and you get the Full HD resolution. This should avoid pixel interpolation distortions. It also allows me to display 13.5 tiles vertically. This is not that far from the Game Boy Advance look, but it sits nicely between Metroid Zero Mission and Axiom Verge.

Testing the resolution and the view size. Notice the size of the Player and the smaller visible area.
What the hell is this?! (just a fun way to test player size, resolutions and ratios). It gave me familiar elements to gauge my observations.

I don't want the player to feel small, inside gigantic environments. I want the players to feel the environment around them. Leaving him/her with little air. But not as little as in Metroid ZM on the GBA. All with a modern 16:9 look.

I found my own resolution with this process and a bit of testing. It might not be the best approach (in fact I'm sure I might have missed some other considerations) but for now it's working great. Your mileage may vary so I recommend a lot of testing.

Kren Devlog #2 – Officially looking for a (Pixel) Artist

Today I started posting around forums. I'm looking for an artist. I have no artistic skills whatsoever; I cannot draw tilesets, sprites, animations... let alone concept art.

My primary objective would be to prototype the game with graphics.

I still don't know if this is going to be a commercial project or not.
Should it become a viable commercial game there could be many options. Here are just some of them

  • Prototype's used to get funding. Then...
    • The artist remains the same, becoming the final game artist. Gets what is due to him/her, plus revenues shares.
    • The artist changes; prototype art won't be used; he/she will get no revenues shares but will get what is due to him/her.
  • Prototype's not a prototype anymore and is ready to market; no more funding necessary. Artist remains the same so revenue share model apply.
  • Project gets cancelled. No one gets anything (this should not happen! at all costs!) Artist is free to use his/her art however he/she sees fit.
  • Project is released as freeware (unlikely). Same as above.

The project is going for the commercial route. It's now a revenue share work relationship.

Right now I'm unable to test the mechanics, to think about what works and what doesn't; to imagine the game world. I need to quickly place things in the levels, test them and get an emotional response as to what works and what doesn't.

That statement is a dramatic exaggeration. But you get the idea.

As of now, everything you see in the image below, except the blocks tilesets, were drawn by me. Ideally, this should change.

Still in early planning stages. Yet testing the platformer engine made in GameMaker.
Still in early planning stages. Yet testing the platformer engine made in GameMaker.

Right now I'm working full-time on this project.


  • I will be trying to help the artist as much as I'm able to, given my limited artistic skills.
  • The game will have a resolution of 384 x 216.
  • Player will be more or less 36px tall.
  • The current game art won't be used as a basis (thank god!)

Beware: the game videos/images are only there to show collisions and other tech aspect. The overall feeling of the game is going to differ drastically. Think Super Metroid (there, I said it).

This won't be an action packed game.
In fact, when I think about it, I think about words like

  • solitude
  • isolation
  • mysterious
  • unearthly
  • uncanny
  • dark
  • ghostly
  • unnatural
  • dangerous

If you would like to collaborate, have comments or want to share your thoughts, leave a comment or get in touch via social networks etc.


Use the contact form I set up