I’ve been working with AIR for quite some time, but have procrastinated getting into this part. The feature has been around for a long time too.
With this new mini-project (Anatomically Incorrect Dinosaurs) that I’ve been working on, I decided to look into it again. I was so not sorry. AIR is amazing.
NativeWindow opened up a world of possibilities for me (game design/development wise). For example, I could make the user’s actual desktop a level! There’s a lot that can be done in terms of “breaking the fourth wall”.
In this case, I thought it would be cool if the window would look like some old-school DOS thing, and be self-aware. By that I mean it would comment on things you do, complain if you minimize it, or try to push it off-screen. Turn the actual WINDOW into a game.
This is a gimmick I’m also exploring for the Steam version of Tetrageddon Games, so it seemed right to test it out on Anatomically Incorrect Dinosaurs first.
Other Articles & Docs:
The NativeWindow class is what makes this all possible, and it’s all pretty self-explanatory.
There are also a number of other tutorials out there. Ones I found insightful where…
(And for working with multiple monitors)
* How to use two fullscreen windows in two monitors with Adobe AIR
* How to display a single fullscreen window across multiple screens in Adobe AIR
Opening “New” Windows & Managing Windows:
What I loved about this is that you can “open” as many windows as you want (see NativeWindowInitOptions for setup ), and it sort of reminded me of working with the display list, except it’s all “happening” on the desktop.
Populating these windows with content is very similar to populating any sprite/mc with content. Just
addChild to that window’s stage.
Essentially the user’s screen is all yours, and you can (very flexibly) get the screen’s size (for placement, example: S
.height ), or multiple screens.
From the docs :
“The screen API contains a single class, Screen, which provides static members for getting system screen information, and instance members for describing a particular screen.
A computer system can have several monitors or displays attached, which can correspond to several desktop screens arranged in a virtual space. The AIR Screen class provides information about the screens, their relative arrangement, and their usable space. If more than one monitor maps to the same screen, only one screen exists. If the size of a screen is larger than the display area of the monitor, there is no way to determine which portion of the screen is currently visible.
A screen represents an independent desktop display area. Screens are described as rectangles within the virtual desktop. The upper-left corner of screen designated as the primary display is the origin of the virtual desktop coordinate system. All values used to describe a screen are provided in pixels.”
I suggest reading Display screens in AIR. It says everything.
BASIC example is:
Customizing Your Window:
This was so basic that it confused me a bit. Thought I was doing something wrong, but no. It’s just really simple…
All that is required is your design (visually however you want that to be) and you control the window with your normal event listeners. This old devnet article has a good rundown.
Also see Public Methods in the Native Window docs for an overview of most of the functionality.
For example, if you wanted to set the initial position of the window (center it)…
Note that (as in this doc)
Screen.mainScreen.bounds is your friend for any placing sizing… Also:
“Do not save the values returned by the Screen class methods and properties. The user or operating system can change the available screens and their arrangement at any time.”
Events like minimizing, maximizing, or closing can be added as your basic mouse button event handlers…
Interestingly enough you can also detect if the window HAS been maximized or minimized (current state). This would be done in a
I’m really not sure what else there is to add to this. The entire thing has been so basic I feel ridiculous putting this into writing. (emphasis intended)
Now I have no idea why I haven’t done this sooner, because it opens up so many doors to so many fun little features that I can add to my games.
Actually… I could finish with a rant!
Ok! Here we go…
I’m really utterly exhausted about hearing the “Flash is dead” argument. I’ve been with the technology since it was called Future Splash, and ever since I can remember, people have been saying that… or hating on it. Microsoft first coined that phrase when they where pushing Silverlight (then Sparkle)… To be honest, nothing died. It just evolved.
I see all these platforms evolving, and becoming wonderful tools that I love using (all of them). I love HTML5 for what it is (HTML5 is an umbrella term, but to keep things simple I just say HTML5), but it’s no Flash. I love Flash for all the things it is, but it’s no HTML5. Both of these solutions have their pet peeves (don’t get me started on HTML5). In the end, I wouldn’t want to go without any of these.
Arguing what killed what is like arguing what screw driver head is better than the other. I’m totally tired of hearing it.
To me, whenever I hear another “developer” arguing that “Flash is dead” it just goes to show that they are amateurs. I can’t event take the conversation (or person) serious anymore.
On a personal level, all this has stopped “getting to me” after I won the IGF Nuovo Award. If your work is good people will not judge it (or your perceived technical skills) based on the technology you use. The end user just sees your good work. It really meant a lot to me seeing all these people playing the game, totally enjoying it, and not one of them thought any less of it because of the tools I’m using. Turns out the people that made me feel that way about my skill-set where just amateurs themselves. Silly how I took that seriously.
At any rate, thanks for listening. I will not comment on this any further! :)
Anatomically Incorrect Dinosaurs will be awesome, and is coming soon.