1. Clears the Bitmap Cache (again :))
2. Resets Input
3. Destroys all sounds
4. Resets various internal arrays and variables to zero
5. Sets the TimeScale to 1.0
6. Seeds the random number generator
7. Sets the World Bounds to -10, -10, Width + 20, Height + 20
8. Sets World Divisions to 6
9. Creates the DebugPathDisplay Plugin

1. If a Replay or Replay Recording is requested, it will process that (this will never happen on the first run)
2. If there is a new state (different from the current State) then switch to it (again, doesn’t happen on the first run)
3. Set the ACTIVE COUNT to zero
4. If Replaying it steps through the replay log, otherwise:
5. Update Input: If a Key is pressed it retains the Boolean for it. If the Mouse has moved, it updates the mouse variables.
6. If Recording, it records the frame
7. Calls Update
8. Sets the Mouse Wheel values to zero

1. Calculates the Mark and FlxG.elapsed values based on the timescale. FlxG.elapsed = FlxG.timeScale * (step / 1000)
2. Calls FlxG.updateSounds – Which handles panning, proximity and amplitude changes in sounds
3. Calls FlxG.updatePlugins – Iterates through the plugins list and if active calls the plugin update method
4. Calls FlxState.update – See below
5. Calls FlxG.updateCameras – Iterates through the cameras Array (on first pass it’ll just have the one default camera in there). If the camera exists and is active it calls update on it, and the cameras flashSprite is moved based on the new x/y coordinates (if changed) or set in / visible.
6. Finally if the FlxDebugger is visible it updates the timer on it.

Remember that this can all happen multiple times. Probably the most important part of it is #4 when it calls FlxState.update. FlxStates extend FlxGroup, they don’t have update functions of their own – but FlxGroup does. So every single object you add into your state (FlxSprites, FlxTileMap, etc) are all added into this one “master” group. Even other groups, Flixel doesn’t care how deeply nested they are.

FlxState.update iterates through every object in members array. Providing the object has exists = true and active = true, it calls 3 functions on it:

Different objects perform different tasks in these three functions. For example an FlxSprite in its preUpdate call will track the last known coordinates for collision purposes, and also check if the sprite was moving on a path. In postUpdate the FlxSprite will update its motion and animation if there is any. Depending on the type of Flixel object depends what happens in these 3 functions.

It’s also well worth mentioning that typically in the update function of your FlxState is where you normally put commands such as FlxG.collide and FlxG.overlap. We will cover this in more detail in a later tutorial, but it’s still useful to know exactly when in the flow they are handled.

FlxGame.onEnterFrame, continued …

After running step and update as many times as the Accumulator wants, it then calls draw once, and ends the onEnterFrame function.

The draw operation is the most expensive part of Flixel, as it’s where it renders all of the cameras, sprites and objects that build-up the visual display. It does so in the following sequence:

Lock Cameras

FlxG.lockCameras is called, iterating through all active cameras. If useBufferLocking is true, then it will lock the bitmapData per camera (note that the default for this is false). It then calls FlxCamera.fill. This does a fillRect on the fill bitmapData object using a colour value of zero, effectively wiping it clean. It then does a copyPixels from fill to FlxCamera.buffer and finally sets FlxCamera.screen.dirty to true.

FlxState.draw

An FlxState doesn’t have a draw method of its own, although you can over-ride i should you need to do something after all of the children draw operations have finished. FlxState extends FlxGroup, which does have a draw method. Whenever you add something to your State, you are effectively adding it to one giant FlxGroup.

The FlxGroup draw method iterates through all objects in the groups members Array. If the object has exists = true and visible = true then it calls their own draw function. Depending on the data type of the object depends what happens next. The following is the draw process for an FlxSprite:

It will do the above sequence for every single FlxSprite used in your State! And of course not just sprites – but tile maps, buttons, text, etc. So do try and be careful about what you leave laying around in memory. Always make sure you set exists or visible to false when you’re done with an object. Although Flixel is clever enough to not bother doing a copyPixel if the object isn’t in any of the cameras views anyway, it will still avoid all of those checks. And if you’ve got thousands of sprites, that’s a lot of extra baggage you can shed.

However the draw process isn’t finished yet! We’ve just locked and cleaned all the cameras, rendered all the sprites and other objects, so the final two things it does are:

1. FlxG.drawPlugins. This iterates through all of the plugins, and if they are active it will call their draw methods. It’s important that when creating a plugin you decide when it’s going to process whatever it does. As you can see from this flow plugins are updated FIRST, before all of the game objects (such as your FlxSprites) are. So if you have a plugin that modifies the x/y coordinates of an FlxSprite it’s important to realise that will happen before the calls to things like updateMotion or FlxG.collide – perhaps un-doing the work of your plugin in the process. The same is true of visual changes to sprites. Basically, test, test, test! Sometimes it’s better to have plugins perform graphical changes here, in their draw function. And sometimes it’s better to do it in their update.
2. Once the plugins have all drawn FlxG.unlockCameras is run. As you can imagine this iterates through all the cameras, only this time if they are visible it will call their FlxCamera.drawFX functions. This internal function handles the flash, fade and shake effects built into Flixel. If any of them are running they are applied right here. Personally I think they ought to be moved to plugins 🙂
3. After it’s all shaken and faded the cameras bitmapDatas are actually unlocked. But as you may recall bufferLocking is disabled by default, so in practise this doesn’t actually do much.

All of the above happens every single frame in your game! That could be 30 or even 60 times per second. So it’s easy to see that if you aren’t careful you can be making Flixel do lots more work than it actually needs to.

My take-aways from this post are:

1. If you find the Delta Timer trouble-some it’s very easy to disable. Just edit the FlxGame.onEnterFrame method and remove the _accumulator checks, and just make sure that step() is run once, and draw() is run once. This is how earlier versions of Flixel used to work, and you may find it improves performance significantly.
2. Be tidy! Re-use (pool) objects. Don’t leave references laying around. If a Sprite isn’t needed, make sure you kill it properly (active / exists / visible to false) to stop it being rendered.
3. If you have loads of items in a FlxGroup, but have done something like stick a great big picture over the top, then disable that group until the picture is removed. It’ll save processing on all of the group items that are obscured from view but will be rendered regardless.
4. Plan your plugins carefully. It makes a significant difference if they are update or draw based. Sometimes moving the processing logic to draw actually helps.
5. Don’t set your game or flash frame rates too high. Especially if you are not using a zoom mode / have a larger resolution game. Keep them at 30/30 if you can.
6. Rotated FlxSprites are expensive if you don’t use baked rotation!
7. Scaling and Blend Modes are expensive! Use sparingly. If you just need a sprite to be say x4 larger in size than it actually is, and the scale won’t change during play, then consider either rendering that sprite x4 bigger in your art package and having 2 versions of it – or scaling it during the create phase of your game, then using the bitmapData to make the actual game sprites from. Basically do what you can to avoid that call to draw() with the matrix transform.
8. Don’t be scared to dig deep into Flixels guts and change it 🙂 There are definitely things that can be improved in there!

If you’ve made it this far well done! Relax by looking at some beautiful pixel art 🙂