The idea was to build the foundation for a fancy, compositing-based windowing system: beside the actual implementation that’s basically just wobbling the current target, i’m sure you’ll be able to come up with other effects as well, but that’s not the real point.
Setting aside the concrete animator implementation that would be better to be used as a base to derive some more abstract definitions from it, the architecture is quite open to new approaches and ideas, especially for the ultra-simple opengl-like interface i chosen for the rasterizer that let’s you prototype things quite fast:

package rasterizer
{
	import flash.display.Sprite;
	import flash.display.BitmapData;
	import rasterizer.data.*;

	/**
	 * OpenGL-like interface for a generic rasterizer.
	 * The triangle is the only supported polygon right now
	 *
	 * More desc for me..
	 */
	public interface IRasterizer
	{
		function glTexture( tex: BitmapData, forceRecreate: Boolean = false, smooth: Boolean = false ): void;
		function glSetTarget( aTarget: Sprite ): void;

		function glBegin( rasterMode: int ): void;
		function glEnd(): void;

		function glPresent( aTarget: Sprite = null ): void;
	}

	/**
	 * OpenGL-like interface for a generic 2D rasterizer.
	 * The triangle is the only supported polygon right now
	 *
	 * More desc for me..
	 */
	public interface IRasterizer2D extends IRasterizer
	{
		function glVertex( vertex: Vertex2, uv: Vertex2 ): void;
	}

	/**
	 * OpenGL-like interface for a generic 3D rasterizer.
	 * The triangle is the only supported polygon right now
	 *
	 * More desc for me..
	 */
	public interface IRasterizer3D extends IRasterizer
	{
		function glVertex( vertex: Vertex3, uv: Vertex2 ): void;
	}
}

Portions of the actual wobble animator took inspiration from the previous Magic Carpet demo and some stuff i found on the net: if you come up with some other effects let me know, i’ll be happy to link back to them!
Here you can play with a basic demo i setup to try it out or get the source code to do your own experiments:

[kml_flashembed allowAccess="true" movie="http://manuel.bit-fire.com/code/wobble_demo.swf" width="100%" height="480" /]

Hoorah. Hoorah.

Basically, it’s a brutally stupid, slogan-centric three-points-nothing-more way to express the act of developing software: “1. Develop, 2. Test, 3. Distribute“.

That’s the real program:

1. You pay, you get the iPhone, note this is not part of the program;
2. You pay, they let’s you develop (to do this you must have a Mac/Intel, not part of the program);
3. You pay, they let’s you test on the device at point 1;
4. You pay, they let’s you distribute it;
5. You distribute, you could possibly earn something, they earn (30%) from this too, damn, again!

Let me analyze it a bit:

1. Apple wanna grow, make big money and get some important user-base;
2. Users come if the platform has something interesting to offer;
3. A good platform-enrichment thing could be some software;
4. Software possibly needs to be developed (sometimes it also has to be 2. deployed and tested on the real device, and ultimately i heard someone also tried to 3. sell it);
5. Software developers, thus, are needed (they’ll invest money, time, patience and experience, just to develop);
6. Apple needs developers;
7. I. Already. Heard. That.
8. Developers decide to support the platform and write/port software for it (best case);
9. Developers willing to support the platform, implicitly favoring Apple and it’s platform, are asked to pay for doing this;

Fortunately, there are great ways to overcome the need to make a living out of bread and onions: make an i-Developer a favor and make sure to get him to know about this, this, also this, this one too, and.. this.

Oh. And this.

In fact, the past year has been really busy: work and daily life take so much that sometimes you have to fight with yourself to squeeze out every possible free minute to do your own things, so one whole year has gone, but this doesn’t mean i don’t have something to write about, even better, i struggled to post about it from September, and i really mean September 2007, but better late than never!

But what did i do in all this time without even posting a blank post in 300 days? Well, in fact, we are not dead for sure, i’m working really hard on the cross-platform framework of some posts ago and we hope to be able to work full-time on the game idea we had in the past and, best of all, on the iPhone!

Some time ago i was asked to publish my implementation of fixed-point math, mainly regarding embedded architectures where IEEE floating point computations have really bad performances. What i want to give you here is a pure-c++, template-based implementation of a fixed-point datatype: this thing is more of a test in order to see how much an object-oriented implementation can perform, being in contrast to a more traditional implementation. As expected, operator overloading and temporary object creation overhead are the main issues with a full-oo implementation as this one, anyway, its a damn nice way to exercise yourself in writing c++ policy-based templated code ;)

Big thank you goes to Kurt for having a great discussion with me on c++, math and for recommending me the most wonderful book on computer arithmetic as Hacker’s Delight delivers it in spades!
Back to the fp stuff: usage of this code in testing environments is advised, since it could contain rounding errors and sometimes explicit casts are needed to get it to work correctly; as i said, this was some sort of test, i abandoned the O-O idea when i ack the performances’ gap between OO vs. traditional implementation was remarkable (at least on embedded devices).
Before showing some usage guidelines, i should say that using this datatype on a desktop machine hasn’t much sense: nowadays floating-point math is faster than the integer’s one!
The class itself predefines a 24.8 and a 16.16:

typedef AquaFixed< 8, LowPrecision,  LowPrecision> fixed8_t;
typedef AquaFixed<16, HighPrecision, HighPrecision> fixed16_t;

An usage example could be a generic, datatype-unaware Matrix implementation as this one:

template<class Number>
class matrix {
private:
Number m[4][4];
public:
matrix();

// matrix indexing
inline Number&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; operator()(const int,const int);

// matrix operations
matrix<Number> operator*(const matrix<Number>);
matrix<Number> operator/(const matrix<Number>);
};

Doing it this way, you should be able to declare a Matrix as here and perform your own tests:

matrix<float_t> float_matrix;
matrix<fixed16_t> fixed_matrix;

NOTE! The AquaFixed class comes out straight from my framework, so you’ll have to define basic datatypes such as int32_t/int64_t for yourself, but that shouldn’t be a problem.

Get the code here and let me know of your tests!

I’m currently working on an early-stage, more of a proof-of-concept thing, but i needed to know more about the code performances: googling for an ActionScript profiler just showed up ASProf, an AS2 profiler. So i decided to port to AS3 the C++ profiler i wrote for Aqua, the cross-platform framework i was working on until April: the original C++ implementation has been developed after being inspired by an article of Steve Rabin in the Game Programming Gems 1 book, that’s a nice one to have on the shelf together with some other great books of which i could post something about them later.
It is always wise to remember that if you are serious about code profiling, you’ll be better to search for some professional tools: in the C++ arena my choice would be this one, but if you plan to have lunch and dinner for the next couple of months give Eletric’s one a try, it really deserves a look.
Unfortunately for the AS3 world, i just haven’t found anything really usable for it up to now, so i just thought to release it under a zlib/png license and some hints on how it works here.

ProfilerConfig.Width = stage.stageWidth;
ProfilerConfig.ShowMinMax = true;
prof = new Profiler( 32 );
addChild( prof );

Setup some custom configuration parameters and then create a Profiler and don’t forget to add it to your local render queue: the Profiler its a Sprite and it will render the results right there, all you have to do now is to profile some code:

var i: int = 0;
var it: int = 1000000;

prof.beginProfiling();

i = it;
prof.begin( "fadd" );
while( i-- ) { fRes += 1.; }
prof.end( "fadd" );

i = it;
prof.begin( "iadd" );
while( i-- ) { iRes += 1; }
prof.end( "iadd" );

i = it;
prof.begin( "fsub" );
while( i-- ) { fRes -= 1.; }
prof.end( "fsub" );

i = it;
prof.begin( "isub" );
while( i-- ) { iRes -= 1; }
prof.end( "isub" );

prof.endProfiling();

With another couple of lines of code you’ll end up with something like this:

Cool graphing for your function-timing needs ;)
And this is it!
A thing i may point out is that you can always group code fragments belonging to your most logical schema by wrapping the same ProfileNode around the different fragments; here i’m grouping math operations by their type, just to keep the call-graph a little bit organized:

var i: int = 0;
var it: int = 1000000;

prof.beginProfiling();

i = it;
prof.begin( "float", true );
prof.begin( "fadd" );
while( i-- ) { fRes += 1.; }
prof.end( "fadd" );
prof.end( "float" );

i = it;
prof.begin( "int", true );
prof.begin( "iadd" );
while( i-- ) { iRes += 1; }
prof.end( "iadd" );
prof.end( "int" );

i = it;
prof.begin( "float", true );
prof.begin( "fsub" );
while( i-- ) { fRes -= 1.; }
prof.end( "fsub" );
prof.end( "float" );

i = it;
prof.begin( "int", true );
prof.begin( "isub" );
while( i-- ) { iRes -= 1; }
prof.end( "isub" );
prof.end( "int" );

prof.endProfiling();

That’s all there is to it, hope it will be useful!
Grab the Profiler here and take a look at the demo code used for this post.

• it seems that image-type function parameters are bound to the selected images according to their alphabetical order, instead of the natural user-defined one: for instance, create a new kernel as here, select two images and refresh; you should be now looking at the image you loaded via “Load Image 2…”: now rename “in image4 srca” to be “in image4 srcc” and refresh. Wrongly, you are now looking at the first image
• the GUI doesn’t release cpu/gpu resources while minimized in order to relieve the machine from the rendering process

Aside that, i’m looking forward to try all this cool stuff with Astro!

I had some difficulties installing the package since it was keep asking to terminate another Adobe installation, anyway i managed to install the beast and give it a try: i wanted to simulate a “glassy look-through” effect (as you are watching something outside of a glass door): it goes without saying there is the need to use some of the “region needed” magic in order to crop the black borders out, but i have no time at the moment, so here it is.
In order to use this filter you’ll have to download the kernel source and these three images:

Basically, once you launched the AIF Toolkit, you load the hydra source, then the shower as the first image, and then choose one of the two normal maps as the second image, press F5 and try play with the parameters.

Here is the difference in rendering between Flash Player versions (image):

I have no way to tell if it is the cause of the singularities i talked about in my previous posts (vertical bar / mid-height correct), nevertheless they perform differently.
Anyone can confirm me this behavior?

Demo (swf):

[kml_flashembed movie="http://manuel.bit-fire.com/wp-content/uploads/2007/08/bmptest.swf" width="150" height="120" /]

Sources