Splice Music

August 6th, 2007

Oh my goodness. Andre has really done it this time. It’s a very “Web 2.0” community remixing site that uses Flash, allowing it all to run straight out of a browser. The Creative Commons-loving crowd is going to have a joygasm when they see it. Cory Doctorow will be so happy he’ll fall from his balloon. Also, my ongoing battle to outmatch Andre in AS skillz has been nixed again. Of course it seems another fellow did all the real audio work, but I must try harder nonetheless. You win this round Michelle.

Flash… sucks?

August 2nd, 2007

This is a pretty interesting article in the sense that it provides a great insight into the minds of people who love, hate, and love to hate, Flash. The article writer’s opinion is that Flash sucks, but the shining point is the comments section which is full of well-thought responses. Truth is, most everybody on that web page seems like an intelligent individual, albeit with varying levels of bias. I can’t think of a single argument for or against Flash that wasn’t covered in a convincing way.

Thing is, I wasn’t aware Flash was going to include a DRM system in an upcoming version. I don’t know how I missed that one. If Adobe ever wanted to scare away the open source (or open specs) crowd that’d do it. With Flex going open-source it seemed like things were going so well too.

Edit: Whoops, according to Adobe the BBC didn’t distinguish between the Adobe Media Player and Flash. That explains a lot.

Flash still plays Doom

July 28th, 2007

Update: Visit the home of Doomed Online here.

I’m pretty pleased with my Doom port so far. I’ve read some comments from people who think the lack of collision detection and sprites mean the final speed will much slower. These people don’t know what they’re talking about. I just finished some basic sprite support and there was no negligible speed impact. Since the sprite drawing routine is faster than the wall drawing routine, this offsets the extra time it takes to process sprites. Pretty cool, huh?

As for collision detection, that’s mostly insignificant. Every update will slow things down, but a wide majority of processing will always be spent drawing the walls, ceilings, and floors, because that’s where most of the work is.

On a side note, to test sprites, I added “dummy” enemies. They just stand there, staring at the player. I cannot begin to describe how inexplicably creepy this is. Here’s a screenshot.

doom-screenshot.png

Flash Plays Doom

July 20th, 2007

Update 3: Visit the home of Doomed Online here.

Update 2: There’s a bigger, badder, version up now.

Yes, that’s THE Doom. This uses the original Doom shareware wad file and gets all content from it at runtime. There’s no preloader, so be patient, it’s 1.7 MB. Use the arrow keys to move.

You’ll need to view this in a browser with Javascript and Flash 9 in order to see it.

There’s no sprites yet (enemies, barrels, that sort of thing) and you can walk through walls too. There’s also a mysterious bug that erects unnecessary walls in the outer areas of the map, but altogether it’s still pretty fast and stable right now. There’s some rudimentary sound support too, although for some reason it sounds scratchy at the end of a sound right now. Press the spacebar to hear.

It took some trial and error to get this far, since making a fast rendering system is so important. I tried using the same method for drawing bitmaps as Papervision at first, and while it was very fast, it also looked terrible. Papervision’s technique doesn’t seem to work well in an FPS environment because the wall textures skewed as you walk along them. I tried again with another method that used Flash’s draw method heavily, but it was far too slow and hard to work with. I was about to trash the whole thing, but I tried a more basic system, roughly resembling how environments were drawn in the original Doom where each pixel is drawn one-by-one. It seemed like it was still too slow, but after a few key optimizations to the drawing routine it ended up being very fast. I honestly wasn’t expecting that, but it’s actually playable now on a decent computer.

I don’t know exactly where I’m going with this, but I’m pretty sure it’s worth it. The only thing I can’t do is the music, the format is roughly the same as midi, and as far as I can’t tell it can’t be preloaded. Everything else Doom is capable of is possible. This whole thing was developed entirely using Flex 2 and the Flex 3 beta with Eclipse on Ubuntu Linux. In other words, with only free tools, right down to the OS.

Update: Apparently nobody knows my name. I think that’s kinda cool, but it’s actually Max.

You can now own your very own Debian/Ubuntu (.deb), Redhat/Fedora (.rpm) or Slackware (.tgz) packages for the Flex 2 SDK. The catch? You have to make them yourself, but at least it’s as easy as moving some couple files around.

This can generate three packages, one for the Flex 2 SDK, another for the native (GTK) standalone Flash debug player, and yet another for a wine-powered standalone Flash debug player. I’ve only tested this on Ubuntu (Debian) so any information on how well it works with other distros would be nice.

Step 1: Get checkinstall

The script I wrote for this job uses checkinstall, you should be able to get this program using your favorite package management software.

Step 2: Gather the files

  • Download these files and unpack them somewhere. It has several folders that you need move files into.
  • Download the Flex 2 SDK, and unpack these files into the folder named flex-2.0.1 that came with those files.
  • If you want the native player, download the Linux Flash players and extract the file located in flash_player_9_linux_dev/standalone/debugger/flashplayer.tar.gz to the flex-saflashplayer folder. You should have a file named flashplayer there now.

Step 3: Make packages

Either just double-click the create-packages.sh file or open a terminal, navigate to your working folder, and run this command…
./create-packages.sh
Any arguments you add to create-packages.sh will be passed to checkinstall, so you can use arguments like -D (force Debian), -R (force RPM) and -S (force Slackware).

Before each package is created you’ll be presented with some details, you can adjust these settings or simply press enter to continue. Once you’re done you’ll have two or three packages.

Step 4: Install

Install the packages using whatever method is available to you, double-clicking being the obvious choice. On Debian/Ubuntu you can run this command…
dpkg -i *.deb
to install them all.

Epilogue

Now that you’re done, type mxmlc, fdb, compc, or asdoc in the command line and bask in it’s glory.

The Flash debugger will use whatever Flash debug player is installed, but if you install both, then the native player will be used by default. If you want to pick, then type this into the command line…
sudo update-alternatives --config flex2-flashplayer
and pick one of the choices. Personally, I feel the wine-powered player is more stable, but it’s a little slower.

I can’t figure out how to include the Flex Ant Tasks as a package because (at least on Ubuntu) Eclipse has it’s own folder for Ant libraries (most of which are symbolic links to the actual files in ant’s library folder) which I don’t know how to reference. Eclipse is kinda screwy on Ubuntu, so I guess that’s to be expected.

All the Flex files are located in /usr/lib/flex, so use that as your FLEX_HOME variable if you continue using the Flex Ant Tasks.

I also can’t figure out how to set FLEX_HOME globally, since editing /etc/profile seems out of the question. For now I use wrapper scripts to set FLEX_HOME if it isn’t already set, but if anybody has any better ideas, email me.

FZip – Updated

June 22nd, 2007

FZip has been updated, it has a couple nifty changes.

  • Apollo/Air has built-in deflate support (ironic, isn’t it?), so if you make an Air app, you don’t need to “prepare” the zip file like before. This means FZip can open any zip file from within Air.
  • There’s better support for foreign language filenames. Unicode is now the default, but that can be easily changed.
  • There’s a new class, FZipLibrary, which is an (optional) processor that makes it easier to convert incoming files into other formats (images, swf files, etc).

The Air support is the most significant change, but if you’re putting the zip online you’ll have to run it through fzip-prepare.py first.

SWX

March 31st, 2007

I won’t lie, I don’t really care for data interchange formats (or data exchange formats, or standardized format exchanges, whatever you want to call it), so that’s why my eyes glossed over while reading about Aral’s SWX project. This is all despite the fact that I myself have actually helped create what could be called a data interchange format. Now after all the drama surrounding spewed forth I decided to give it a look and you know what? I’m impressed. In theory anyway.

I love the idea of leveraging Flash to produce faster results because of my long-standing obession with speed. I like SWX because it’s the closest thing to basically encoding data directly into Flash. Since some serialization always has to take place, why not serialize strings or arrays directly into a SWF? I can’t speak for Aral’s implementation, but to me it’s clearly one of the better ideas when it comes to Flash-specific solutions. If you have control over the client and everything server-side then the your solution need only be reliable. SWX offers real advantages to those who want them.

Since I’m one of the developers for FZip, which arguably an alternative format, I’d like to note that FZip and SWX are two very different things. FZip is intended to transfer files, not data (like an array or a string), although both systems could arguably do each other’s job, they wouldn’t be very good at it.

I’m ending this post with a couple quotes from Aral’s hilarious angry pro-SWX rant. Keep in mind I actually like SWX and wish to see it evolve, I just find these little tidbits very humorous when quoted out of context.

  • WTF? Who died and elected you Pope, Mr. Hultberg?
  • You see, Flash developers are an ignorant bunch who live simple lives.
  • He is the white man come to educate the natives with the Word of the Lord.
  • [Humans are] an unpredictable, complex creature that may just be scratching his balls with one hand as he uses your lovingly crafted interface with the other while simultaneously devoting 73% of his attention to Carmen Electra’s rack in the trailer of I Want Candy that’s blaring on his TV screen.

Update: Hardy-har-har

More Actionscript One-Liners

March 27th, 2007

I’ve been having some fun working out new speedy lines of code using operators

// if str is blank, pass an alternative string
return str || "str is blank";

// if obj isn't active, return null
return (obj.isActive && obj) || null;

// If num is zero, return "1" instead
return num || 1;

// If num is zero or not a real number (including NaN), return "1" instead
return (isFinite(num) && num) || 1;

// If num is less than 0 or not a real number, return "0" instead
return (isFinite(num) && num > 0 && num) || 0;

// add an entry to a list that is created if it doesn't exist
(arr || (arr = [])).push(entry);

Anybody have other ideas?

Apollo

March 19th, 2007

The public alpha is out. I awoke suddenly in the middle of the night for no apparent reason, only to find that Apollo had been released… almost as if it was calling to me. 😉

It was fairly easy to port my current project to an Apollo app and I was pleased to discover that you can create Apollo “air” files (installers) on Linux. Not that this matters since “air” files are just zip files, so I could probably make an “air” creator myself. The Apollo runtime and debugger aren’t available for Linux, which is understandable, although they should probably find the time to port it later if they want Apollo to be taken seriously. It doesn’t matter much to me since my project works under multiple circumstances (Apollo, Flex, Flex-less Actionscript) and I do my debugging under an simpler environment.

So far I like Apollo, but it’s easy for a Flash developer to like Apollo, what about everybody else? With all the (somewhat undeserved) attention towards Web 2.0 sites, I wonder if anyone will even notice Apollo. It’s still a nifty idea anyway, and there might be a niche out there just waiting for Apollo to come along.

Faster Actionscript

March 17th, 2007

I’ve long been mildly obsessed with getting power out of Actionscript. These days Actionscript is fast enough that I can code with less time spent optimizing, but I still like writing code I know is faster than its more readable counterpart. I never thought this line, one I use frequently, would ever be trumped…

var value = obj ? obj : (obj = new Something());

It’s very straightforward, right? If obj doesn’t exist, it is created, and a non-null value of obj is always passed on. How could it get any better?

var value = obj || (obj = new Something());

That’s how. I spotted a similar line while checking out Papervision’s source code, the only library I’ve ever seen where the obsession with optimization is greater than my own. This line only offers one less operation, which is practically nothing, but it’s still very interesting especially when there could be real advantages to using them in a long series. You can do similar tricks with a && operator. These two lines do the basically same thing…

var value = objA ? objB : null;
var value = objA && objB;

A series of && operators returns the last statement if all previous statements are non-null. A series of || operators returns the first non-null statement. I always thought those operations converted everything into boolean values, but they don’t, they pass on values based on their equivalent boolean values. But that’s not all the interesting things I’m leeching from Papervision, there’s also the best lazy array iterator I wish I thought of…

var p, i = list.length;
while (p = list[--i]) p.doSomething();
// or
var p, i = 0;
while (p = list[i++]) p.doSomething();

This line reminds me of my speed-obsessed days. It’s similar to a technique I’m using now, but it has a flaw (feature?). If the list changes then entries may be skipped or run more than once. Regardless, it’s very stable and probably the best way to handle things as long as an entry can be run twice or skipped without messing up everything. It probably doesn’t have a speed advantage over this… (Update: Looks like the following method is slightly faster as long as you don’t need to access list[i] more than once)

var i = list.length;
while (i-- > 0) list[i].doSomething();

But it stores list[i] in a variable, which allows static typing to be used, and makes sure the variable is non-null beforehand. Too cool.

Update: Did some basic speed tests. Papervision’s method beats out a “for each” loop every time. The “while (i –> 0)” loop has an advantage as long as list[i] is accessed only once. Might just be my computer though.