Free, cross-platform 2D game engine powered by Haxe and OpenFL


flixel | addons | ui | demos | tools | templates | docs |

CI Discord Haxelib Version Haxelib Downloads Haxelib License Patreon


Here are the most important links to get you started with HaxeFlixel:

If you want to contribute code or report an issue, please check our


Thanks to being built on top of Haxe and OpenFL, HaxeFlixel can target the following platforms natively:


HaxeFlixel has its roots in the original ActionScript 3 version of Flixel, created by Adam “Atomic” Saltsman. It was started by Alexander Hohlov in 2011, initially as a straightforward Haxe port of the AS3 codebase and Richard Davey's Flixel Power Tools.

Thanks to the efforts of the core team as well as over 100 contributors, today's version of HaxeFlixel far surpasses the capabilities of the original. Not only has the core engine seen many substantial improvements and new features, there is also a far richer ecosystem with additional libaries and over 80 demo projects to learn from.

  • Naming convention suggestions

    Naming convention suggestions

    The current style guide may be found here:

    While I know it would be difficult to change certain conventions, I want to put forward some arguments and suggestions for consideration.

    As well as having intrinsic benefits, some style changes could help to make HaxeFlixel more appealing to prospective developers. On a couple of occasions I've spoken to developers who do not use Flixel, but did cite the strange prefix naming convention.

    The "Flx" Prefix Regarding the Flx prefix, the existing code-style doc points out, "Even though this is widely regarded as bad style, it still makes sense to follow this convention since it is so deeply ingrained into the flixel workflow and doing otherwise would be very inconsistent and confusing."

    Arguments for changing this convention include:-

    • The prefix is unnecessary. Packages already provide this information and should be used to resolve name conflicts.
    • Increase readability. Shorter lines, less fluff.
    • Less to type.
    • Better for auto-completion.
    • Yes, it is considered bad style, and this might affect prospective developers' likelihood of trying HaxeFlixel.

    Arguments for keeping the convention (with counter points):-

    • "It's always been that way and I'm used to it."
      • Prospective developers are not, and it is in your interest that HaxeFlixel remain competitive with alternatives to ensure there is active interest in continuing development. The more people using HaxeFlixel, the more contributions it will recieve. Some developers might compare HaxeFlixel to an alternative and think "HaxeFlixel and X are both good, but HaxeFlixel has an ugly, impractical naming convention. I wonder what else in HaxeFlixel is ugly and unconventional. I'll go with X."
      • The "I'm used to it" argument can be applied to every bad design/convention ever.
      • It is easy to become used to a better, cleaner design.
    • A lot of work to change?
      • The work is heavily reduced by automatic renaming, i.e. Refactor->Rename, or find and replace in files
    • Changes the API, migration impact for users
      • Considering the next release will be a new major version, now would be as good a time to change it if ever.
      • Could provide migration script?
      • ~~Could provide option to restore the old names with a flag in project xml, which uses typedefs?~~
    • It lets you see which classes belong to the engine.
      • Why should this be useful? When using a class one needs to know its function, not where it came from. Far more information can be gained by hovering the cursor over a the text in FlashDevelop.

    "_" prefix for private variables The underscore prefix is a remnant of AS3, which required underscores due to a deficiency that Haxe does not have. The underscore convention is generally useful in languages that allow you to define getters and setters of properties, but where a naming collision might occur between the getter/setter methods and the member variable. Haxe does not have this issue, thanks to the way properties are defined. Note that changing this convention would not affect the API.

    Arguments for changing the convention:-

    • The underscore is no longer required.
    • It is more robust. When using an underscore, any decision to change the visibility of the property would require a complete rename, whereas without an underscore you simply need to change the property signature.

    Arguments for keeping the convention:-

    • It let's you easily see which variables are private.
      • This should not be useful. It is much better to consider the implementation of methods separately to the public interface.

    Captitalized method parameters This is pretty unconventional. It makes local variables look like classes, especially when they share a name with a class. It is futile simply trying to avoid the "this" keyword, as there are places it simply cannot be avoided, such as when using abstract values. A find and replace in files with some simple regexs could probably make this less tricky to change. The API itself would not change.

    opened by JoeCreates 91
  • Add support for OpenFL 8

    Add support for OpenFL 8

    This is still a work-in-progress, but just like #2133 this adds support for OpenFL 8 via the new drawQuads() API. Instead of creating a compatibility layer and effectively reimplementing the Tilesheet API, it adds a FlxDrawQuadsItem that is more properly integrated into the current renderer.

    Currently I'm in the process of getting Travis builds green (I added jobs for OpenFL 8).

    Work on #2068 might still continue after this - it's a full render refactor which adds some cool features. This PR really just adds OpenFL 8 compatibility, and due to drawQuads() this is possible much more quickly and with much fewer changes.

    There will probably be a transition phase in which OpenFL 3.6.1 will still be supported for quite a while. This branch is compatible with OpenFL 3.6.1 Legacy, OpenFL 3.6.1 Next and OpenFL 8. This is a bit messy in places, but probably necessary.

    How to test this

    • install my flixel branch via haxelib git flixel draw-quads-2
    • install openfl dev via haxelib git openfl
    • for Lime, the latest Haxelib release (6.2.0) should be fine
    • some demos and some flixel-addons classes need updates as well, there's branches here: [1], [2]


    • Shader filters (per-game / per-camera, such as in the Filters demo) are not supported yet. @jgranick is working on the OpenFL side of this.
    • Per-sprite filters already work! However, they need to be adjusted a bit (see FlxBunnyMark).
    • flixel.effects.postprocess is currently not supported, and might be deprecated since you can do basically the same thing with filters.
    • Blend modes are not supported (lack of support in drawQuads())
    • FlxPreloader currently falls back to OpenFL's default preloader

    Feedback is appreciated!

    opened by Gama11 51
  • Implement OpenFL Next's Tilemap API

    Implement OpenFL Next's Tilemap API

    OpenFL Next has a new rendering API called Tilemap, which is supposedly faster than drawTiles (but does not support scaling or rotation at this point, so implementing it at this point would only be experimental).

    An example implementation can be found in OpenFL's BunnyMark sample:

    opened by Gama11 45
  • The game freezes on -Dnext

    The game freezes on -Dnext

    • Flixel version: dev
    • OpenFL version: 3.6.1
    • Lime version: 2.9.1
    • Haxe version: 3.2.1
    • Affected targets: neko, windows

    -Dnext. Only debug builds. This issue has been around for a while now. I can reproduce it in FlxBunnyMark demo (see below).

    Observed behavior:

    Scenario 1:

    • run the game
    • minimize the game window
    • restore the window back
    • the game freezes, Update and Draw in the flx debugger show: 0

    Video capture:

    Scenario 2:

    • run the game
    • open and close the flx debugger with tilda key
    • click anywhere inside the game window
    • the game freezes (in the video example Focus Lost screen is shown, but defining FLX_NO_FOCUS_LOST_SCREEN doesn't fix the freeze itself)
    • open and close the flx debugger with tilda key
    • the game unfreezes until the next mouse click and so on

    Video capture:

    Expected behavior:

    The game should not freeze

    opened by starry-abyss 43
  • My `FlxPreloader` changes

    My `FlxPreloader` changes

    These changes seem to make the FlxPreloader work with Chrome again...

    I was looking at the way NMEPreloader works (since it works on Chrome) vs the FlxPreloader, which started getting 'stuck' once my swf was > 5MB.

    It looked like, at some point, someone was worried about the super.onLoaded() function being called more than once, and decided that the way to fix it was to override onLoaded to not do anything, and then call destroy once percent >= 1 and I think this seemed to work okay when the swf was small enough, but once the swf gets to a certain size this logic breaks and it was getting stuck - because EnterFrame still gets called more than once after the swf has finished loading...

    Instead, I stopped overriding onLoaded, and put a flag (_loaded) that will stop EnterFrame's logic from happening after the onLoaded function is called for the first time... In my project, if I revert to the current version of FlxPreloader, it gets stuck every time - and when tracing I can tell that EnterFrame is being called about 10 times after the swf has finished loading. When I use my changes, it has never gotten stuck and only goes through the EnterFrame logic until it's loaded and then stops.

    opened by SeiferTim 43
  • Do not allow invalid data in tilemap loading

    Do not allow invalid data in tilemap loading

    this ensures that input data is actually a number before pushing it to the map, not only to warn the user, but previously the map sizes would be wrongly set if there were commas at the end or xml at the start, hope its good enough:), Nico

    opened by NicoM1 41
  • OpenFL 4 compatibility

    OpenFL 4 compatibility

    This pull request adds openfl 4 compatibilty to HaxeFlixel and it still will work on openfl 3 also. Openfl 3 backend still uses Tilesheet class, but openfl 4 uses custom DisplayObject. I had to make my own class, because Tilemap class is too restrictive and doesn't allow us to have multiple cameras support. I had to reorganize the FlxCamera class: almost all rendering related logic has been moved to FlxCameraView class and its subsclasses, which are kind of backends for different targets. And every camera has view property which is an instance of FlxCameraView subclass. All drawing commands sent to the camera are forwarded to its view. There are:

    • FlxBlitView which works when game uses blit render mode
    • FlxHardwareView which works on native targets. Plus there are plenty other helper classes added for batching handling.

    One more good thing is that shaders are kinda work, but they aren't completely compatible since shader format in openfl had been changed (you'll need little work to convert them to work on openfl 4, nothing special).

    The bad news is that this version contains some breaking changes:

    1. Couple of demos (FlxBlur and FlxBloom) won't compile without small changes since drawing logic had been moved out of FlxCamera
    2. I've mad some changes to FlxStrip class for the sake of optimization - you'll need to set dirty = true; every time you change its vertices, indices or uvtData, or it won't update it's visuals.

    I'll start updating demos this sunday and hope to make another pull request to demos repo next week.

    opened by Beeblerox 39
  • Pixel Rounding on Native

    Pixel Rounding on Native

    I've noticed that there dosn't appear (maybe I'm missing something) to be a way get even pixel rounding (probably the wrong name) on native builds. Here is what I expect (flash build): pixelroundingflash gif

    And here is the native result (neko build): pixelroundingneko

    (note the objects bouncing between closer and farther to each other)

    I thought it would be but its already true, and setting it to false, while fixing the jitter, loses the snapped pixels...

    opened by NicoM1 38
  • GamePad + FlashPlayer 11.8 =

    GamePad + FlashPlayer 11.8 = "Stuckness" bug...

    I'm refering this here and not on the addons issues because I don't think this only affects FlxBackdrop (but I could be wrong):


    1. Get the latest standalone Flash player/plugin (11.8+, as this will not appear on older versions).
    2. Run this SWF: You'll notice the "Stuckness" bug by looking at the line / changing gradient.
    3. Goto this repository:
    4. Enable the line that disable the GamePad on Flash (Project.xml).
    5. Bug's gone.
    6. What's going on here?
    opened by sruloart 38
  • Fix camera occlusion and background for zoom != 1

    Fix camera occlusion and background for zoom != 1

    Here's a demo to compare before and after the changes:

    Native targets for now, on Flash target nothing changed, need assistance on it :-)

    opened by starry-abyss 37
  • Add console to debugging screen

    Add console to debugging screen

    I've been working on recreating Eric Smith's "CoolConsole" (link to YouTube-Video about it, recommended you watch it) in haxe and integrating it into the flixel debugger screen. This has been inspired by Dovyski's suggestion in a Flixel-Community-issue about improving the debugging screen.

    Commit on my HaxeFlixel-fork

    Demo swf

    The console is pretty much functional at this point and has a good number of integrated commands, but likely needs a lot of bug fixing, polish and also a more solid documentation (there are just a few comments here and there right now):

    Known Bugs:

    • It doesn't compile to HTML5 and windows at all atm. Haven't really looked into it, but upon compiling, I get an error saying nme.text.TextField has no field length. Flash seems to be working fine so far, haven't tested anything else. On a lot of (mobile) targets, having this doesn't make sense anyway?


    • I don't really like the 2.5+ debugger at all. Like, the whole FlxWindow-stuff and the different debuggerLayouts. Read more about it in the issue over at the flixel-community repo, I describe it there. What do you think? I kinda think it should be considered to ditch debuggerLayouts entirely, I doubt anyone uses them. Makes it easier to integrate the console as well, which currently only works with one.
    • Adding a call command that calls a function with a set of parameters. Would require a lot of repetition of the code in onKeyPress - or its abstraction. The create command currently also doesn't support parameters for the class it creates an instance of.
    • Create an optional shortcut for each command that consists of two letters only. Might be nice?


    • Testing
    • Bug fixing / Cross-platofrm-testing
    • Proper documentation
    • Make the history cross-platform-compatible. Afaik, it only works in flash due to using a local shared object. Also,


    Not gonna list all of them here, just the more intersting ones (have a look at the help command). A lot of them are basically just links to the public functions of FlxG:

    • clearHistory - The console has a history of up to 25 commands you can browse through by using the up and down keys. This clears it.
    • help - Prints all the commands there are.
    • watchMouse - adds FlxG.mouse.x and FlxG.mouse.y to the watch window. Really useful for building gui stuff
    • play / playMusic - use the "Beep" sound to test
    • create - Creates a new FlxObject at a specified position or a the mouse coords. Use the TestSprite class / object to test it.
    • set - Changes the value of a variable. Use "state" as object parameter to refer to the current state being used (FlxG.state).

    Sorry, I guess I probably didn't cover a lot of stuff, but feel free to ask away.

    opened by Gama11 37
  • I want to be able to downgrade and actually update my version

    I want to be able to downgrade and actually update my version

    • Haxe version: i dont even fucking know


    Im using Haxe 4.2.5, I'm trying to make a Friday Night Funkin' Mod, I CANT. You guys need to make something that makes it so we can downgrade our versions, I'm tired of this bullshit, I'm tired of the auto-update your extension does, I want to be able to make FNF mods without having to deal with this BULLSHIT.

    And your thing doesn't update itself, I installed haxe 4.1.5, it says 4.0,2, but in vsc its 4.2.5? What the fuck is this.

    opened by PortilizenHub 3
  • Add support for multi-texture frame collections

    Add support for multi-texture frame collections

    For the purposes of optimization, it would be useful to have the ability to initialize a character's animations by creating a frame collection which is able to pull from two or more spritesheets.

    For example, if you have some levels where a character needs some extra animations and other levels where these extra animations are not needed, you can place the primary animations in one Sparrow spritesheet and the secondary animations in an additional Sparrow spritesheet. Then the sprite would use the appropriate sprite and coordinates for the appropriate frame.

    This is one manner it may appear to people using the feature:

    var primaryFrameCollection:FlxAtlasFrames = FlxAtlasFrames.fromSparrow(primaryImage, primaryData);
    var finalFrameCollection:FlxAtlasFrames = primaryFrameCollection;
    if (needsSecondaryAnimations) {
      var secondaryFrameCollection = FlxAtlasFrames.fromSparrow(secondaryImage, secondaryData);
      finalFrameCollection= FlxAtlasFrames.concatenate([primaryFrameCollection, secondaryFrameCollection]);
    sprite.frames = finalFrameCollection;
    // Both of these should work.'animFromPrimaryCollection');'animFromSecondaryCollection');

    In this case, we are able to create a sprite that includes both sets of animations, without secondaryImage having to include the frames from primaryImage.

    New Feature 
    opened by MasterEric 6
  • HaxeFlixel windowed games doesn't play well with Windows Display Scale

    HaxeFlixel windowed games doesn't play well with Windows Display Scale

    I use a laptop with a smallish screen of 1920x1080 resolution. Windows provides a system setting, System -> Display -> Scale, which I set to 150% and this makes most apps and their text bigger so my eyes don't get strained reading tiny text. I don't fully understand everything this setting does, but I know it makes working on this laptop much more comfortable.

    But it creates a problem when I launch my HaxeFlixel projects, which request 1280x720 window size in Project.xml. The Windows setting is scaling the window by 150% so it creates a 1920x1080 game window. I think the game graphics are scaling too, so this would be fine, but the 1920x1080 game window takes my whole screen, and the window border with the minimize and close buttons, is pushed off the top of my screen and I actually can't click any buttons or even drag the window to make the buttons accessible.

    I don't know what exactly I want HaxeFlixel to do about this. Just ignoring the 150% scale setting doesn't seem quite right, although it would solve the problem as long as I implement my own resolution and scaling choices for players. Maybe at least, bumping the window lower so the border is visible and accessible on my screen, and the bottom of my game window is clipped instead, so I at least am not forced to Alt+F4 or Ctrl+Alt+Del? Or if I just knew a way to work around this problem myself without changing flixel, that would be great too.


    EDIT: This behavior is consistent on Neko, and goes away when I change display scale to 100%. I'm currently testing it with the cpp target to see if it's Neko-specific.

    opened by NQNStudios 1
  • change asset path args

    change asset path args

    fixes #2547

    AssetPaths has always been a clunky system, whenever people come to me with issues regarding it, I tell them just to delete it and use String paths.


    • Duplicate filenames break down the entire system. even when they are in different directories, or if one of them is excluded via Project.xml
    • Custom rename arg only takes the file name, and ignores the directory


    • Allow duplicate field names, warn the user and omit the duplicated field
    • Change filterExtensions to an include/exclude regular expression, allowing exclusion for any context.
    • Change custom renaming to take the entire filepath, not just name and extension
    opened by Geokureli 4
MAZE (My AmaZing Engine) - 🎮 Personal open-source cross-platform game engine

MAZE (My AmaZing Engine) is the self-written open-source cross-platform game engine in the active development stage. At the moment it is my main pet project, developed for the purpose of learning and preserving different game dev technologies.

Dmitriy Nosov 11 Jan 9, 2022
Improved version of the X-Ray Engine, the game engine used in the world-famous S.T.A.L.K.E.R. game series by GSC Game World.

OpenXRay OpenXRay is an improved version of the X-Ray Engine, the game engine used in the world-famous S.T.A.L.K.E.R. game series by GSC Game World. S

null 2k Jul 30, 2022
Powerful, mature open-source cross-platform game engine for Python and C++, developed by Disney and CMU

Panda3D Panda3D is a game engine, a framework for 3D rendering and game development for Python and C++ programs. Panda3D is open-source and free for a

Panda3D 3.4k Aug 3, 2022
Intrinsic is a Vulkan based cross-platform game and rendering engine

Intrinsic is a Vulkan based cross-platform game and rendering engine

Benjamin Wrensch 1k Jul 31, 2022
The Atomic Game Engine is a multi-platform 2D and 3D engine with a consistent API in C++, C#, JavaScript, and TypeScript

The Atomic Game Engine is a multi-platform 2D and 3D engine with a consistent API in C++, C#, JavaScript, and TypeScript

null 2.7k Aug 6, 2022
Open-source, cross-platform, C++ game engine for creating 2D/3D games.

GamePlay v3.0.0 GamePlay is an open-source, cross-platform, C++ game framework/engine for creating 2D/3D mobile and desktop games. Website Wiki API De

gameplay3d 3.7k Jul 31, 2022
KlayGE is a cross-platform open source game engine with plugin-based architecture.

KlayGE KlayGE is a cross-platform open source game engine with plugin-based architecture. It's started since 2003. The explicit goal of KlayGE is: to

Minmin Gong 1.8k Jul 27, 2022
A cross-platform 2D game engine

nCine nCine is a cross-platform 2D game engine. It is released under the MIT License, Copyright (c) 2011-2021 Angelo Theodorou. For additional informa

nCine 733 Jul 31, 2022
CSEngine is a cross-platform 3D game engine.

CSEngine - Cross Platform C++ Game Engine CSEngine is a cross-platform 3D game engine. ?? As it is under development, it is not yet suitable for pract

ounols 45 Jun 27, 2022
Godot Engine – Multi-platform 2D and 3D game engine

Godot Engine 2D and 3D cross-platform game engine Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unifie

Godot Engine 51.6k Aug 3, 2022
Flax Engine – multi-platform 3D game engine

Flax Engine – multi-platform 3D game engine

Flax Engine 3.4k Jul 31, 2022
CLUSEK-RT is a complex game engine written in C++ and the successor of the CLUSEK game engine

CLUSEK-RT is a complex game engine written in C++ and the successor of the CLUSEK game engine. This engine has been designed with a cross-platform design in mind. Thanks to Vulkan API it delivers a next-gen experience with ray tracing to both Linux and Windows platforms

Jakub Biliński 33 Jul 28, 2022
Ground Engine is an easy to use Game Engine for 3D Game Development written in C++

Ground Engine is an easy to use Game Engine Framework for 3D Game Development written in C++. It's currently under development and its creation will b

 PardCode 52 Jul 31, 2022
Free, open-source, game engine and a 3D sandbox.

Work-in-Progress The official "early alpha" release should be available around April 2021 SGEEngine SGEEngine is an open source (MIT License), C++ cen

ongamex 66 Jul 14, 2022
Free Heroes of Might and Magic II (fheroes2) is a recreation of HoMM2 game engine.

Free Heroes of Might and Magic II (fheroes2) is a recreation of HoMM2 game engine.

Ihar Hubchyk 1.4k Aug 4, 2022
Amazon Lumberyard is a free AAA game engine deeply integrated with AWS and Twitch – with full source.

Amazon Lumberyard Amazon Lumberyard is a free, AAA game engine that gives you the tools you need to create high quality games. Deeply integrated with

Amazon Web Services 1.9k Aug 4, 2022
SameBoy DX is a Qt-based interface of SameBoy, a free, highly accurate Game Boy and Game Boy Color emulator.

SameBoy DX SameBoy DX is a Qt-based interface of SameBoy, a free, highly accurate Game Boy and Game Boy Color emulator. Build requirements: CMake Pyth

Snowy 8 Jul 26, 2022
A fully-featured Falling-Sand game in the browser - Powered by WebAssembly

PLOP A fully-featured Falling-Sand game powered by WebAssembly! Try it out here Building Required Dev-Dependencies: clang uglifyjs $ git clone https:/

Caltrop 45 Jun 28, 2022
TrenchBroom is a modern cross-platform level editor for Quake-engine based games.

TrenchBroom is a modern cross-platform level editor for Quake-engine based games.

TrenchBroom 1.2k Aug 1, 2022