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.
July 26th, 2007
This video is hilarious, and holds a special place in my heart being a mashup and all. Embedded video below.
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.
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.
July 2nd, 2007
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.1that came with those files.
- If you want the native player, download the Linux Flash players and extract the file located in
flex-saflashplayerfolder. You should have a file named
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…
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.
Now that you’re done, type
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.