I wrote an OpenFL Flump parser (similar to the one in Flambe) for use in a past project and it seems to work pretty well. What’s the best way to contribute it to the code base, and where?
Set it up as a separate project, then submit it to Haxelib. (Pretty sure this is done via haxelib submit, though I’ve never done it myself.)
And please don’t forget to upload the project to Github: makes it easy to find, fork and contribute…
I find it really strange that there does not seem to be any official docs on how to submit your own haxelib. This should really be a sub-topic in the haxelib section of the Haxe Manual ( http://haxe.org/manual/haxelib.html ).
This guide seems good, but can someone confirm if it still holds up with latest haxe/haxelib etc.
Yep, those instructions look good.
Obviously, if it was something that you think should be core (part of the command-line tools?) or another library (like the “spritesheet” library?) then that’s cool – otherwise releasing separately provides a way to get in people’s hands immediately, and for it to improve over time! 
Ok great, I just have one question, since I’ve never submitted anything to haxelib before.
Is it better to make the submission root directory of my project the bare essential .hx files? For example, those are in com/michaelgreenhut/openflump, so should I make it there? Or should I create a full example project in FlashDevelop with that as one of my subdirectories, and make the example project’s root folder my submission root?
Personally, I like making the root of a haxelib the same as the root of my repository. It makes it simple to “git clone” then “haxelib dev openfl openfl”, etc, rather than “haxelib dev munit munit/src” and other things that can be confusing to someone who is not familiar with the structure.
Haxelib adds the root as a classpath by default. You’ll see how this leads to /openfl/display/Sprite.hx (etc) in the repositories. Haxe will ignore classpaths that are either mismatched with the “package” at the top of the tile, or that start with “_” in the folder name, so if you use “tests/mytest/Main.hx” that will be hidden from code-completion.
A little “trick” though, is that FlashDevelop does not ignore subdirectory paths (in older releases, might be fixed in dev) unless there is a “haxelib.xml” (left over from the older Haxelib 1 format), so that’s why Lime and OpenFL have dummy “haxelib.xml” files, to improve completion and hide our test, sample, etc directories.
If you’re interested, OpenFL supports “include.xml” files within haxelib directories, which enables the ability to add some project tags, including (Lime and OpenFL both define this) a tag for specifying a directory path for use with “openfl create”, so you could do “openfl create flump TestProject” or whatever, if you’re interested
Cool, a lot to review there. I actually submitted it to haxelib as “openflump”, though I had to remove the src/ container folder to get it working (that haxelib install example confused me a bit with one of the images of that root folder).
Hi, any plans to port flump to haxe Starling?
Holy necro, it’s been years since I worked on this. Does anyone use Flump anymore? The 2DKit guys have something called FlaExporter that supposedly works a little better, though it’s not without its bugs and they’ve closed up their source and make you pay for it.
I’ve been doing more Unity and Phaser stuff than Haxe these days (except for one zombie client project done in Flambe/2dkit that refuses to End or go away), but if Flump is still alive and there’s enough demand I would consider dusting it off and continuing it.
2 Likes
Having a working flump player from c++, if possible, would be great.
I have some cases where it would be incredibly useful.
I’ve started porting to Haxe OpenFL. Thinking to get rid of react-as3 dependency.
1 Like
I’ve already managed to do a working port. However it’s dirty right now. Need some time to optimize and clean up code.
Also still thinking, whether to keep Future stuff or replace it with starling event system
http://188.166.108.195/flump/
1 Like
Can this be used in OpenFL?
Nope. It is Starling dependant.
I am not sure that it is needed for pure OpenFL. I hope, they’ll improve SWF lib with single batching with tilemaps and multiple scaling.
But currenlty you can try this:
But it is old, and doesn’t support single batch (no tilemaps). I didn’t test it
Didn’t test it much yet.
Requires refactoring, code cleanup and may be optimizations
Added to haxelib
@rainy are you familiar with flump? May be you can extend it and split to 2 renderers (pure openfl and starling openfl)? If you are busy, I’ll try to find some time to make a pure openfl version
3 Likes
It would probably be able to work with Tilemap
I’m not familiar with Flump, and currently I don’t need Flump for my job. If possible, I want to optimize the rendering performance of SWF.
Yeah, but need to find time to implement. Also, what would be better solution to handle multiple altases? Create multiple tilemaps?