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.

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

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?

Unknowns

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

Todo

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

Commands

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.

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

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.
sprite.play('animFromPrimaryCollection');
sprite.play('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.

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.

Thanks!

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.

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.

Problems

• 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

Solutions

• 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