January 3rd, 2008 § § permalink
No new features: just rebuilt and repackaged to run on AIR beta 3. Note that the newest AIR beta properly displays animated GIFs, which makes this silly app look much better :)
I did have to make a change from the original version, to conform to the new AIR HTML security model. My original code used
setInterval, with a string to execute as the first parameter. This is a no-no in the new security model (since the executable string is the equivalent of an
eval). I could have put the whole thing into an
iframe in a non-application sandbox, but instead I used the AIR-native
Timer class, which did the trick.
Download the updated Monster Attack! (requires Adobe AIR beta 3)
September 27th, 2007 § § permalink
September 26th, 2007 § § permalink
Well that was easy!
alwaysInFront in the AIR API), and voilà: monster attacking your desktop!
It’s not quite finished though. The biggest problem is that the current beta of the AIR runtime does not display animated GIFs correctly (it just displays the first frame), so the fires do not look right (this is a known bug and should be fixed by the 1.0 release of AIR). I may change the code to do the animations myself. Besides that, I have not created any application icons yet, and has only been tested on Windows, on a single machine :P No idea how well it runs on the Mac. UPDATE: After fixing the mime type for AIR files, it now downloads on Safari on my Mac and runs correctly. On top of that, the animated GIFs run properly on Mac OS X!
If you run this, be warned that it eats a lot of CPU time, which is not a surprise; after all, it’s a full-screen transparent window!
If you have the AIR runtime installed (available here), then give this a try.
Download monster attack!
September 26th, 2007 § § permalink
I’m here at the Toronto stop of the Adobe AIR Tour. So far it’s been pretty keen with cool demos, including stuff like applying Flash filters (e.g. blur, bevel, etc) to HTML elements. Nice.
Right now Akamai just announced the release of an AS3 Media Player Framework…
Oh yeah, I’m not liveblogging :P
August 15th, 2007 § § permalink
I’m experiencing a strange problem: when running an Adobe AIR app, the Flash debug player
trace() log stops updating!
The details: I’ve followed the steps in this article so that I can read the output of
trace() while running Flash movies in the browser. I use cygwin and the
tail command to view the log updating in real time (I’m running Windows XP SP2 Home).
Now, I’ve noticed that whenever a new instance of the Flash player loads, it clears the flashlog.txt file. The tail command reports this as “
tail: flashlog.txt: file truncated“. This happens when, say, I reload a Flash movie in IE and then in Firefox. But in both cases, logging of
trace() continues after the file is cleared.
However, whenever I launch an AIR app (for example, the excellent tweetr or kuler apps), not only does the log file truncate (as I would expect), but the flashlog.txt file stops updating, no matter what
trace() commands execute in my browser movies. The file stays at zero length for as long as the AIR app is running. When I quit the AIR app,
trace() commands resume logging to flashlog.txt.
It’s quite odd. Note that I am not the author of these (or any) AIR apps, so I do not know if those apps are using
trace() at all. Perhaps it’s just a case of AIR locking flashlog.txt and not letting go until the app(s) are closed?
The upshot is that I have to close any AIR apps before following any
trace() logs. A small inconvenience, but it took me a while to figure out :P