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

The current style guide may be found here: http://haxeflixel.com/documentation/code-style/

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.

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.

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 https://github.com/Gama11/flixel draw-quads-2
• install openfl dev via haxelib git openfl https://github.com/openfl/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]

Limitations

• 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!

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: https://github.com/openfl/openfl-samples/blob/master/demos/BunnyMark/Source/Main.hx

• 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: http://i.giphy.com/3oriOchXffaK7OSD1m.gif

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: http://i.giphy.com/l2Jht0pruoqifEX8Q.gif

Expected behavior:

The game should not freeze

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.

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

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.

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):

And here is the native result (neko build):

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

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

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):

Reproducal:

1. Get the latest standalone Flash player/plugin (11.8+, as this will not appear on older versions).
2. Run this SWF: https://github.com/sruloart/FlxBackdrop-Bug/blob/master/GameTest/export/flash/bin/GameTest.swf?raw=true. You'll notice the "Stuckness" bug by looking at the line / changing gradient.
3. Goto this repository: https://github.com/sruloart/FlxBackdrop-Bug
4. Enable the line that disable the GamePad on Flash (Project.xml).
5. Bug's gone.
6. What's going on here?

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

https://github.com/starry-abyss/hf-multicamera

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

• 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:

package;

import flixel.group.FlxSpriteGroup;
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;

		camSource.active = false;

		FlxG.cameras.reset(camMain);
		FlxG.cameras.add(camSource, false);

		camMirror = new FlxSprite().makeGraphic(screenWidth, screenHeight, FlxColor.TRANSPARENT);
		camMirror.cameras = [ camMain ];

		camMirror.screenCenter();
		add(camMirror);

		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 ];

			add(camSquare);
		}
		super.create();
	}
	override public function update(elapsed:Float)
	{
		squareTime = (squareTime + (elapsed * 4)) % (Math.PI * 2);

		camMirror.screenCenter();
		camMirror.x += Math.sin(squareTime) * 10;

		@:privateAccess
		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;

			camSource.render();
			camSource.update(elapsed);

			camSource.drawFX();
			if (renderBlit)
			{
				if (useBufferLocking)
					buffer.unlock();
				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);
				default:
					mirrorPixels.draw(canvas, null, canvas.transform.colorTransform);
			}
			if (renderBlit)
			{
				camSource.checkResize();
				if (useBufferLocking)
					buffer.lock();
			}
			if (renderTile)
			{
				camSource.clearDrawStack();
				canvas.graphics.clear();
				// Clearing camera's debug sprite
				#if FLX_DEBUG
				camSource.debugLayer.graphics.clear();
				#end
			}
			if (renderBlit)
			{
				camSource.fill(camSource.bgColor, camSource.useBgAlphaBlending);
				screen.dirty = true;
			}
			else { camSource.fill(camSource.bgColor.to24Bit(), camSource.useBgAlphaBlending, camSource.bgColor.alphaFloat); }
		}
		super.update(elapsed);
	}
}

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:

https://user-images.githubusercontent.com/98495978/202837813-b08ec8f3-7187-4be2-92f5-8a6241f11f76.mp4

Expected behavior:

https://user-images.githubusercontent.com/98495978/202837809-daf29dbb-f73e-46db-b311-58a5ce175092.mp4

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:

https://user-images.githubusercontent.com/98495978/202837949-a0c0eec6-dd44-4563-8ade-cbb1deabe193.mp4

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.

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:

package;

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.FlxState;
import flixel.FlxStrip;
import flixel.graphics.tile.FlxDrawTrianglesItem.DrawData;
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()
	{
		super.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();
		add(shaderStrip);

                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]);
		add(alphaStrip);

		normalsprite = new FlxSprite(0, 0).makeGraphic(100, 100, FlxColor.BLUE);
		normalsprite.shader = new GreenShader();
		add(normalsprite);
	}

	override function update(elapsed:Float)
	{
		if(FlxG.keys.pressed.A)
		{
			alphaStrip.alpha -= 0.01;
		}
		if(FlxG.keys.pressed.D)
		{
			alphaStrip.alpha += 0.01;
		}
		super.update(elapsed);
	}
}

class GreenShader extends FlxShader
{
	@glFragmentSource('
	#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()
	{
		super();
	}
}

When I tested this on windows and html5 it worked

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: https://github.com/HaxeFlixel/flixel/issues/2667

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 https://github.com/HaxeFlixel/flixel-docs/issues/258

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

• 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:

package;

import flixel.FlxState;
import flixel.FlxG;

class PlayState extends FlxState
{
	override public function update(elapsed:Float):Void
	{
		super.update(elapsed);
		if (FlxG.mouse.wheel != 0)
		{
			trace(FlxG.mouse.wheel);
		}
	}
}

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.