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
  • Serious floating-point artifacts on CPP FlxTilemap & FlxSprite

    Serious floating-point artifacts on CPP FlxTilemap & FlxSprite


    I made all transparent tiles in my tileMap bright green to highlight the issue. The boundaries of some tiles are showing pixel data from their adjacent neighbours.

    (1) This only occurs on some resolutions. Try lots of different resolutions. (2) This occurs infrequently; best way to "find" it is by moving slowly in x and y axis. Most likely some floating point issue.

    Using latest version from github.

    opened by cwkx 64
  • 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
  • Only able to run 41-42 frames on HaxeFlixel games.

    Only able to run 41-42 frames on HaxeFlixel games.

    After narrowing it down, some people in a server figured out it's an issue with HaxeFlixel. I am running Windows 11 with a 3050 ti (Laptop) and an 11th gen i7-11800h. Wondering if there's a fix

    opened by DevilishWeb3692 3
  • seriously, fix the FlxText Memory Leak when updating text

    seriously, fix the FlxText Memory Leak when updating text

    • Haxe version: 4.2.5
    • Flixel version: 5.1.0
    • OpenFL version: Latest
    • Lime version: Latest
    • Affected targets: All I'm pretty sure but windows for sure

    Code snippet reproducing the issue: make a flxtext and have it update a ton between different texts.

    Observed behavior: Memory Goes Really High. image

    Expected behavior: Memory Doesn't Go Extremely High

    opened by TheRealJake12 10
  • add linearDrag, maxLinearVelocity and drag modes

    add linearDrag, maxLinearVelocity and drag modes


    • FlxObject: added various physics fields
      • maxLinearVelocity: caps an object's velocity based on it's magnitude
      • linearDrag: applies a drag amount to an velocity's magnitude
      • dragMode: determines when drag.x/y is applied to velocity.x/y
      • linearDragMode: determines when linearDrag is applied to velocity
      • angularDragMode: determines when angularDrag is applied to angularVelocity
    • FlxDragMode: Enum for determining when drag is applied to velocity (used above)
    • FlxDragMode2D: Allows separate dragModes for different axes of a FlxPoint (used above)
    opened by Geokureli 1
  • Enable GLSL 3.00 migration

    Enable GLSL 3.00 migration

    Without modifying the fragment header and vertex source to replace deprecated keywords, specifying 300 es or higher as your GLSL version (possible with openfl/openfl#2577) will break. This pull request tells the ShaderMacro to perform this replacement.

    This change should be non-breaking even if it is merged before 2577, due to how annotations are read.

    opened by MasterEric 0
  • Windows Debug Error On __boot__.cpp

    Windows Debug Error On __boot__.cpp

    • Haxe version: 4.2.5
    • Flixel version: 5.0.1
    • OpenFL version: 9.2.0
    • Lime version: 8.0.0
    • Affected targets: Windows Debug

    image sorry I have no idea what causes it.

    Observed behavior: I get errors when compiling to debug and debug only. It works fine on release. Expected behavior: The Ability to compile to debug without error

    opened by TheRealJake12 1
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 13 Dec 14, 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 2.2k Jan 1, 2023
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.6k Dec 31, 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 Dec 29, 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.8k Dec 29, 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.9k Jan 8, 2023
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 Dec 23, 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 780 Dec 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 58 Dec 18, 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 56.7k Jan 9, 2023
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 48 Dec 29, 2022
Flax Engine – multi-platform 3D game engine

Flax Engine – multi-platform 3D game engine

Flax Engine 3.7k Jan 7, 2023
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 61 Dec 14, 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 72 Dec 7, 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.8k Dec 31, 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 Dec 26, 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 7 Oct 2, 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 46 Aug 9, 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.3k Jan 8, 2023