Problem mit Terrainübergängen

Hallo,
Ich arbeite derzeit wieder mal ein wenig an einem nicht endend wollenden Problem. Ich hatte vor gehabt, eine Karte zu entwickeln, welche weiche Übergänge zwischen 2 Terraintypen errechnet. Oder eher gesagt das bild errechnet, welches dann angezeigt werden soll.
Dazu gibts ja bei Gamedev ein Tutorial ( www.gamedev.net/reference/programming/features/terrain_trans/page2.asp ), aber die gehen leider nur auf die Organisation der Übergänge ein und verlieren kein Wort darüber, wie man denn schnellst möglichst das gewünschte Bild bekommt.
Meine Bilddaten sind genauso aufgebaut, wie in diesem Tutorial beschrieben.
Also Hilfe hier mal ein kleines Ascii-Bild
|16| 2 |32
-----------
| 1 | x | 4
-----------
128| 8 |64
Das kommt daher, wie es auch im Tutorial steht, dass die Ecken die letzten 4 bits belegen und die Kanten die ersten 4 bits. (auf dem Feld mit dem X soll der Übergang berechnet werden)
So das umrechnen ist auch kein Ding, was ich so gelöst hab:

int corners = transitionNumber >>> 4; //right shift ohne Vorzeichenbeachtung
int edges = transitionNumber & 15;
So nun hat man zwar die Bilder, welche rein theoretisch passen würden, aber es darf ja nicht immer eine Ecke gezeichnet werden, wenn da schon eine Kante liegt und somit da schon eine Überblendung vorhanden ist. Aber irgendwie ist dies genau das Problem, wo ich nicht weiter komme.
Ich dachte erst, dass ich es einfach mittels

corners = (corners ^ edges) & corners;
raus bekommen würde. Leider haben mir da gewisse Konstellationen ein Strich durch die Rechnung gemacht.
Wenn ich zum Beispiel dieses Bild errechnen müsste:
y|x|y
------
y|x|y
------
y|x|y
(mittleres Feld soll wieder überblendet werden)
Dann liefert meine so sicher geglaubte Formel totalen Blödsinn. Für diese Überblendung wäre die Bitmaske am Anfang 1111 1010 und es müsste sinngemäß 0000 1010 raus kommen. Aber es kommt durch (1111 XOR 1010) & 1111 = 0101 die Bitmaske 0101 1010 raus und nun werden da unschöne Ecken hingemalt, wo keine sein dürften (ich habs deutlich gesehen, weil bei mir die Ecken erst nach den Kanten gerendert werden).
Hatte schon jemand mal Erfahrung in diesen Dingen oder sieht auf einen Blick, wie ich diese jeweils 4 bit kombinieren muss, damit das raus kommt, was ich will?
PS.: Ich hoffe ihr versteht was ich meine

Momentaner "State of the Art" was Terrain Texturing angeht ist das sogenannte "Splatting":
www.cbloom.com/3d/techdocs/splatting.txt
Lässt sich auch gut als offline processing in Software umsetzen.

Hier sind sogar ein paar Grafische Beispiele dabei:
www.gamedev.net/reference/articles/article2238.asp

Jo das ist aber für mich nicht nutzbar, nur weil ich hier gerade irgendwas mit rendern und so schreibe( es ist nur der Map-Editor), heißt es nicht, dass es nicht doch in ein Browsergame soll und da soll dies per Javascript berechnet werden. Sonst hätt ich das andere schon längst genutzt

Du mißverstehst uns.
Dein Editor kann diese Tiles erzeugen und auf der Platte für einen Grafikpack o.ä. bereit stellen.
So mußt du nicht alle Grafiktiles selbst zeichnen, sondern kannst diese Übergänge per Software erzeugen lassen.
Das macht man 1x und nicht laufend per JavaScript auf dem Client
Abgesehen davon, kannst du mit CSS und Co. einen Teil dieser Features eh im Client sogar realisieren. Wobei du hier absolut wieder abhängig wird den Möglichkeiten des Clients wirst.
Da dann lieber 1x irgendwo anderst erzeugt und halt ein größeres Grafikpack dann im Hintergrund haben.

So fallen aber viele Grafiken an, die eventuell vom Server zu laden sind. Dummerweise multipliziert sich das mit jedem neuem Terraintyp.
Einfacher wäre es transparente PNGs zu erstellen. Also für jede Möglichkeit Ecke/Kante der Textur mit Alpha-Übergang und darunter die 2. Textur. Problematisch wird es, wenn auf der anderen Seite eine andere Textur anfängt, dann müsste man noch eine 3. Grafik darunter legen etc.

Ok ich glaube ihr missversteht mich alle - ausser Klaus vielleicht nicht.
Genau so, wie Klaus es meint fabriziere ich es derzeit. Ich hab ne Sammlung aus PNG-Elementen (Sicher man könnte dies in der Zukunft per Programm erstellen lassen) und lege diese dann über die Grundtextur (die von dem Feld x).
Mir geht es nun nicht darum, wie man solche Texturen am Besten erstellt, sondern wie man sie am Besten auswählt.
Nehmen wir das Bild von dem Tutorial was ich gepostet hab und stelle sich vor, dass dies ein großes PNG-Bild mit Transparenz ist, welches alle möglichen Übergänge beinhaltet.
Nun hab ich die zwei Variablen "corners" und "edges", worüber ich die passende Ecke oder die passende Kante in diesem großem PNG-Bild auswählen kann. Nur das Problem ist, dass man manchmal keine Ecke zeichnen darf, weil da schon eine Kante ist (das Beispiel mit den xen und yen).
Nun will ich kein großes switch()-Konstrukt basteln, sondern suche nach einer Möglichkeit, die Variable corners so zu verändern, dass die Ecken auch wirklich nur angezeigt werden, wenn sie Sinn machen.
Hier mal ein so ein Tileset (bitte net lachen, aber dies ist nur zum Testen erstellt worden )
img162.imageshack.us/img162/1073/tilestl6.png
Die Kante bekomm ich einfach über (edges*width, 0, edges*width+width, height) raus und die Ecke über (corners*width, height, corners*width, 2*height). Das ist aber nicht wirklich das Problem, sondern halt nur das, dass es bei manchen Konstellationen meine Umrechnung der Ecken nicht hin haut und Ecken angezeigt werden (corners != 0), wo keine sein dürfen(Beispiel im Anfangsposting).
(PS.: das ist den Klammern soll ein Rechteck (x1, y1, x2, y2) beschreiben )
Deswegen frag ich ja, ob jemand schonmal sowas gemacht hat und es vielleicht diverse Bitoperationen gibt, welche dies beheben könnte, weil (corners XOR edges) AND corners nicht klappt