Yes, I'd love to see this too, thanks for keeping us updated Kevin, nice one Tom
On 22 Sep 2010, at 18:07, jared stanley wrote: wow 60 fps sounds impressive! i have not been impressed with the flash>iphone demos adobe has been showcasing; they showcased the same blox game when they first announced it and again 6 months later just before release...i would love to see your example as it would be the first smooth-running demo i've seen. On Wed, Sep 22, 2010 at 9:29 AM, Kevin Newman <capta...@unfocus.com> wrote: > This all worked great. I now have the unBrix demo running at 60FPS - > smooth as silk (almost, there are a very few small hiccups, nothing like in > the previous demo - I have one last optimization left that I think will > clean that up). > > The things I did were to make sure GPU acceleration is working (the bricks > were red previously) - and preallocating (instantiating and storing) any and > all objects I might need, and removing reliance on build in black box > methods like hitTextObject. Actually, I separated the entire game engine > into simpler shape objects (x, y, width, height - all int - final classes, > no getter/setter, no inheritance) and did all the hit testing movement > calculation manually on those, then apply that to scene in the render phase > of ENTER_FRAME. I'll try moving it to RENDER event and see if that yields > any improvement too (which'll be hard to spot!). > > Doing all that preallocation jives with what is mentioned in the packager > for iphone dev guide PDF: > > http://download.macromedia.com/pub/labs/packagerforiphone/packagerforiphone_devguide.pdf > > In particular: "Allocating fresh blocks of memory is costly. It can slow > down your application or cause performance to lag during animation or > interaction as the garbage collection gets triggered." > > and: "As memory fills up, iPhone OS notifies other running, native iPhone > applications to free up memory. As these applications process this > notification and work to free memory, they may compete with your application > for CPU cycles. This can momentarily degrade the performance of your > application." > > For me, memory allocation has been the biggest cause for stuttering and > visual "lag" in Flash on iPhone. > > I haven't posted the results yet, because I only finished this work at 3am. > ;-) Also, certain properties like cacheAsBitmapMatrix aren't available in > the Player swf builds (to run on Android or Frash) so I'm not certain a > posted swf would truly represent these improvements (I'll try it anyway > though). Hopefully I can finish and polish something within a few weeks or > months and get it into the app store! :-D > > Kevin N. > > > > > On 9/21/10 5:07 PM, Kevin Newman wrote: > >> I've been attempting to tackle the same issues, and would love a lot more >> info, if there is any available, on how to get the framerates to be stable. >> >> I've actually had a bit of luck, and I'm currently operating on the theory >> that the problem lies with memory allocation/deallocation and the garbage >> collector. This seems to apply to any situation where the player might >> create objects that will have to be collected - including events (the event >> object - passed on dispatch), and maybe even functions in general (args >> array?) - and certain built in methods like hitTestObject, or >> txtFld.htmlText. Constructors are a killer. >> >> I'm in the process of refactoring this: >> http://www.unfocus.com/unBrix.html to aggressively remove all reliance on >> black box APIs (like hitTestObject) and create 0 (zero) new objects per >> frame, except the two event objects (ENTER_FRAME and possibly RENDER) and >> touch/mouse events. >> >> I should be done with that tonight, and then I'll have a better idea of >> what kind of impact that has if any on the performance, and most importantly >> on the lag spikes (for lack of a better term). >> >> In general, I'll also note that Frash (the hacked Android player on iOS) >> works far better in terms of scripting than the iPhone compiler - I hope the >> recent changes in Apple's ToS means that Adobe can just ship AVM2 and skip >> all this AOT compilation, since AVM2 from what I can tell, performs better >> anyway (it should help make the compile times bearable too). >> >> From what I'm seeing, the scripting has a definite impact on performance, >> much more than the folks at Adobe are letting on (maybe they aren't aware?). >> >> Kevin N. >> >> >> >> On 9/21/10 9:19 AM, Tom Gooding wrote: >> >>> Hi Flashcoders (back to Apple again), >>> >>> I'm wondering, having seen reports that developers are getting CS5 >>> packager content approved on the app store, if anyone knows of a decent >>> Flash game / app on iPhone? >>> >>> I have just read this thread on Adobe labs: >>> >>> http://forums.adobe.com/thread/718595?tstart=0 >>> >>> Whilst there's some regrettable bickering to wade through - the overall >>> impression I take from it, is that decent visual performance, say 30fps, >>> (even when optimising for gpu according to the guidelines) isn't possible. >>> I'm considering whether to dedicate some resources to our own benchmarking >>> of it, but currently, I get the impression it's not worth it if you want >>> stuff that runs well / is comparable to the native platform. >>> >>> Can anyone point me in the direction of something that makes a genuine >>> case for Flash on iPhone before we dump it in favour of Unity3D?! >>> >>> Thanks! >>> >>> Tom >>> >>> >>> >> _______________________________________________ >> Flashcoders mailing list >> Flashcoders@chattyfig.figleaf.com >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> > > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
