Once in a while I get requests or bug reports for flex2ant. Like the other day, I received a request for a fix of this one bug from two different people. Apparently a blog had popped up that discuses flex2ant (amonst other things). I knew that the problem in question was caused due to operating system differences but I didn’t really have the time to look into the problem.

When I received the second email explaining the issue I decided to have a look at it because the problem was starting annoy me. It didn’t annoy me that people report bugs, but the fact that there was a problem with flex2ant. And since I always try to fix bugs to code ASAP instead of pushing it forward, I loaded up up Eclipse, synchronized the project with the Subversion repository to be sure I had the latest copy and fixed the issue in about 2 min. Updating the website however, took me about 10 min.

So, there you go. If you’re a flex2ant user then get your new copy from the download area of the website. Happy Flexing!

No, its alright! I chose to go for the minimalistic theme called SandBox. Not only do I actually like this theme, it also gives me a great clean template to work from if I ever want to change the CSS for this blog myself.

Last week I was working on a port of a Quake model viewer I did in OpenGL to ActionScript 3.0 and Papervision3D. The actual AS3 code is reading the Quake model information from the original binary Quake .mdl file and contains, besides the polygon data, the bitmap that represents the texture for the model. The problem is that Quake uses a global color palette because the game was programmed for 256 colors (remember, this game is from 1996!). None of the models or textures actually stores a palette because they are assumed to all use the same palette and why store it many times… The actual color palette is stored in a separate binary file of 768 bytes in size (256 * 3 = 768, the 3 is for the three r, g, b color channels and every component ranges from the standard 0 – 255).

When building the AS3 version of the Quake model viewer I could have chosen to read the color palette from the binary file by loading it in at runtime. Instead I chose another approach. I created a class that represented the color palette and I embedded the raw palette information as a resource in the swf itself:

package
{
   import flash.utils.ByteArray;

   public class QuakePalette
   {
      [Embed(source="quake.pal", mimeType="application/octet-stream")]
      private static const Palette : Class;

      public var r : Array = null;
      public var g : Array = null;
      public var b : Array = null;

      public function QuakePalette()
      {
         var i : int;
         var a : ByteArray;

         a = new Palette() as ByteArray;

         r = new Array();
         g = new Array();
         b = new Array();

         for( i = 0; i < 256; i++)
         {
            r[i] = a.readUnsignedByte();
            g[i] = a.readUnsignedByte();
            b[i] = a.readUnsignedByte();
         }
      }
   }
}

Above is the code for the actual QuakePalette class that is used by the AS3 Quake model viewer. As you can see, the color palette is embedded inside the class as a resource. By setting the mimeType property to "application/octet-stream" the data is actually embedded as raw binary data. In the constructor the Palette class (the alias by which the raw binary data is known inside the class) is then casted as a ByteArray to be able to access the data. In the end the QuakePalette class has three public properties, r, g & b, that represent the three RGB color channels for easy access.

Some months ago I was working on a conversion of an OpenGL Quake 1 model viewer I did years ago, it must have been 2000 or 2001 or something, to Papervision3D. The overall conversion went pretty smooth because all of the difficult stuff I already did when I was building the OpenGL version and the code was documented pretty well.

When doing the conversion there was one problem I had at the time and that was the texturing. I just couldn’t get the texturing to work correctly with Papervision3D. I read the Papervision3D documentation and searched the web from top to bottom and inside out to find an example of the correct way to apply a texture to a Face3D object. At one point I just gave up and the code started to collect dust on my hard drive.

Until today. For a commercial project I’m currently working on I’m going to use Papervision3D and since I could spend paid hours on figuring out what the problem was with this code it seemed the right opportunity to dust off the Quake 1 model viewer code and fix this issue once and for all. And behold, after a day of debugging and bending my brain over and backwards, I seemed to have fixed the problem.

Basically, and I will not bore you with the details, I figured out that the Papervision3D documentation wasn’t that clear since the Face3D class constructor didn’t expected an array of {x,y} objects for the UV coordinates but an array of NumberUV objects. Second, the UV coordinates had to be given in percentage, something I lucky remembered from my OpenGL programming days.

So, there you go. You can checkout the Quake 1 model viewer here (might take a couple of seconds to load) and please let me know what you think…

…or as I would like to believe. I have a number of websites for which I use Google analytics and I check the stats on a regular basis. However, ever since Google applied the “new” design I had some trouble interpreting the main visitor statistics graph.

When ever you would hover with the mouse on one of the blue dots it would bring up a tool-tip stating the date of that particular blue dot. However, it would only say something like “18 October, 2007″. Now, what day was the 18th of October exactly? Was it a Monday, a Friday…? It would never give me context that I needed and I always had to look this up on a separate calender. A bit of a pain if you’d ask me. So, a couple of weeks ago I wrote the Google Analytics support team an email explaining my problem. And voila! When hovering the blue dots the other day it now states the day of the week in front of the date.

Now, I’m sure that Google already had this on their TODO list, but I would still like to believe that they actually listened to my suggestion. Anyways, all in all pretty cool…

When programming we all use comments. Some times we use comments more extensively then other times. In general we accept comments as a good thing, which of course they are. Comments can help you e.g. to annotate the difficult state logic of your fully animated menu system. Or it can be used to add full documentation of your library or framework API as you can do with something like JavaDoc and from which your actual documentation can be generated. Pretty cool!

I use comments myself in both situations. When I create libraries I always use a JavaDoc style of commenting for the interface of my API and when I do application development I tend to use more inline comments that explain some of the more difficult logic or that explains the structure of certain parts of the application. With inline comments I try as much as possible to make a brain dump of my short term memory about a certain aspect of the logic. This way, when I come back to this particular piece of code, be it weeks or even months later, I can more easily pick up of what was going on or why I did things in a certain way. This is especially necessary for the gotchas!

Over the years however I’ve seen quite a lot of programmers taking a weird approach to comments. Often when browsing through source files, of mostly unexperienced programmers, I often see comments like this:

function foo(x : int, y : int) : int
{
   var q;

   // Add x & y together and store the result in q.
   q = x + y;

   return( q );
}

You see that comment? What it does, is just echoing what the code does. It a completely pointless comment. I’m a programmer and I can read code! I know it adds y to x and then stores the result in q. What I would like to know is why… Instead of actually taking the time to describe what the function does and why it exists, the programmer added a pointless comment to the code because commenting your code is good, isn’t it? Well, not if you comment your code this way.

So, next time you write that function that has some obscure algorithm going on, just add comments that describe in plain English what that algorithm does, how it works and what you should use the function for. Don’t just add useless comments out of the notion that commenting your code is good.