Group Details Private


  • RE: Issues with loading tilemaps

    The second set of errors comes from using a Flixel version that's incompatible with Lime 7. Try updating to Flixel 4.5.0.

    posted in Help!
  • RE: Console ports?

    Yo! I'm Lars, the guy who maintains the various lime/OpenFL console backends, which in turn power HaxeFlixel on consoles. I've already ported and shipped my game Defender's Quest on PS4, PSVita, XBox One. We also have a Nintendo Switch backend for lime/OpenFL (and thus HaxeFlixel) that has been approved by Nintendo, you can sign up for it from the official Nintendo Switch middleware site on the developer backend.

    However, my past experiences with "cross platform" tools has me a little more pessimistic.

    Heh, honestly this isn't a bad attitude to have. Since you asked, I'll explain in detail.

    The Switch backend is the nicest one we have right now. It is based on modern OpenFL (version 8), but temporarily frozen on a fork that's a few months old, just so stuff isn't moving around. Most people who have games that are running on HaxeFlixel on PC right now, are able to get their stuff up and running on Switch in a few hours at most. Also, there's no crazy special backend or anything, because we're able to use both OpenGL and SDL on the Switch, which we can't do on the other consoles. So it's a very similar platform to the desktop targets.

    In theory, all you're doing is connecting the HXCPP target to a new platform. All the major console platforms have C++ api's, so there's not any particular magic sauce here, from a technical perspective.

    The PS4, PSVita, and XB1 backends are based on a custom backend that licenses WayForward's proprietary in-house engine. We're going to release that tech freely in the near future, but there's still quite a bit of cleanup to do so it's very "DIY" for anyone who wants to use it right now. It supports most of the features anyone could want, but the initial setup is a decently big hurdle, just making sure you have the right version of all the libraries and everything. It's not insurmountable (and I hope to make it better in the coming months) but it's intimidating for users who aren't used to say, recompiling lime from source. The reason these have a different backend is each platform requires its own entirely unique rendering solution, and so we just piggybacked off of WayForward's existing solution.

    Tech wise, the Switch backend supports the most of modern OpenFL and HaxeFlixel, and the PS4/XB1/PSVita backend is frozen on OpenFL3 for now (though both work with current HaxeFlixel). If you use fancy features like shaders those will almost certainly work on the Switch backend but probably need some custom handling on the PS4/XB1/PSVita backend. Everything else just works, more or less.

    Each platform has native API's you need to hook in to to do specific stuff, these aren't too hard to expose, you just need to write a C++ bridge for whatever you need. It's tedious sometimes but not impossibly hard, and I've already done the trickiest ones. You do want to be careful you don't accidentally leak memory when you do this for stuff you call frequently.

    But all that aside, none of this really captures all the lovely hidden "gotchas" of console development. Honestly? The tech side is the easy part.

    The really annoying part is all the paperwork, obscure technical requirements, and endless delays you have to contend with. Each platform has a long list of certification requirements you have to comply with before they'll let you ship and they're extremely detail oriented.

    Performance varies -- obviously the PSVita is the weakest platform and you'll probably have to really optimize your app. I wrote a whole article just about that.

    PS4 and XB1 were mostly fine, but I had to content with some of their platform specific stuff. Like each console has its own way of doing things like saving and achievements, and sometimes the way they're implemented make things harder than they need to be, and assumptions you made in a Desktop world might not work on consoles and you have to rip out and rewrite that code -- like on PC's you have free reign over the filesystem more or less, on consoles you're much more constrained. Also if you're doing multiplayer be prepared for some huge headaches and even more technical requirements.

    On a positive note, input was really easy to deal with. Once we hooked the low level stuff into Lime and OpenFL, the input abstractions worked pretty great, and the Flixel gamepad stuff was very nice. I personally use my FlxActions API layered on top of that, which is super nice IMHO, and I should really get around to getting that merged up.

    Back to annoyances, one really big gotcha is title safe regions --- TV's often have overscan, but computer monitors typically don't, so PC games are often designed to have UI go right to the edge of the screen. Well, after you've gone and made a game that baked all those assumptions in, you find that on consoles you have to deal with overscan or you can't ship. Either you have to keep all non essential text within 10% of the borders (which can be a pain if you have a complex UI that's not easily changed), or you can make use of a "title safe sizer" ( that little display that says "move the sticks to scale the display until all four arrows in the corners are visible ) to get you a safe visible area and make sure you draw within that. Some consoles provide their own system level title safe sizer, so you just have to conform to a given rectangle, and others require you to implement one entirely yourself. As for conforming to the rectangle, on some consoles the system takes care of rendering at a smaller resolution with black borders (ie, the upper left of your rendering space is 0,0, and you just set a window size and forget about it afterwards), and on others you have to implement that yourself (ie, if you need to cut in by 10%, you just need to offset your render area and window yourself).

    You have to be careful with specific platform terminology and trademarks, and if you're localized, every single scrap of text has to be translated to that locale, and you have to use the official localized versions of specific terminology.

    Also, when you go through certification you don't always get prompt feedback, and there can be a lot of delays trying to get into the next certification cycle. Requirements are also easy to misunderstand and then you have to go through all over again.

    So that's my story. TL:DR --

    1. Initial setup is not as convenient as I would like it to be, Nintendo Switch is probably the easiest right now
    2. Most stuff works pretty well, tech wise
    3. Native system API calls have to be exposed via C++ now and then
    4. Technical certification + paperwork + delays + hidden requirements = absolutely no fun
    5. Depending on platform you might have to optimize some stuff
    6. You're not allowed to talk openly about a specific platform's specific details which is incredibly frustrating and makes it hard to solve problems when you get stuck

    Oh, getting ratings is a pain, too. Some of the platforms have moved to IARC, which makes things easier/cheaper, but some still require you to go to PEGI, ESRB, and also all the tiny ones for individual countries like Australia, New Zealand, Brazil, etc... That can be a huge pain and also expensive.

    posted in General Discussion
  • RE: Android performance with Haxeflixel 4.4.0

    @agustín-pérez-fernández Could you try to disable vsync in your Project.xml?

    posted in Help!
  • RE: HaxeFlixel coding Language

    @antwgames It does limit them to HTML5. Also, HaxeFlixel has no explicit support for this / no TS type definitions, so this is only really an option with pure OpenFL.

    posted in General Discussion
  • RE: XCode error when exporting to ios

    I don't have any experience with iOS / XCode myself, but this sort of question usually gets better results in the OpenFL forums, since this is not HaxeFlixel-specific.

    posted in Help!
  • RE: Android performance with Haxeflixel 4.4.0

    @rafadelahoz You could try disabling particular "features" (text rendering, large sprites, etc) to try and isolate what exactly is making it slow. Not aware of anything in particular that would be slower with new OpenFL 8 right now.

    posted in Help!
  • RE: Android performance with Haxeflixel 4.4.0

    I'd be curious to know what results you're getting with the Tilemap branch:

    It's rather experimental / unstable, but it uses a different renderer (Tilemap instead of drawQuads), so there's a chance you'd see an improvement.

    posted in Help!
  • RE: [solved] "Unexpected for" bug?

    @blaise_rascal Yes, what he meant is that for loops are not allowed after a class name / directly in the class body. They must be inside a function.

    posted in Help!
  • RE: Android performance with Haxeflixel 4.4.0

    What OpenFL / Lime versions are you using? If not latest, could you try updating?

    posted in Help!
  • RE: HaxeFlixel coding Language

    @sascha-west said in HaxeFlixel coding Language:

    If I use HaxeFlixel can I use Javascript?

    No, you will have to use Haxe (

    posted in General Discussion

Looks like your connection to HaxeFlixel was lost, please wait while we try to reconnect.