Using the OpenFL/Haxeflixel API on a commandline tool?
I want to make a commandline tool that stores my assets in a small custom database. I'm using:
- haxe -main MyClass -neko myclass.n
and then i run it with:
- neko myclass.n
this environment is not very accommodating though. I cant do anything with the haxeflixel/openfl packages. I have tried adding: --macro allowPackage('flash') to the compiler. Then it will compile - if you use the flash.* imports - but it will have runtime problems: "Uncaught exception - Invalid field access : new"
Im guessing that this is because a lower level framework is not loaded and new then can't run proper.
In sort I want to open a bunch of PNG files and save them in a small database. I can load PNG's with sys.io.* but i cannot translate them to BitmapData.
As a workaround I can off-course just store the PNG in the database and then use normal API on (regular-game) runtime to translate them. Still i would like to know if there is a way to do this in advanced with a commandline (neko) interface... So there perhaps any way to use the haxeflixel/openfl api on the neko/cli interface?
Thanks in advanced for helping!
Access to the flash package is not allowed on other platforms for a reason - without a library like OpenFL, there is no actual implementation of the Flash API. Have you tried simply including OpenFL / Flixel with
-lib flixel -lib openfl -lib lime
Not sure if all functionality is accessible that way, but it should work for at least some things. I'm able to create and trace a
BitmapDatainstance that way for instance.
You might also want to have a look at tdrpg-tools, a set of random tools Lars has written for Defender's Quest. Some of them are CLI applications that make use of OpenFL APIs, like SpriteSheet or ImageProcess, so this should definitely be possible. Be aware that not all of those tools are up to date though and might not compile with current Haxe / OpenFL versions.
@Gama11 :: Thanks for the tips. I just played around with it and it seems to be fitting my needs. I only need a subset, not the whole framework. On my first tests adding the libraries seem to hold-up.
I'm coding a asset solution now because I don't like them sitting in the application 'naked'. I was wondering how other people arrange this. Or better yet, what do you recommend for this?
It does not have to be totally unhackable (if that even exists), but I don't fancy the other extreme either. I was almost finished with a solution for this but then when i tested it on Android I became sad. Reading a file with sys.io.* not working that well. Which caught me off guard.!
My last technical question for my asset part is how to best read from files. (dont need to write them) on most common compiled platforms? (Android, IOS, MacOSX and Windows).
Thanks alot for your reply and I bid you well,
sys.ioshould work fine generally, on Android it might be a bit problematic because I believe the
.apkfile is not actually unpacked, so you couldn't read from the assets directory, for instance. There's also permissions to watch out for.
What exactly are you're trying to achieve? There's the option of compiling assets into the exectuable with the
<assets path="assets" embed="true" />
I could not just open files on Android. It seem to only want to open the files that are indexed in the manifest. loadGraphic works fine on Android.. but no matter what I've tried I could not get something like: sys.io.File.getContent(/* some_path */); to work on Android. Yet it worked fine on Windows (Neko & CPP). Yet this works on all platforms: openfl.Assets.getText(/* same_path */); ( Except on Neko cli :)
I did notice in the documentation that getText(id:String):String refers to the input string as ID and not as PATH. So it is most likely doing other stuff then just opening a file and outputting it.
Quote: "I believe the .apk file is not actually unpacked, so you couldn't read from the assets directory, for instance."
This would explain alot. But the assets do get copied to the android template. Are they then also embedded.? That would explain why the higher API calls work and the low-level file system ones don't.
Embedding seems like a good idea. Atleast for the Graphics. (can it embed audio?). The only thing I might not like about embedding is that if it all gets in the same binary, it might get bit. Especially if you have lots of audio. The biggest disadvantage of that is that if you start your game/app then the initial loading time can be a pain.
But perhaps there is some nifty way of loading the game. I'm just on HaxeFlixel for 3 weeks now, so there's still lots to figure out.
Quote: "What exactly are you're trying to achieve?"
Inshort, I just don't want everybody to be able to just manipulate the look and feel of the game. Thats all. Embedding is already a viable option.!
For now I will read up on embedding for HaxeFlixel. For now I don't want to be too busy with this. Better wait until the game is more mature. Writing my own asset facility will probably make me break decency with everything that's not support #if sys ...
Thanks again for helping me out!
For now I will let this rest a bit.