HaxeFlixel Tutorial – Camera Zoom Revisited

In the previous post, I wrote a tutorial on how to zoom the camera in a hack-ish way. Turns out the original author of Bullet Time Ninja article, Greg Lieberman, already fixed that with a haxeflixel-addon class, the FlxZoomCamera. If you look at the API page, you’ll notice that it doesn’t say much, so let’s explore that today.


I learned from a recent HaxeFlixel tweet that you can create a new HaxeFlixel “barebones” project template, which has minimal files/folders, and also excludes all the config and comments:

Notice that the usual MenuState.hx file is now missing — the entry point is now PlayState.hx, which makes more sense. We’ll be using the barebones template for tutorials from now on. 🙂

Before we proceed, let’s change some configs — notice the difference of Main.hx (between barebones and non-barebones). The config variables and comments are now missing, and entry point (the last line) relies on the default values (Refer to the API):

Anyway, to change the resolution of the screen, do it in Main.hx :

… and to change the size of the window screen, do it in Project.xml :

To use the FlxZoomCamera class, which belongs to the flixel-addons haxelib, we need to enable it in the Project.xml, by uncommenting the line below:

And now we can start coding!


Let’s set up the code similar to the previous tutorial:

And when you run with lime test neko , you will get a player that moves in a placeholder map:


Now let’s use the FlxZoomCamera addon:

And when we test :


Hmm, when you zoom out, the camera behaves in a peculiar way — the camera moves along with the player’s movement.

If you refer to the FlxZoomCamera API, there doesn’t seem to be anything you can modify that can change the way the camera moves when you’re zoomed out.

However, if you look into the FlxZoomCamera.hx file (on OSX, it’s located at /usr/lib/haxe/lib/flixel-addons/1,1,0/flixel/addons/display), you’ll notice there are actually two private variables that seem better off as public:

You can just make these public , and you can now play around with the value in your game, perhaps like this:

And the result:


Note the zoom speed has reduced greatly. Also, when zoomed out, the camera doesn’t seem to move around too much when the player moves.

_zoomSpeed  sounds self-explanatory, but what exactly is _zoomMargin ? I don’t really know. I don’t understand what value it should be, but after some tinkering, it seems to be a range between -1.6 to 1.6. So if you want the camera to not move when zoomed out, just set _zoomMargin  to a big value (e.g. 1.7) and it will probably work.

Otherwise, you may need to extend or rewrite the FlxZoomCamera.hx‘s  alignCamera()  function to suit your needs.

This concludes the revisited tutorial on zooming the camera.

HaxeFlixel Tutorial – Camera Zoom

@mikeevmm tweeted me early this month and noted that there are some problems with FlxCamera.

Here are some known issues I could identify:

  1. Camera doesn’t follow well when zoomed.
  2. Objects start disappearing when zoom is less than 1.

The problems above are apparent (as of writing) even in the FlxCamera demo.

There’s an article by Bullet Time Ninja that discusses and resolves the camera issue, but it’s from 2011 and uses Flixel (not HaxeFlixel), so the result may differ.

Today’s tutorial will attempt to resolve the first problem stated above. If there is a solution for the second problem, I’ll write a tutorial to address that next time. 🙂


As usual, let’s setup a new HaxeFlixel template project for testing:


First, let’s set an arbitrary resolution of the game in the Main.hx file:

Now, let’s go into MenuState.hx (the default entry point for the game) and create a large-enough level with a movable character:

Now if you run the game with lime test neko , you’ll get a player that can move around a placeholder map, and the camera follows it, within the map’s bounds (btw, yes, there is no collision logic):


Now let’s add some debug controls to recreate the problems mentioned at the beginning of the article above:

Now if you test the game — Zooming in and out will only zoom the camera’s viewport. The camera still “follows the player”, but not in a way you would expect:


When we use  camera.zoom , it seems we’re actually resizing the camera’s viewport. So how can we fix this? With my limited knowledge, I’d assume the solution is to reposition and resize the camera every time its zoom is changed.

Before we do that, let’s add more debug input into the code so we can later understand what needs to be used to fix the problem:

Now if you play around with the debug keys above, you’ll notice the following points:

  • Changing the camera’s x  or y  value will move the viewport’s origin (top-left corner).
  • Changing the camera’s width  or height  value will increase/decrease the viewport’s size.
  • Changing the viewport size doesn’t seem to update the tilemap’s size, until we use level.updateBuffers() (by pressing P).
  • The camera’s deadzone (when following the player) isn’t updated, until we re-follow the player (by pressing O).

Resolving Camera Zoom issue

After some testing with the debug keys above, it seems we can combine the techniques and resolve the zoom issue, by writing the following code:

Now when you zoom in or out, the camera is centered and the player’s deadzone is updated:


Notice that the player will get cropped when moving out of the map’s bounds. That’s because we used  FlxG.camera.setBounds() . If you modify the following lines:

The player can now freely move around in the camera without being cropped, at the expense of not having any map boundaries:


To top things off, let’s use Bullet Time Ninja’s technique in lerping the camera’s zoom:

And the result:


It’s not perfect, but I think this should be enough for most camera-zooming issues. This concludes the tutorial on zooming the camera.

HaxeFlixel Tutorial – Parallax Scrolling

One great way to enhance the feel of your game is parallax scrolling. I could only find tutorials that briefly mention it, so here’s one dedicated to parallax scrolling. In most cases, parallax is used on horizontal plane, so we’ll proceed with that in mind.


For placeholder images, let’s use some background images from OpenGameArt, Red Baron Backgrounds by MindChamber. Download the zip, and extract it somewhere.

We’ll be using the following files for this tutorial: highwayz – Copy.jpg and highwayz_floor.jpg. I didn’t include the images here in this tutorial so you would go and download the original files from the link above — to support the author 🙂 Anyway, put those two images into your /assets/images  folder and move on.

Now let’s create a HaxeFlixel template project, as usual:

Now we can proceed with the code-related stuff.

Code Setup

Parallax effect can be easily achieved by setting the scrollFactor  value.

If you want to have parallax backgrounds which are repeated, you will need FlxBackdrop , which is part of the flixel-addons  haxelib. To enable the flixel-addons haxelib, go to your Project.xml file and enable the following code:

To use parallax effect, you only need to do two things:

  1. Create an FlxSprite (or anything derived from FlxObject) and set its scrollFactor  value
  2. OR create a FlxBackdrop  and specify the X/Y scroll rate, and whether it repeats on the X-plane and/or Y-plane.
  3. Scroll the camera!

Parallax with [scrollFactor]

The code below demonstrates the above parallax with only scrollFactor :

And that’s it! Build with lime test neko  and you can test the parallax with the LEFT/RIGHT arrow keys.


From other tutorials, like this (Dustytome) and this (Haxecoder), we can observe that scrollFactor/parallax technique can be applied to groups of objects or even UI elements, depending on your creativity. 🙂

Parallax with [FlxBackdrop]

If you want repeated backgrounds in your parallax scrolling, just modify the following lines from the above code:

And here’s the result:



There’s nothing much on the API page for FlxBackdrop, so I guess the usage is straight-forward.

HaxeFlixel Tutorial – Multiple Cameras

If you check the flixel-demos Github page, you can find sample code on how to implement split screen camera, as shown on the demo page.

In this tutorial, we will create a simple platformer which implements 4 cameras. The purpose is to demonstrate that it is possible to have multiple cameras with different properties.


As usual, let’s create a new template HaxeFlixel project from the terminal:

We won’t be needing any assets, because we’ll use the default HaxeFlixel graphics.


First, let’s create a map:

And here’s the result when you build it with lime test neko :

Screen Shot 2015-04-11 at 10.31.30 AM

And now let’s add a playable character, complete with collision and movement logic:

And here’s how it’ll look:


Although it isn’t shown, the camera takes up the full area of the screen (in the case above, it’s 640 x 480). We can resize the cameras to only fit a portion of the screen — and along with this, we can create multiple cameras, to achieve split-screen multiplayer effects. Let’s add some code to make this happen:

Note: The FlxG has a variable camera  that controls the first main camera, whereas the cameras  variable holds an list of all the cameras. Be careful not to make typos here.

Now when you test, you’ll get this:


Notice that the background of each camera is of a different colour, but the screen is still showing the same content (one red player moving around). What this means to us, is that we know each camera has properties that can be customised individually.

Now, by knowing this, we can expand on the code to do the following:

When you test, you will see that this is starting to look like a 4-player split-screen game:


Please excuse the erratic movements — I was mashing my keyboard to simulate 4 players moving around in their individual screens.

Anyway, I hope this tutorial gives you an idea of how multiple cameras can be used (e.g. for mini-maps or split-screen multiplayers). You can refer to the FlxCamera API for more info. This concludes the tutorial on creating multiple cameras in HaxeFlixel.

HaxeFlixel Tutorial – Using The Camera

Today we’re going to cover the FlxCamera class, and its common uses in HaxeFlixel. Here’s a list we’ll be going through:

  • Camera shake
  • Camera flash/fade/fill
  • Camera follow/lerp/bounds

Project Setup

First, let’s create a template HaxeFlixel project, as usual:

To demonstrate camera scrolling and follow functions, let’s create a large CSV map data. Copy the data below, save it as map-data.csv, and put it in your /assets/data  folder:

For the image tilesheet, let’s go to OpenGameArt.org and use one of the tiny 16 basic spritesheets. Download the basictiles.png (a.k.a. basictiles_2.png) and put it in the project’s /assets/images  folder.

Now we can begin coding.

Map & Player Setup

We will not be loading map data using TMX file this time — for simplicity sake, we just load using CSV file. We’ll skip the explanation and jump straight to setting up the map code. Let’s start with the MenuState.hx:

If you build with lime test neko  now, you should see this:

Screen Shot 2015-04-06 at 11.34.00 AM

Note: If the map doesn’t show up, make sure your .csv file does not end with an empty line.

Let’s set the resolution lower so we can zoom in on the map. In the Main.hx, change the resolution width/height from 640×480 to 320×240:

Now if you build again with lime test neko , you should get this:

Screen Shot 2015-04-06 at 11.37.12 AM

Oh, note that the pillar tile is going to be our player tile. Please excuse the poor choice of graphic; We’re just using one placeholder tilesheet. 🙂

Now, let’s quickly parse the player object so we can move on to the camera stuff:

There shouldn’t be any difference visually when you build, — we just have a player object which we can control.

Now let’s add some player input in the update  function:

And if you build now, you should be able to control the pillar… er, player:


Great! Now let’s move on to the main content of today’s tutorial — using the camera.

The reason why we took quite a few steps to setup the game is so that we have a visual reference, to know the camera functions are working. If you started with a simple empty black screen with a blue box in the middle, it would’ve been difficult to tell if the camera actually shook, or if the camera actually follows the player as you move.

Camera Shake

The simplest way to use the camera shake can be written as follows:

You can refer to the FlxCamera API on how to the function callback and whatnot. If you’re not sure how callbacks are written, try reading the Button events & callback tutorial here.

Notice how when the screen shakes, there’s a visible black area around the screen’s edges:


From a quick search, this page reveals a simple solution. Just add the following lines in your create  function to extend the camera size:

Note that the ext  value is arbitrary, as long as the camera shake’s intensity doesn’t go beyond the extended range.

And now there won’t be any visible black area when the screen shakes:


Camera Flash/Fade/Fill

Camera flash can be used for situations such as lightning flash, or explosions. Let’s just modify the existing camera shake test buttons like this:

Now you should get this when you test:


The camera’s fade  and fill  functions are similar to flash .

fade  will gradually fill the screen with a color — the opposite of flash.   fill  instantly fills the screen with a certain colour. These two functions can be used hand-in-hand for situations like fading in or out between screens. You can check out the FlxCamera API for more info.

Camera Follow/Lerp/Bounds

To get the camera to follow something (in this case, the player), you can just write it like this:

And here’s the result when you move around:


At first glance, there are three problems:

  1. The camera scroll is too rigid (no deadzone).
  2. The camera movement is not smooth (no lerping).
  3. The camera can move out of bounds (shows the black area).

Let’s go fix each of the problems above.

1) To fix the rigid scroll issue, you need to add “deadzones” in the camera (an area within the screen that won’t scroll the camera). HaxeFlixel has a few presets which can be used in the  follow  function, as indicated in the API page. Here’s an example usage, by modifying the existing code:

Note that we added the preset STYLE_TOPDOWN and now it’ll automatically follow the player, with a little deadzone, as demonstrated below:


2) To add smooth camera scrolling (lerping the movement), you can just add additional values to the follow  function, like this (refer to the API):

And now the camera will lag a little when the player moves:


3) To prevent the camera from moving out of bounds, you just need to set the bounds of the map, like this:

And this will give you the result:


There’s a lot of other things you can experiment with in FlxCamera, so go ahead and try them all out! The information above should be enough to give you a rough idea of what’s possible with the FlxCamera — they’re very handy in prototyping games.

This concludes today’s tutorial on HaxeFlixel’s camera. In the next post, we’ll try something more advanced with the camera — split screens and parallax scrolling.