ich habe mal jüngst angefangen, mich wieder ein wenig mit isometrischer Darstellung zu beschäftigen. Vielleicht kriege ich eine kleine isometrische 3D Engine hin, mal sehen. Der Unterschied zu anderen Engines ist, dass ich meine Objekte nicht programmatisch zeichne,
sondern nur bestehende Objekte mithilfe der Transformationsmatrix von Flash verzerre.

Bei folgendem kleinen Beispiel ist es denn auch so, dass die drei Flächen schon existieren und nur noch durch mein Skript transformiert werden.

Wie man sehen kann, stimmt die Z-Sortierung noch nicht. Darum kümmere ich mich als nächstes. Auch sind sicher die Formeln noch nicht so rank und schlank, wie sie sein könnten. Der Code ist momentan noch recht übersichtlich:

import flash.geom.Matrix;
var i:Number = 0;
var radius:Number = -75;
var cosI:Number;
var sinI:Number;
this.onEnterFrame = function() {
   wall.transform.matrix = transformSurface(0,300,50);
   floor.transform.matrix = transformSurface(1,300,300);
   ramp.transform.matrix = transformSurface(0.5,300,150);
   i += 0.01;
}
function transformSurface(angle:Number, i_x:Number, i_y:Number):Matrix {
   var trMatrix:Matrix = new Matrix();
   cosI = Math.cos(i);
   sinI = Math.sin(i);
   trMatrix.a = cosI;
   trMatrix.b = sinI*0.5;
   trMatrix.c = -sinI*angle*(1+Math.sin(angle*Math.PI)*0.25);
   trMatrix.d = ((cosI*0.5*angle)+(1-angle))*(1+Math.sin(angle*Math.PI)*0.25);
   trMatrix.tx = (cosI*radius)+i_x;
   trMatrix.ty = (sinI*(radius/2))+i_y;
   return trMatrix;
}

nicht unbedingt neu aber interessant finde ich die Möglichkeit, Klassendefinitionen in Objekten oder Arrays zu referenzieren, um sie später zur Instanzierung zu verwenden. Beispiel:

var qeue:Array = new Array();
qeue.push(de.bla.FirstClass);
qeue.push(de.bla.SecondClass);
qeue.push(de.bla.ThirdClass);
var oneInstance:Object = new qeue[0]();

Wem nicht gefällt, dass oneInstance jetzt nur ein Object ist, der könnte zum Beispiel ein Interface schreiben, welches die drei Klassen dann implementieren.

Autocompletion, welch ein Segen. Es hat ja so mit Flash 7 und den Actionscript 2 Klassen langsam angefangen, ich kann gar nicht mehr genau so sagen wann, aber da kamen die ersten Editoren mit Auto-Vervollständigung innerhalb von Actionscript 2.0 auf. Ich benutze ja nun schon seit einiger Zeit FlashDevelop und ehrlich, ich kann mir gar nicht mehr vorstellen, wie das vorher ohne war (doch kann ich, wenn ich in seltenen Fällen mal eben kurz was direkt in der Flash IDE ausprobieren will).

Was ich interessant finde ist, dass mit der Autocompletion sich auch der Programmierstil verändert. Habe ich früher noch immer möglichst kurze und knackige Funktions- oder Variablennamen verwendet, damit man nicht soviel tippen muss, konzentrier ich mich heute viel mehr darauf, dass die Namen sprechend sind, denn tippen muss ich sie ja nicht mehr, macht ja die Autocompletion.

Auch beobachte ich mich dabei, dass ich viel häufiger Konstanten (also pseudo-Konstanten, weil gibbed ja nich in AS) für häufig benötigte Werte oder Strings schreibe, weil dann brauch’ ich die auch nicht mehr tippen.

Auch mach ich nur noch selten davon Gebrauch, einfache Objekte zu erstellen um dort Attribute zu setzen, sondern vielmehr schreibe ich schnell kleine Klassen, in denen ich die Attribute fix deklariere, weil dann zeigt mir später die Autocompletion gleich alle möglichen Attributnamen und ich muss wieder nix tippen. Und wenn dann der Name doch mal nicht sprechend genug war, dann sieht man ja noch den javadoc (pardon, asdoc) Kommentar.

Ach ja, Autocompletion, ‘s schon schön …

in diesem Beitrag hatte ich beschrieben, dass eine Klasse in einer Runtime Shared Library eventuelle Pendants in Hauptfilmen, die diese RSL benutzen, überschreibt. Das war in Flash 7 auch so. Nicht so allerdings in Flash 8. Hier verhält sich die RSL jetzt genauso wie ein normal geladener Film. Die bestehende Klasse im Hauptfilm wird immer beibehalten.

Wir schreiben eine Klasse ‘Superklasse’, in der steht folgendes:

class Superklasse {
   private var name:String = "Superklasse";
   public function Superklasse(msg:String) {
      trace("Konstruktor von " + name + " spuckt: " +  msg);
   }
}

Und wir schreiben noch eine Klasse ‘Unterklasse’, in der soll folgendes stehen:

class Unterklasse extends Superklasse {
   private var name:String = "Unterklasse";
}

So, jetzt erstellen wir eine .fla und schreiben im ersten Frame einfach folgendes:

var testchen:Unterklasse = new Unterklasse("Hallo");
var testchen:Superklasse = new Superklasse("Hallo");

So und nun mal raten, was kommt raus?

Konstruktor von Unterklasse spuckt: undefined
Konstruktor von Superklasse spuckt: Hallo

Was sagt uns das? Das fehlen des Konstruktors in der Unterklasse bewirkt zwar wie gewünscht, dass der Konstruktor der Superklasse verwendet wird, wegen Vererbung und so, aber der Parameter kommt nicht mit. Kann mir das einer erklären?

Umgehen lässt sich das Problem nur, indem man einen super() enthaltenden Konstuktor implementiert:

class Unterklasse extends Superklasse {
   private var name:String = "Unterklasse";
   public function Unterklasse(msg:String) {
      super(msg);
   }
}

Dann kommt auch der Parameter durch. Ach ja, Flash …

was passiert eigentlich, wenn zwei Movieclips in sich die gleiche Klasse kompiliert bergen und der eine Film den anderen lädt? Welche Klasse wird von welcher überschrieben? Das haben Lars und ich uns gefragt und folgendes herausgefunden:

Folgendes Szenario:
Wir erstellen einen Testordner, darin einen weiteren Ordner mit dem Namen ‘B’. Im Testordner selbst erstellen wir eine .fla mit dem Namen ‘A’ und im Ordner ‘B’ eine .fla mit dem simplen aber praktischen Namen ‘B’. Ausserdem erstellen wir im Testordner die Klasse mit dem Namen ‘Testklasse’. Sie enthält weiter nichts ausser ihrem Konstruktor, der selbst nichts anderes verrichtet, als: “Ich bin A” zu tracen. Die Klasse kopieren wir in den Ordner ‘B’ und ändern dort den trace zu: “Ich bin B”.

So, nun müssen wir noch dafür sorgen, dass in beiden .fla’s die jeweilige Klasse kompiliert wird, was man mit einem einfachen ‘Testklasse;’ erreicht. Zusätzlich muss Film A noch per createEmptyMovieClip und loadMovie Film B in sich hineinladen.

Flugs kompiliert das ganze, und was spuckt die Ausgabe aus: “Ich bin A”. Das ist mal interessant. Ein hineingeladener Film, der selber die gleiche Klasse in sich trägt, überschreibt die vorhandene Klasse des Hauptfilms nicht.

Das hätte uns fast gereicht, aber wir haben trotzdem noch was anderes getestet. Jetzt binden wir Film B mal als RuntimeSharedLibrary ein und was passiert nun: “Ich bin B”. Wär’ ja auch zu einfach gewesen. Klassen, die in einer RuntimeSharedLibrary sitzen, überschreiben sehr wohl ihre Doubles im Hauptfilm.

Das ist durchaus wichtig zu wissen, wenn man sich fragt, was man alles kompilieren muss, damit eine Änderung zu Tage tritt. Noch besser ist hier die Verwendung von exclude XML Dateien, die verhindern, dass bestimmte Klassen in bestimmte Filme kompiliert werden.

Exclude Dateien haben nur leider einen Haken: Wenn man eine bestimmte Klasse in einen Film kompilieren möchte, muss man auch immer alle Superklassen, von denen diese Klasse – auch indirekt – erbt, mit kompilieren. Sprich, man darf sie nicht exkludieren. Denn Flash kann sonst die Verknüpfung nicht mehr herstellen. Das gilt auch für Interfaces.

ein Thema, was schon hundertmal durchgekaut wurde, zumindest in anderen Programmiersprachen und welches jetzt auch in Flash, wo wir sowas lustiges wie Wenn-Du-willst-gerne-aber-muss-auch-nicht-Typisierung haben.

Also, warum das ganze? Folgendes Szenario: Wir haben eine Template Klasse, die soll später mal eine Seite anzeigen. So eine Seite besteht aus lauter lustigen Komponenten, also Bildern, Headlines, Links, Texten, Videos usw. Da all diese Komponenten bestimmte grundlegende Funktionen wie z.B. das Setzen des Inhalts (der Text, die Url des Bildes, die Url des Links usw.) benötigen, sehen wir eine allgemeine Klasse ‘Component’ vor. Die konkreten Komponenten erben dann von dem Ding. Eine Link Klasse würde dann wahrscheinlich neben vielen anderen Funktionen vielleicht noch sowas wie setHighlight() implementieren, nur mal als Beispiel.

So, unsere Template Klasse benötigt nun, warum auch immer, ein Array, in dem alle für diese Seite verwendeten Komponenten referenziert werden, nachdem sie erzeugt wurden. Intern hätte die Klasse also ihr Array:

private var _components:Array;

Und wir brauchen auch noch eine Funktion zum Hinzufügen von Komponenten und eine zum Herausnehmen:

public function setComponent(newComp:Component):Void{...}
public function getComponent(index:Number):Component {...}

So. Der Parameter und der Rückgabewert der einen bzw. der anderen Funktion muss natürlich vom Typ Component sein, denn es sollen ja alle möglichen Komponenten eintragbar sein.

So und jetzt geht’s schon los. Angenommen, ich habe jetzt eine Link-Komponente erzeugt und will sie nun eintragen:

var myLink:Link = new Link();
setComponent(myLink);

Jetzt fragt man sich vielleicht: “Moment, setComponent will doch vom Typ Component, warum geht das jetzt mit dem Link?” Weil Flash hier ein implizites Typcasting macht, sprich es ist immer erlaubt, vom Speziellen ins Allgemeine umzuwandeln und da muss man auch nix besonderes machen, das passiert dann einfach bei der Zuweisung bzw. in unserem Fall beim Funktionsaufruf.

Anders wäre es jetzt, wenn wir den umgedrehten Fall hätten. Angenommen also, unser Template wollte nur Links im Array speichern, dann würden wir sowas schreiben:

public function setLink(newLink:Link):Void{...}

Wenn wir nun eine Komponente vom Typ ‘Component’ erzeugen und zuweisen wollten, würde das schiefgehen:

var myComp:Component = new Component();
setLink(myComp); // Compiler würde hier 'Typdiskrepanz' melden

Macht ja auch Sinn, denn nicht jede Komponente ist mit einem Link kompatibel, hingegen ist jeder Link immer auch eine Komponente.

Es gibt aber Fälle, wo wir einfach wissen, dass unser Objekt vom Typ ‘Component’ eigentlich ein Link ist. Betrachten wir folgenden Verlauf:

var myLink:Link = new Link();
setComponent(myLink);
// So, jetzt also nur dieser Link im Array. weiter geht's.
var myOtherLink:Link = getComponent(0);
// ähh, geht nicht. getComponent liefert vom Typ Component,
// wir brauchen aber Link.

Ja, hier ist das Problem also noch mal illustriert. Jetzt ist das ja blöd, weil wir wissen ja, dass wir da einen Link reingetan haben, nur Flash weiss das nicht, Flash sieht nur, wir wollen einen ‘Link’, aber getComponent() liefert vom Typ ‘Component’. Wenn man sich also wirklich sicher ist, dass man eigentlich den richtigen Typ hat, kann man einen Typcast versuchen. Man schreibt dann also:

var myLink:Link = new Link();
setComponent(myLink);
// So, jetzt also nur dieser Link im Array. weiter geht's.
var myOtherLink:Link = Link(getComponent(0));

Jetzt haben wir Flash also explizit (deswegen hier auch explizites Typcasting, weil nicht automatisch) angewiesen, die Referenz auf das Objekt, welches getComponent liefert zuzulassen, weil wir wissen, dass sich dahinter ein Link verbirgt. Wenn es kein Link wäre, würde Flash hier nur ‘null’ liefern.

So, das war das. Ach übrigens, dieser ganze Spass gilt so nur für Objekte. Es gibt ja noch die primitiven Datentypen, wie einen String, womit ich nicht die String Klasse meine, sondern einen String selbst. Bei den primitiven Datentypen gibt es auch Typenumwandlung, allerdings findet hier tatsächlich eine Konvertierung statt, während wir da oben ja nie was konvertiert, sondern nur die Typdefinition angepasst haben.

wieder mal so’n bug, den Kollege Lars und ich neulich entdeckt haben:

FireFox und Mozilla bzw. wahrscheinlich eher das Flash Plugin für diese Browser unterstützt das Event onLoadError vom MovieClipLoader nicht. Bei anderen Browsern haben wir’s noch nicht getestet. Alle anderen Events vom MovieClipLoader funktionieren.
Tja …
(Nachtrag: bei Flash 8 geht’s)

meineInstanz["falscheVariable"]

erkennt das Flash und ruft ebenfalls __resolve() auf. Geschummle ist also nicht mehr möglich.
Dachte ich. Aber weit gefehlt. Wenn man

meineInstanz["falscheVariable"];

schreibt, wird zwar __resolve() aufgerufen, wenn man aber ganz frech eine Zuweisung macht, z.B.

meineInstanz["falscheVariable"] = "Hallo";

dann wird __resolve() nicht aufgerufen. Die Variable wird dann einfach erzeugt.
Damit kann man also immer noch zur Laufzeit mogeln und einer an sich nicht dynamic deklarierten Klasse Variablen zuschieben.
Schade eigentlich.

interface SimpleMovie {
   public function machWas():Void;
}

Hier die Klasse MovieClip1:

class MovieClip1 extends MovieClip implements SimpleMovie {
   public function machWas():Void {
      trace("MovieClip1 schreit.");
   }
}

Dann hatte ich ein Factory Klasse geschrieben, die jetzt für ihren Client einen MovieClip vom Typ MovieClip1 erzeugen sollte, nach dem Factory Design Pattern Prinzip(unwichtiges habe ich hier aus Platzgründen weggelassen):

class MovieFactory {
   public function getSimpleMovie():SimpleMovie{
      var tempMovie:SimpleMovie;
      tempMovie = _root.attachMovie("movie1", "someMovie", 1);
      tempMovie._x = 100;
      tempMovie._y = 100;
      return tempMovie;
   }
}

So, nu’ hat dann irgendwann meine ClientKlasse, die ja auch einen SimpleMovie haben will, gesagt: ‘var meinMovie:SimpleMovie = getSimpleMovie();’. Und dann hat natürlich, wie mir jetzt ja auch auch klar ist, der Compiler gesagt, moment mal hat er gesagt, is’ nich’, weil Typ MovieClip ist ja nicht gleich SimpleMovie.
Hää, denk’ ich? Der MovieClip, den ich attached habe, ist vom Typ MovieClip1 und da er SimpleMovie implementiert, müsste Flash das doch typcasten können?!
Nee, ganz falsch, weiß ich nun. Zum Ersten liefert attachMovie immer einen MovieClip als Rückgabewert zurück und die allgemeine Klasse MovieClip implementiert ja nun mal kein interface SimpleMovie, da kann man also auch nix casten. Und dann castet Flash auch schon mal gar nicht mal so eben von selbst, das muss man schon selber machen.
Also ändert man sein Skript dahingehend:

class MovieFactory {
   public function getSimpleMovie():SimpleMovie{
      var tempMovie:MovieClip1 = MovieClip1(_root.attachMovie("movie1", "someMovie", 1));
      tempMovie._x = 100;
      tempMovie._y = 100;
      return SimpleMovie(tempMovie);
   }
}

So, jetzt casted man als erstes mal nach MovieClip1, was ja vollkommen in Ordnung ist, weil wir haben dem Symbol ja genau diese Klasse zugewiesen und nur die Tatsache, dass Flash immer allgemeine MovieClips zurückgeben will, soll uns da nicht schrecken. Und dann casten wir beim return noch in SimpleMovie, was auch OK ist, weil ja die Klasse MovieClip1 das interface SimpleMovie implementiert und man deswegen auch zu diesem Typ casten kann.
Ja und nu’ klappt alles. Herrlich. Fragt sich nur, warum soviel Aufwand für’n blöden MovieClip …