Yeah, it seems like there're a lot of arrays being thrown away. The "_non_class" thing is Dynamics that take on a Float, Int, or Bool state, I believe - I've got a fix that at least gives them better names, but it's in hxcpp (and not yet pushed)
And dynamics -- a few weeks back the OpenFL guys went through a pass of tightening up some of these allocations
very unexpected things cause them, e.g. map.getKeys() causes an Array allocation, function closures cause the inner simple types (e.g. int/float) to become Dynamics. I mean, it makes sense if you think about it, but when you're coding along, you don't really think about it
There's lots of good discussion in OpenFL's slack - just send @jgranick your email and ask for an invite (same for Mike, if he'd like.) But unfortunately it's a free installation, so it doesn't keep history indefinitely.
I intentionally have the old style flip phones they market to old people
I'm actually grumpy because it has some pointless media features and a color display; ideally I want a black & white oldschool grid LCD display, and only talk and text, and thus a battery life that lasts forever
my wife has a smartphone so we're not totally out of the loop, I borrow that when I absolutely need it
we're a mixed device family, lol, wife has macbook air and iPhone, I have an android, chromebook and prefer linux. We have a desktop Windows machine. So I'm generally ok for x-platform development. But I spend most of my time in linux.
I let my ios dev license expire.
(oh, I've got an old mac mini I ssh into to do builds :) )
now, let me lay out the philosophical differences of the major frameworks as I understand them:
1) NME: stability and performance. Don't move the API around. It works, it's fast, don't fix it if it ain't broke.
also, cover the Flash API, but doesn't insist on covering absolutely all of it with 100% fidelity
2) Lime: low level cross platform abstraction layer, build off SDL, try to avoid custom backends. Top priority seems to be: GET ON ALL THE PLATFORMS
2.a) OpenFL: cover the Flash API, and cover as much of it as possible, with the greatest fidelity. Integrate with all the Flash tools it can. Support SWF on all targets if we can. Basically be a wholesale native crossplatform replacement for Flash, and a solid multimedia library in general
3) Flow, Snow, and Luxe: You have to go to sven for specifics and he may correct me, but as I see it: -- Don't make it more complex than it needs to be -- Forget about flash entirely -- Focus squarely on GL for native and WebGL for html5
and then Kha is its own thing with a focus on being very lightweight and super crossplatform
So Lime+OpenFL endured a LOT of instability as we transitioned to Next, it has been a tough transition, and you are coming in now at the very end of it
I haven't looked at lime directly... For games (which I'm not professionally involved in...yet, but I have done one in AIR) I'm interested in GPU-focused APIs, sprite sheets, shaders, etc. At work, we may shift from AS3 to Haxe, targeting html5 and perhaps native, so it could become in interest there.
Right now I'm in a spot where Lime could be my backend, but I'd also like to have a lightweight framework on top of it with features like sprites, animations, particles, shaders, stencils and basic raycasting. Then I can build my stuff on top of that.
guys.. it's late and I need to drive home.. I'll catch with you in about an hour. And Mike, I want something like that.. any chance someone already started something similar and we can all join forces?
@jcward if you have an interest in this whole GPU framework world of code definitely have a look at Khas code. its a really cool toolchain. cross compiles shaders from GLSL to Metal (iOS) and DirectX. has native backends for OpenGL, Metal and DirectX all with the same api. lots of really neat stuff in there.
the big issues with Kha is no documentation, no community, basically one developer maintaining it and it is very fragile.
it has some great ideas but i dont think its stable enough for production use for anyone other than Robert. he seems to be the only one familiar enough with the code to fix anything. too many moving parts in there
I fixed that issue on iOS but then it doesn't resize on that device. And it looks like a problem occurring during resize. I'll have another look at it on a Mac with Retina tomorrow if I find some time during this weekend
BTW one of the guys at Motion Twin told me that they're soon going to switch from h2d to heaps. I don't really know where that framework places itself. At first I thought it was just a personal project of Haxe's creator
I dunno if I read that, but when I was first getting into haxe, he had some irritations with openfl. he has good (but strong) ideas about separation of concerns and libraries. Joshua is more of a "bring it all together and make it work for the end user" philosophy.
and i agree with them even if i contribute to oss myself
it's got to be oss but with a solid company behind it.. then you have chances
think about this: i am a company. I want to own the 2d tech i will use and sell it to others (as paid support). I look into openfl. Nice. But it's oss. Who owns it? Shall I lose months trying to get the ball roling? Not really. It's a hard sell.