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
  • FlxSprite.draw(FlxCamera.canvas) does not render the Alpha channel

    FlxSprite.draw(FlxCamera.canvas) does not render the Alpha channel

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

    Code snippet reproducing the issue:

    import flixel.util.FlxColor;
    import openfl.display.Sprite;
    import openfl.display.BitmapData;
    import flixel.FlxG;
    import flixel.FlxSprite;
    import flixel.FlxCamera;
    import flixel.FlxState;
    class PlayState extends FlxState
    	inline private static var screenHeight:Int = 600;
    	inline private static var screenWidth:Int = 400;
    	var camMain:FlxCamera;
    	var camSource:FlxCamera;
    	var camSquares:FlxSpriteGroup;
    	var camMirror:FlxSprite;
    	var squareTime:Float = 0;
    	var squareSize:Int = 50;
    	override public function create()
    		camMain = new FlxCamera();
    		camSource = new FlxCamera(0, 0, screenWidth, screenHeight, 1);
    		camMain.bgColor.alpha = 0;
    		camSource.bgColor = FlxColor.GRAY;
  = false;
    		FlxG.cameras.add(camSource, false);
    		camMirror = new FlxSprite().makeGraphic(screenWidth, screenHeight, FlxColor.TRANSPARENT);
    		camMirror.cameras = [ camMain ];
    		var squareX:Float = (screenWidth - squareSize) / 2;
    		var squareY:Float = squareSize * 2;
    		for (index in 0...3)
    			var camSquare:FlxSprite = new FlxSprite(squareX, squareY + (index * squareSize * 2)).makeGraphic(squareSize, squareSize, FlxColor.RED);
    			camSquare.alpha = (index + 1) / 3;
    			camSquare.cameras = [ camSource ];
    	override public function update(elapsed:Float)
    		squareTime = (squareTime + (elapsed * 4)) % (Math.PI * 2);
    		camMirror.x += Math.sin(squareTime) * 10;
    		if (camMirror != null && camSource != null)
    			// i basically reinvent the wheel
    			var buffer:BitmapData = camSource.buffer;
    			var screen:FlxSprite = camSource.screen;
    			var canvas:Sprite = camSource.canvas;
    			var useBufferLocking:Bool = FlxG.cameras.useBufferLocking;
    			var renderBlit:Bool = FlxG.renderBlit;
    			var renderTile:Bool = FlxG.renderTile;
    			if (renderBlit)
    				if (useBufferLocking)
    				screen.dirty = true;
    			var mirrorPixels:BitmapData = camMirror.pixels;
    			mirrorPixels.fillRect(mirrorPixels.rect, FlxColor.TRANSPARENT);
    			switch (renderBlit)
    				case true:
    					mirrorPixels.copyPixels(buffer, buffer.rect, mirrorPixels.rect.topLeft);
    					mirrorPixels.draw(canvas, null, canvas.transform.colorTransform);
    			if (renderBlit)
    				if (useBufferLocking)
    			if (renderTile)
    				// Clearing camera's debug sprite
    				#if FLX_DEBUG;
    			if (renderBlit)
    				camSource.fill(camSource.bgColor, camSource.useBgAlphaBlending);
    				screen.dirty = true;
    			else { camSource.fill(camSource.bgColor.to24Bit(), camSource.useBgAlphaBlending, camSource.bgColor.alphaFloat); }

    Making a new Lime project and pasting this code into the PlayState will give the same results as seen below.

    I have been attempting to make an arcade machine for a game that I am currently developing, and as of right now, I've come up with the solution of copying an FlxCamera's pixels to an FlxSprite to mask it behind the arcade machine's body. With the code above, what I do is render the camera manually, and then draw the canvas (since renderBlit is disabled) to the sprite. The issue comes with this, as the alpha channel does not seem to be rendering. I cannot seem to find a workaround to this issue, as there seem to be no other properties or functions I can use to draw the canvas with the alpha channel.

    Observed behavior:

    Expected behavior:

    For reference, here are the two side-by-side:


    The one on the left is the FlxCamera itself, and the one in the center is the FlxSprite that has copied the pixels. This is an issue I cannot seem to bypass, or fix, unless I were to try using renderBlit. I'm also unsure if this is intended behavior or a bug.

    For context, here is the issue, but presented on the 'game' I have mentioned:

    The top-left is the camera, and the center is the sprite copying the camera's pixels. You can see that the static fades out on the camera, but not on the sprite. This is a hinderance to the effects that I want to add to this, seeing as it limits the ability to make sprites translucent. I will be grateful for any help on this issue.

    opened by Paracosm-Daemon 0
  • Added support for shaders in FlxStrip and FlxDrawTrianglesItem

    Added support for shaders in FlxStrip and FlxDrawTrianglesItem

    This pr adds support for shaders with the FlxStrip class. When I was working with the FlxStrip class I noticed that setting its shader property or alpha property did not have any effect on it, while it did work on regular FlxSprites. It looks like it's because FlxCamera.drawTriangles does not take in any parameters related to them, so I added those in this pr.

    Example code:

    import flixel.FlxG;
    import flixel.FlxSprite;
    import flixel.FlxState;
    import flixel.FlxStrip;
    import flixel.system.FlxAssets.FlxShader;
    import flixel.util.FlxColor;
    class PlayState extends FlxState
    	var shaderStrip:FlxStrip;
    	var alphaStrip:FlxStrip;
            var normalsprite:FlxSprite;
            var simpleShader:GreenShader;
    	override public function create()
    		shaderStrip = new FlxStrip(50, 50);
    		shaderStrip.makeGraphic(100, 100, FlxColor.YELLOW);
    		shaderStrip.vertices = DrawData.ofArray([100.0, 100.0, 150, 100, 125, 150]);
    		shaderStrip.indices = DrawData.ofArray([0, 1, 2]);
    		shaderStrip.uvtData = DrawData.ofArray([0, 0, 0, 1, 1, 1.0]);
    		shaderStrip.shader = new GreenShader();
                    alphaStrip = new FlxStrip(0, 0);
    		alphaStrip.makeGraphic(100, 100, FlxColor.RED);
    		alphaStrip.vertices = DrawData.ofArray([300.0, 100.0, 350, 100, 325, 150]);
    		alphaStrip.indices = DrawData.ofArray([0, 1, 2]);
    		alphaStrip.uvtData = DrawData.ofArray([0, 0, 0, 1, 1, 1.0]);
    		normalsprite = new FlxSprite(0, 0).makeGraphic(100, 100, FlxColor.BLUE);
    		normalsprite.shader = new GreenShader();
    	override function update(elapsed:Float)
    			alphaStrip.alpha -= 0.01;
    			alphaStrip.alpha += 0.01;
    class GreenShader extends FlxShader
    	#pragma header
    	void main()
    		vec4 clr = texture2D(bitmap, openfl_TextureCoordv);
    		gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0) * clr.a;
    	public function new()

    When I tested this on windows and html5 it worked

    opened by UncertainProd 3
  • Add FlxSprite.graphicWidth and graphicHeight

    Add FlxSprite.graphicWidth and graphicHeight

    At the current moment, I've gotten the getter for the new width for a sprite done. But there's 3 things I'd like you all to keep in mind.

    1. I'm not the best coder at Haxe, but I'm still learning though.
    2. I just wanted to help with an issue via PR, I'm trying to be a better & helpful person. (I don't honestly know if I have what it takes to be professional)
    3. I don't know if WIP PRs are allowed, and I don't know if it was ever stated somewhere, and I'd had overlooked it.

    I haven't tested this either since it's on another branch, and I don't know if haxelib can install from other branches. But I did also allow edits by maintainers in case you want to fix my shitty mistakes.

    This should close this issue:

    opened by MemeHoovy 2
  • add sprite.graphicWidth and graphicHeight getters, stop calling updateHitbox on setGraphicSize()

    add sprite.graphicWidth and graphicHeight getters, stop calling updateHitbox on setGraphicSize()

    no reason to change the hitbox in setGraphicSize other than to have a handy getter for the new graphic width. maybe add new helpers that scale the graphic and hitbox, too

    opened by Geokureli 0
  • Improve debug selection tool

    Improve debug selection tool

    As discussed in #2662 we should improve the selection tool:

    • Clicking should always select the most top-drawn object overlapping the cursor.
    • Shift-click to toggle the selection of the top-most object Additionally, it would be a good idea to have a button to toggle ignoreDrawDebug on the selected object(s)

    Pinging @ACrazyTown, if you don't end up getting to this, let me know

    Improvement New Feature 
    opened by Geokureli 2
  • Discrepancy between mouse scroll values on Windows and HTML5

    Discrepancy between mouse scroll values on Windows and HTML5

    • Haxe version: 4.2.5
    • Flixel version: 4.11.0
    • OpenFL version: 9.2.0
    • Lime version: 8.0.0
    • Affected targets: HTML5 (At least HTML5; I can't check many others)

    Code snippet reproducing the issue:

    import flixel.FlxState;
    import flixel.FlxG;
    class PlayState extends FlxState
    	override public function update(elapsed:Float):Void
    		if (FlxG.mouse.wheel != 0)

    Observed behavior: On Windows, the value of FlxG.mouse.wheel after the mouse wheel is scrolled one notch is +-1. On HTML5, it's +-625. Expected behavior: The value of FlxG.mouse.wheel should be the same on every target.

    opened by DalekCraft2 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 Nov 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 2.2k Nov 22, 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.6k Nov 28, 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 Nov 18, 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 Nov 24, 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 Nov 24, 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 Nov 24, 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 768 Nov 26, 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 53 Nov 11, 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 55.4k Nov 25, 2022
Flax Engine – multi-platform 3D game engine

Flax Engine – multi-platform 3D game engine

Flax Engine 3.7k Nov 27, 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 37 Oct 7, 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 61 Nov 26, 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 73 Nov 3, 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.6k Nov 29, 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 Nov 21, 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 Nov 21, 2022