OpenFL -Dnext building fails because ByteArray.hx can't find cpp.NativeArray

Hello,

I just ran haxelib upgrade and ended up with these:

  • openfl 3.0.3
  • lime 2.3.3
  • nme 5.3.1
  • hxcpp 2.3.81

When I try to build my project or PiratePig for Mac, it fails with this error:
/usr/lib/haxe/lib/lime/2,3,3/lime/utils/ByteArray.hx:24: characters 7-22 : Class not found : cpp.NativeArray

I ran openfl display mac and saw the argument -Dnext, so I tried building with -Dlegacy and that worked. So it’s a problem with OpenFL next.

I had that same error when trying to build my project for Android, so it seems to be across different platforms. Building for Android with -Dlegacy isn’t working yet, but I think it’s unrelated (I think it’s something specific to my Android setup that was off).

I couldn’t find any other reports of similar issue, so maybe something in general in my setup is wrong?

try upgrading haxe, call “haxelib selfupdate”

That will only update haxelib, not haxe.

@cactusanctuary It seems your hxcpp version is old, try updating it, cpp.NativeArray was probably introduced in a latter version.

Indeed my version of hxcpp was a little old, I don’t know why haxelib didn’t catch update it when I ran upgrade over the weekend.

Anyway, I’ve updated hxcpp and there’s no change. It’s still complaining that it can’t find cpp.NativeArray.

I tried using haxelib to remove hxcpp and then install it again, but no luck.

Sounds like an issue with your Haxe install

I did a clean install this evening, but it still doesn’t work.

When I ran haxelib selfupdate I consistently get this:
Haxelib was already up to date... Error compiling haxelib client: /usr/lib/haxe/lib/haxelib_client/3,2,0-rc,3/src/tools/haxelib/SemVer.hx:52: characters 7-17 : Not enough arguments /usr/lib/haxe/lib/haxelib_client/3,2,0-rc,3/src/tools/haxelib/SemVer.hx:52: characters 7-17 : Function 'get_data' requires arguments : this

Anything to do with it?

No, that just looks like a broken haxelib install :frowning:

I reinstalled Haxe from here: http://haxe.org/download/

And I get another problem when building on -Dnext:
Export/mac64/cpp/haxe/ApplicationMain.hx:17: characters 2-30 : themission.Main should be lime.app.Application Export/mac64/cpp/haxe/ApplicationMain.hx:21: characters 2-41 : themission.Preloader should be lime.app.Preloader

It was complaining about my Main and Preloader classes. I tried creating and testing PiratePig, and it works fine!

My Main extends Sprite, and my Preloader extends NMEPreloader. I tried removing my preloader from the project.xml, but compiler still complains about Main.

Any ideas?

Make sure you include <haxelib name="openfl" /> but not <haxelib name="lime" /> if you want to build for OpenFL with the OpenFL templates, otherwise it boots using Lime, and expects your Main class to be compatible with Lime (which allows you to exert further control over an OpenFL project by starting at a lower-level)

OK it compiles! I had indeed added the lime haxelib in order to make autocompletion work properly for SublimeText. So if I remove <haxelib name="lime" /> and <set name="openfl-legacy" /> then my game compiles.

But many things are broken in the game now:

  1. Not using my font.
  2. Data from shared object is not restored.
  3. Input doesn’t work anymore (I built a custom layer which uses KeyboardEvent and JoystickEvent).
  4. Forces full screen even if I turn it off in the project.xml, and my in-game setting is to window instead of full screen.
  5. My project.xml setting of FPS to 30 is ignored.
  6. Logic which center and letterboxes the game isn’t working anymore.

So I’m thinking of sticking to the -Dlegacy. 1, 2, 3 and 6 I can probably fix, but 4 and 5 seem really strange that they don’t work anymore.

Okay…

1.) What kind of font is it? Do you use Assets.getFont, or hard-code the name? Or does it use @:font?
2.) Yeah, we need to look at SharedObject
3.) JoystickEvent is being deprecated, we need to implement Gamepad events in OpenFL (otherwise Lime gamepad events are available, and better than JoystickEvent)
4.) Hmm, I’ve never seen something force full-screen. Does it do that if you use a sample? And what target you using?
5.) That’s known, Lime hard-codes 60 FPS ATM, but I think we can make changes to allow different frame-rates as well
6.) That’s something we could look into, do you do this yourself, or rely on the OpenFL logic for this?

  1. It’s a TTF, and I use Assets.getFont. It’s embedded via the assets element in the project.xml.
  2. So SharedObject isn’t working properly yet?
  3. When would JoystickEvent be deprecated? I haven’t checked out Lime Gamepad yet, but I do have the issue that connected gamepad ID’s get scrambled each time the game starts up again (JoystickEvent.device). In my system, the events are being dispatched properly and the codes I gave it are consistent with -Dlegacy, so probably the events aren’t being listened for, or not propagating all the way, as expected.
  4. It was forcing full screen because it couldn’t read the value from my SharedObject, so by default it would go full screen :3
  5. Looking forward to when the window element’s FPS attribute is applied again!
  6. The centering + letterboxing logic is something I made as well, so I would have to look into it. Is there some OpenFL logic that does it as well?

In any case, I’m aiming for release very soon, and I have tons to do before then. So I’ll stick to -Dlegacy for now, if there isn’t some crucial reason to look into the issues I have when using -Dnext.

Totally understand! That’s why -Dlegacy is here. It’s great to get this feedback so we can continue to help mature the newer code path.

The new gamepad API supports proper gamepad events, connect/disconnect, axes, buttons, etc. It’s definitely better than the joystick API. Since they added Gamepad APIs later in Flash Player, I think we should look at implementing those in OpenFL, receiving the events we are dispatching now from Lime to power it.

We could implement a compatibility mode for JoystickEvent, but I think it would be wiser to try and avoid custom (non-Flash) classes in OpenFL, and to either allow use of Lime APIs below, or to implement the Flash sugar in the OpenFL layer

Using Assets.getFont ("font.ttf").fontName? Does it work in the “AddingText” sample, if you use the font alone?

Interesting about the Lime gamepad, I didn’t look into it way back when I was making my custom input layer. Definitely it would be nice to have some gamepad-related class in OpenFL, but I’m not sure of the way you would prefer to do it – just modify the functionality that dispatches JoystickEvent in order to maintain existing implementations built on those, or remove JoystickEvent and replace it with an API largely similar to Lime’s?

About the text, it’s very odd. I tried the AddingText sample, and that works fine with its own font, as well as mine when copied over. It works when entering the font name manually, as well as when using the Assets.getFont().fontName. It looks like I’m doing font-related stuff consistently with the AddingText sample, so I’m not sure what the problem is.

What about the shared objects, that’s a known issue? Will it be fixed soonish?

I was thinking we should do this: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ui/GameInput.html

SharedObject is here:

Looks like we need to copy some code from here:

https://github.com/openfl/openfl/blob/master/openfl/_legacy/net/SharedObject.hx

Flash’s GameInput and related classes API looks quite nice! How far off is its implementation?

I looked at the next SharedObject.flush() vs legacy SharedObject.flush() to compare, and indeed the new one doesn’t do anything for non-HTML5 targets :frowning: Was the idea to rework the code instead of just copying it over?

I’m asking too many questions out of curiosity now :stuck_out_tongue: Let me know if I can help by testing stuff out!

For desktop, the old SharedObject code is all written in Haxe, so that should be practically a copy-paste job, with testing.

For mobile, we do have the ability to get the preferences path from the Lime System class, we can probably use that to try and get the equivalent functionality going there

No one has tried to write the GameInput class, but I’m guessing the Lime Gamepad API provides all the information we need to implement it

I can look into copying over the SharedObject code specific for desktop. If it works for me on Mac then I’ll make a pull request. Are you guys set up with unit tests?

I’d love to contribute with controller-related stuff. I do have my hands full these days, so I can’t make any commitment. Maybe after I release my game!

Thanks, really appreciate your help!