Adobe AIR Bouncing Ball
I've created a little bouncing ball sample for Adobe AIR (derivative of course of our stock Boxely example some of you may be familiar with). You simply run the AIR applet and the ball will do its thing. You can pick it up and toss it as well and it will be constrained to your primary display.
I just wanted to demonstrate to the Adobe folks that their system capabilities class is not quite enough to do tight integration with the user's desktop. In this case for example, we'd prefer to know the user's "work area" size and position rather than the monitor resolution, for example so as not to go behind the taskbar on Windows or if the taskbar is docked to the top of the screen to know that the work area is not oriented at 0,0. Apparently there is a 'Screen' class coming soon?
Very simple code, the source is available on request. I just snag screenResolutionX and screenResolutionY from flash.system.Capabilities, and then let a gravity and elastic constant affect the ball position on the desktop. The ball itself of course is just a 60x60 SWF - over time I'm simply setting and resetting stage.window.x and stage.window.y ... when the user grabs the ball, I kick into a system managed drag via stage.window.startMove() and monitor the balls position in a frame handler.
AIR is starting to show some promise but still missing a few fundamentals.
Download the AIR file here.
posted by Twinsen @ 4:03 PM
6 comments
6 Comments:
I really enjoyed your bouncing ball application. When I ran it on my MacBook Pro, the ball fell to the bottom of the screen behind the Dock and I was unable to grab the ball. After moving the Dock to the side I was able to grab the ball and throw it around. Very cool application.
Right..that's the issue I've reported to Adobe. :)
Clearly, you have not thought it through. There is no need to animate the default NativeWindow (in fact you shouldn't be doing so at all).
Most developers need the screenResolutionX and screenResolutionY to return the actual value of the screens resolution and not some "workable area". Which, to be honest, could be different for every developer.
The adobe integrated runtime uses your operating systems “Native Windows”, so things *will* go off the screen and behind the task bar. Do yourself a favor and open a new window and drag it around your desktop. Notice how it can go behind your task bar and off the edge of the screen? This is a feature. And because you are animating a window, instead of a sprite, this will be the case.
You should be maximizing the default (yet transparent) NativeWindow and animating the ball instance within it. See: window.maximize(); and addChild(ball). That way, the operating system will auto-magically work this “workable area” out for you, you can then access via: window.height and window.width.
Now when you come to run your application, the operating system will do all the working out for you. And when you bounce the ball around the screen you can shift the (dock/taskbar) to edge of the screen, since the default NativeWindow is set to “maximize” it will inherit the size of available space.
And then you can relax.
Heh...no. I politely disagree... my current version (due to the recent introduction of the APIs and metrics I declared to be missing at the time) now bounces between multiple monitors / displays and is conscious of non-work area fixtures such as the dock and taskbar.
As to maximizing a transparent window and animating a sprite within - huuuge performance differences (specifically on MS Windows) between that and my approach. Not to mention the fact that I desire to bounce seamlessly between and several displays.
The performance issue boils down to a fundamental architectural issue on Windows. Falls into the category of "too much information" but... just fyi, on the Windows platform, AIR uses "layered windows" (ws_ex_transparent HWNDs) - In windows (unlike Mac) there is no way to update just a portion of a layered window (e.g. just the dirty bits)..the entire thing must be updated at once for each frame. The performance of updating (blitting) a single layered window (especially one spanning three displays..is absolutely horrid). There is zero cost of moving an already cached layered window (of size 50x50) around the screen because once the display buffer is updated, it's cached by the operating system.
I'll post comparison apps if you'd like after the Adobe MAX release of AIR is public. Huge perf difference.
Yeah, but you are still animating a native window around the desktop. Even though it's visually represented as a ball, it's still a window. And as such it will inherit size metrics from the desktop.
The ws_ex_transparent window style you are talking about, (performance issues) the mileage of which will greatly differ depending on the specs of the Machine in question.
I understand what you are saying, because this ball-window debate has been argued from the very first day of the beta, across many blogs.
You can throw a ball across multiple "NativeWindows".. transparent or not transparent.
http://theflexblog.com/?p=50
Adding multiple balls with collision detection (to be used as some game), would be easier to implement when you animate a display object (sprite) within a single native window.
Rather than creating every object as a unique native window. It's easier to manage as few as possible.
@wez, "And as such it will inherit size metrics from the desktop."
Since when? Windows are nothing but display objects themselves, owned by the desktop window manager. Windows have explicit height width, and x, y position relative to the work area of the desktop. Their size metrics are not inherited nor dictated by the 'desktop'.
That said, check out "SoupToys". Managing a collection of layered windows (transparent windows) and updating their positions as modelled by a physics model - while keeping things as performant as possible (the smaller the bitmap representing the layered windows, the better) - is the optimal solution.
Thanks, agree, the issue is a fun debate - falls into the bucket of "to each is own" though imho. Either way it's a fun way to exercise the new AIR runtime. :)
Post a Comment
<< Home