Good afternoon, thank you very much for your response. It’s very motivating.
@Matse
I have always used haxelib to download and install libraries. I really didn’t expect so many people to directly use GitHub to install libraries
You can use Haxelib to install libraries from GitHub, too 
1 Like
@Bink I don’t have any number : I guess a good part of people still using AIR (and paying for it) are doing mobile apps, which often require ANE(s) and most are gonna be from distriqt
If for any reason distriqt stopped maintaining those ANEs… I feel like it would be a big nail in the coffin for AIR
I miss the lively community too…
@785597448 haxelib install someLibName is absolutely fine, I’m still using that a lot. When I want to participate with a lib though I need to fork it on github and either use haxelib git or haxelib dev
1 Like
Hello developer, I personally think the API method for adding animations in “creatjs” is very convenient. Has “starling” considered adding this API by referring to the creatjs API? Just say a few words ..
- for a single frame animation, you can simply specify the frame index
animations: {
sit: 7
}
- for an animation of consecutive frames, you can use an array with two required, and two optional entries in the order:
start,end,next, andspeed. This will play the frames from start to end inclusive.
animations: {
// start, end, next*, speed*
run: [0, 8],
jump: [9, 12, "run", 2]
}
- for non-consecutive frames, you can use an object with a
framesproperty defining an array of frame indexes to play in order. The object can also specifynextandspeedproperties.
animations: {
walk: {
frames: [1,2,3,3,2,1]
},
shoot: {
frames: [1,4,5,6],
next: "walk",
speed: 0.5
}
}
To define a simple sprite sheet, with a single image “sprites.jpg” arranged in a regular 50x50 grid with three animations: “stand” showing the first frame, “run” looping frame 1-5 inclusive, and “jump” playing frame 6-8 and sequencing back to run.
var data = {
images: ["sprites.jpg"],
frames: {width:50, height:50},
animations: {
stand:0,
run:[1,5],
jump:[6,8,"run"]
}
};
var spriteSheet = new createjs.SpriteSheet(data);
var animation = new createjs.Sprite(spriteSheet, "run");
I personally think that the API method for adding animations in ‘creatjs’ is very convenient,
Has Starling considered adding this API as a reference? Just say a few words ..
In CreatiJS, whether it’s Movieclip or Sprite, I think both animations are much more flexible in animation control APIs than Movieclip in Starling. Don’t misunderstand, I just want to provide inspiration for this ..
Here in the OpenFL community, is probably not the best place to ask for new features for Starling, as Starling for Haxe is a port of Starling for ActionScript 3.0.
That is, Starling for ActionScript 3.0 is likely where the key development occurs, and is then ported to Starling for Haxe.
That said, I’m not sure you’ll get much traction asking for one framework, to be more like another framework, particularly if it means adding additional ways of accomplishing something it’s already capable of, creating framework bloat and confusion.
There are three more likely options you might pursue:
- Simply use the other framework (EaselJS).
- Port the other framework to Haxe. There is this library in Haxelib: easeljs. I can’t vouch for what it can do though.
- Get comfortable with Starling’s paradigm.
A fourth option I neglected to mention, is to extend Starling yourself, for your purposes.
I’m frequently doing this in my projects. Adding or extending things here and there, that are useful to me and my approach to development. This has more to do with my personal preferences and project needs than any feature that might be absent from Starling.
Using frame indexes is in my opinion a less flexible way : if you realize animation X needs one more or one less frame you’re in for a lot of index changes everywhere. You don’t have that problem with names.
In any case what you describe can easily be added on top of Starling, as Bink said. That’s typically an extension : this way of doing things might suit you for example but it won’t suit me, and someone else might prefer a different approach. Starling provides the ground to handle pretty much anything, but it shouldn’t be too specific.
The sprite sheet definition you describe can also easily be added on top, but I wouldn’t want it to be the default : it’s potentially a lot of lost space in the texture.
Personally I would want that to change : I think we should maintain the existing API so that as3 devs can easily port their stuff to OpenFL, but aside from that we should feel free to add new features, make the code different etc
That’s something I want to discuss in the coming weeks/months, I know Chris started working on starling 3.0 a while ago
I’m perhaps not privy to the broader conversation, so I anticipate there’s some context I may be missing.
Personally, I feel going our own way with still-active libraries such as Starling, should be handled with care and caution, so long as the original repository is still active and accepting pull requests. The OpenFL and AIR communities overlap, and contributing a feature to Starling for AS3 so we can implement it in Starling for Haxe, sees both communities looked after. What’s good for Starling for AS3, is good for Starling for Haxe, and visa-versa.
I suspect too, that maintaining good synergy between AS3 and OpenFL versions of Starling, would reduce maintenance overheads when implementing updates from one to the other.
Other libraries, are not such an issue if the AS3 project has essentially been abandoned. Perhaps Away3D or DragonBones are examples of that.
It’s an issue I’ve been wrestling with even with my own efforts. I’ve supplied a pull request to OpenFL that provides KTXv1 support, but I do wonder if perhaps for these very reasons, it may be better to provide that as a Haxelib library instead. It is that difficult balance of trying to add valuable core features to OpenFL/Starling, while trying to stay somewhat true to the upstream API.
I agree up to a point 
If someone wants to add a new feature to starling-haxe and doesn’t have the time or motivation to also add it to the as3 version that’s fine to me. Personally I will try to do both if possible, but it shouldn’t be mandatory in my opinion.
There is stuff that you can’t do with as3, for example I saw Fancy2209 suggesting we should add GLSL support since OpenFL can upload GLSL to a Program3D : I think we should do it, even if the as3 version doesn’t have it.
There is also stuff that is bad for the haxe version, for example using ByteArray for VertexData : the only target on which it can be uploaded directly is flash/air. On all other targets the ByteArray’s data has to be copied to a Float32Array for upload.
This has a huge impact on performance : first because ByteArray is slow, even on flash/air target it’s a lot slower than using Vector with the slight advantage of faster upload (which doesn’t matter much in my opinion since you’re gonna be limited by CPU first). But it’s even worse on other targets where ByteArray doesn’t offer any advantage.
To illustrate here are some numbers on html5 target, displaying 64K texture-animated quads with raw Stage3D:
- 16 fps with
ByteArray(slow read/write + copied toFloat32Arraywhen uploaded) - 30 fps with
Vector(fast read/write + copied toFloat32Arraywhen uploaded) - 54 fps with
Float32Array(fast read/write + direct upload)
There is only one situation where ByteArray is fast : when using domain memory on flash/air target
Edit : numbers on air target for the same stuff :
- 19 fps with
ByteArray - 60 fps with
Vector(45-46 fps when displaying 128K) - 60 fps with
ByteArrayusing domain memory (50 fps when displaying 128K)
2 Likes
You make a solid case @Matse. I appreciate you going into the details of it, thank you.
1 Like
Good, Where can I obtain an example of this performance benchmark test? I would like to see the specific differences, thank you. 
It’s part of a Starling lib I’m about to “release”, you can test it here MassiveDemo
and the demo code is here : massive-starling/samples/demo at main · MatseFR/massive-starling · GitHub
2 Likes
That’s exciting @Matse!
I was having a play with your benchmark, and the performance difference I was seeing between Starling and Massive using the Zombie asset, was well… massive! 
Massive with 128,000 zombies was holding 60fps.
Starling with 128,000 zombies was holding around 4fps 
Curiously, using the Bird asset, resulted in similar results between Starling and Massive though… but perhaps this is still a work in progress?
1 Like
Cool, I can also run 128000 zombies at 60FPS. 
1 Like
Do you use the drawing API of openfl.dsplay.Sprite? Is it possible to use Float32Array instead of Vector?
Is there anything different about the bird? This sprite image has much worse performance than zombies.
You guys have much more powerful computers than me 
The speed difference is supposed to be massive 
it’s not displaying “real” images : it’s a kind of TileMap for Starling so the comparison is not here to say “look I have better overall rendering code” but more “with some limitations, if you need to display tons of textured quads this lib can do it”
Yup, I kept the bird asset in to illustrate how GPU can be a bottleneck (I tried to explain that in the demo’s readme on github) : I don’t know low level stuff much but my understanding is that when this happens we have a fillrate issue. GPU struggles with drawing all those pixels. If you look at your CPU usage though it’ll be much lower with Massive (as it should be since the code is much simpler)
I use Context3D.drawTriangles()
VertexBuffer3D has an uploadFromTypedArray method that lets you upload a Float32Arraywhich is sent to OpenGL directly on non-flash targets, all other methods result in the data being copied into a Float32Array before sending to OpenGL
I discovered this while trying to understand why I had best performance on air target : with this c++ is the fastest target as it should be
edit : if you want to have a look at the rendering it’s in MassiveDisplay ( massive-starling/src/massive/display/MassiveDisplay.hx at main · MatseFR/massive-starling · GitHub ) and ImageLayer ( massive-starling/src/massive/display/ImageLayer.hx at main · MatseFR/massive-starling · GitHub )
2 Likes