Group Details Private

administrators

  • RE: Standard Library not found by Vscode

    The folder containing the neko binary, as well as std.ndll (and other .ndll files). On Windows, that's a separate directory next to the Haxe directory (C:\HaxeToolkit\neko vs C:\HaxeToolkit\haxe), not sure what the directory structure would look like on a Mac.

    posted in Help!
  • RE: Standard Library not found by Vscode

    Is NEKOPATH set correctly? Seems relevant to that error message, according to what I linked earlier:

    NEKOPATH - path to the neko installation. I believe it's needed for loading standard .ndll files.

    posted in Help!
  • RE: Standard Library not found by Vscode

    Hm... flixel-tools calls haxelib, and it sounds like something is wrong with running the latter. What happens when you run haxelib list / haxelib path flixel?

    I don't think HAXE_PATH and NEKO_PATH are a thing btw - it's HAXEPATH and NEKOPATH (source).

    posted in Help!
  • RE: Something strange is happening compiling HelloWorld tutorial

    The ApplicationMain not found error happens when you haven't built for the selected target yet (see https://github.com/openfl/lime-vscode-extension/issues/44). As the warning says, it doesn't meant that completion won't work, just that it will be slower than it could be.

    I think the black screen when building through VSCode and the "invalid field access" error were since fixed in Lime by this commit. However, it hasn't made it into a release yet. So to avoid that, you could either downgrade to the previous Lime / OpenFL versions or update to a dev version of Lime. Adding this to your settings.json should work as a workaround as well:

    "haxe.enableCompilationServer": false
    
    posted in Help!
  • RE: Standard Library not found by Vscode

    Perhaps you need to set the HAXE_STD_PATH environment variable since you have it in a non-standard location. It should point to the std folder next to the Haxe binary.

    posted in Help!
  • RE: [VSCODE] Type not found : ApplicationMain

    This happens if you haven't compiled the game yet (for the currently selected target). See also https://github.com/openfl/lime-vscode-extension/issues/44.

    posted in Help!
  • RE: Way to change editor command when running from console?

    No, that's currently not possible (without modifying flixel-tools sources).

    posted in Help!
  • 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

    EDIT:
    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!

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