While staying on the topic of Flash Remoting. Using it with ActionScript 3 isn’t all that different. The basic building blocks are quite similar with those used in ActionScript 2. The main difference is that in ActionScript 3 there is a dedicated flash.net.Responder object that needs to be instantiated to receive the result from a AMF call. Knowing that, a bare bone ActionScript 3 Flash Remoting call would than look something like this:

import flash.events.NetStatusEvent;
import flash.net.NetConnection;
import flash.net.Responder;

function onConnectionStatus( event : NetStatusEvent ) : void
	{
		trace("onConnectionStatus " + event.info.level + ", " + event.info.code );
	}

function onResponderResult( result : String ) : void
	{
		trace("onResponderResult " + result);
	}

function onResponderStatus( event : NetStatusEvent ) : void
	{
		trace("onResponderStatus " + event.info.level + ", " + event.info.code );
	}

var responder : Responder;
responder = new Responder( onResponderResult, onResponderStatus );

var nc : NetConnection;
nc = new NetConnection();
nc.addEventListener( NetStatusEvent.NET_STATUS, onConnectionStatus);
nc.connect(http://localhost/remoting/gateway.php");
nc.call("HelloWorld.say", responder, "hello");

The other day I was attending the Colin Moock lecture “AS3 from the ground up” here in Sydney. Even though the lecture was very (and I mean very) basic, as it was intended, it was still quite interesting to see the man in action. I sat through the whole thing even though around 4 o’clock I was ready to walk out (of boredom). I’m glad I made it till the end.

Even though the lecture was quite basic there was one thing he pointed out that caught my attention. The implicit calling of the super class constructor. He’s stated that even if you do not specify a call to super in your sub class constructor, the super class constructor is still called. this sounded all to weird for me. I didn’t wanted to shout this out in case I was wrong and I didn’t bring a laptop to test out if this weird behavior was true. And thinking again, AS3 has a number of weird things going on that are not consistent with what you would expect. So, this might be another one of those things.

Never the less, the next day I decided to test this behavior just to make sure this was the case, and behold. It is. Besides the fact that you can’t make constructors private in AS3 (which is a different discussion all together) the super class constructor IS ALWAYS CALLED!!!

As a programmer, for me to override the constructor has actual meaning. It means that I DO NOT WANT THE SUPER CLASS CONSTRUCTOR TO EXECUTE, unless I call the super class constructor explicitly with the super keyword. To me this is another typical one of those; “we complier designers need to protect those poor little programmers from them selfs, the poor souls don’t know what they’re doing” type of thing. Sigh…

For some reason, the more I do with AS3 the the more frustrating it is becoming. Every time I run into small but irritating issues like this the more I tend to step away from the language. Don’t get me wrong, I like the executing speed increase and the improvement from AS2 its just these little annoying things that get to me.

The other weekend I was playing with APE. I must say, even though APE isn’t the most advanced physics engine for the Flash Platform out there, it is definitely easy to get up and running with. Maybe this is because of the limiting functionality of APE. The particles that APE offers are quite limited, Rectangle, Circle and Wheel. But still, there are some nice effects achievable with these three particles.

The main limitation I ran into when playing with APE was the fact that I couldn’t easily detect if a particle collided another particle. In the end, I ended up modifying the APE source by letting the AbtractItem (the base class for the AbstractParticle class) inherit from the Flash EventDispatcher class and modified the collision testing code in the CollisionDetector class to dispatch an event when a collision occurred.

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…