Jetzt müssen wir nach oder umstellen und in die entsprechende Parametergleichung einsetzen um einen Schnittpunkt zu errechnen:

1. Fall :
   
   1. Fall :
      
      Schnittpunkt berechnet.
   2. Fall :
      
      1. Fall:
         
         Geraden 1 und 2 sind parallel, schneiden sich also nicht.
      2. Fall:
         
         Gerade 2 hat keine Richtung, Geraden schneiden sich also nicht.
2. Fall :
   
   1. Fall:
      
      Schnittpunkt berechnet.
   2. Fall:
      
      Gerade 1 und 2 sind parallel, schneiden sich also nicht.

Zur Demonstration der bisherigen Lösung habe ich ein kleines Programm geschrieben, in welchem man sich die berechnete Lösung für beliebe Ausgangssituationen anzeigen lassen kann. Man sieht, dass nicht wirklich vorhandene Kollisionen nun nicht mehr fälschlicherweise „korrigiert“ werden.
Screenshot:

Bedienung :
Linke Maustaste, Drag&Drop : roter und schwarzer Kreis, Enden der schwarzen Linie
Rechte Maustaste, Drag&Drop : Bildschirmausschnitt
Mausrad : Zoomen

Ausprobieren: win-06.02.2011-21.09

Relevante Quellcodeausschnitte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

bool TestBoundedMovement::DoLineSegmentsIntersect( sf::Vector2f s1, sf::Vector2f e1, 
	sf::Vector2f s2, sf::Vector2f e2 )
{
	sf::Vector2f v1 = e1 - s1;
	sf::Vector2f v2 = e2 - s2;
	sf::Vector2f intersection;
	if ( LinesIntersection( s1, v1, s2, v2, intersection ) ) {
		float k = LineParam( s1, v1, intersection );
		float m = LineParam( s2, v2, intersection );
		if( ( m >= 0 ) && ( m <= 1 ) &&
			( k >= 0 ) && ( k <= 1 ) ) {
			return true;
		} else {
			return false;
		}
	}  else 
		return false;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

bool TestBoundedMovement::LinesIntersection( sf::Vector2f s1, sf::Vector2f v1, 
	sf::Vector2f s2, sf::Vector2f v2, sf::Vector2f &intersection )
{
	if( v1.x != 0 ) {
		float a = v2.x * v1.y / v1.x - v2.y;
		if( a != 0 ) {
			float m = ( s2.y - s1.y - ( s2.x - s1.x ) * v1.y / v1.x ) / a;
			intersection.x = s2.x + m * v2.x;
			intersection.y = s2.y + m * v2.y;
			return true;
		} else {
			return false;
		}
	} else {
		if ( v2.x != 0 ) {
			float m = ( s1.x - s2.x ) / v2.x;
			intersection.x = s2.x + m * v2.x;
			intersection.y = s2.y + m * v2.y;
			return true;
		} else {
			return false;
		}
	}
}

1
2
3
4
5
6
7
8
9
10

float TestBoundedMovement::LineParam( sf::Vector2f s, sf::Vector2f v, sf::Vector2f p )
{
	float k = 0;
	if( v.y != 0 ) {
		k = (p.y - s.y) / v.y;
	} else if ( v.x != 0 ) {
		k = (p.x - s.x) / v.x;
	}
	return k ;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

void TestBoundedMovement::UpdateCorrectDest()
{
	sf::Vector2f s = myCircleStart.GetPosition();
	sf::Vector2f v = myVector;
	sf::Vector2f pl1 = myLineBound.GetP1();
	sf::Vector2f pl2 = myLineBound.GetP2();
 
	sf::Vector2f z = s + v;
 
	sf::Vector2f ng0;
	sf::Vector2f nh0;
	if ( MathUtils::VectorLen(v) == 0 ) {
		myCircleCorrectDest.SetPosition( z );
		return;
	}
	sf::Vector2f v0 = v / MathUtils::VectorLen(v);
 
	if ( MathUtils::ComputeNormal( pl1, pl2, ng0 ) &&
		 MathUtils::ComputeNormal( s, z, nh0 ) ) {
 
		float r = radius;
 
		if( ! DoLineSegmentsIntersect( s + nh0 * r, 
		                               z + v0 * r + nh0 * r, 
		                               pl1, pl2 ) &&
		    ! DoLineSegmentsIntersect( s - nh0 * r, 
		                               z + v0 * r - nh0 * r, 
		                               pl1, pl2 ) &&
		    ! DoLineSegmentsIntersect( z + v0 * r + nh0 * r, 
		                               z + v0 * r - nh0 * r, 
		                               pl1, pl2 )) {
			//Bewegungslinie und BoundLine überschneiden sich nicht,
			//also wird keine Kollisionserkennung vorgenommen,
			//also ist myCircleCorrectDest = myCircleDest
			myCircleCorrectDest.SetPosition( z );
			return;
		}
 
		if( MathUtils::DotProduct( v, ng0 ) > 0 ) {
			//Bewegungsvektor zeigt von BoundingLine weg,
			//also wird keine Kollisionserkennung vorgenommen,
			//also ist myCircleCorrectDest = myCircleDest
			myCircleCorrectDest.SetPosition( z );
			return;
		}
 
		if( MathUtils::DotProduct( s - pl2, ng0 ) < 0 ) {
			//Der Startpunkt liegt hinter der Line
			//also wird keine Kollisionserkennung vorgenommen,
			//also ist myCircleCorrectDest = myCircleDest
			myCircleCorrectDest.SetPosition( z );
			return;
		}
 
		float d = ( MathUtils::DotProduct( z - pl2, ng0 ) );
 
		if( d >= r ) {
			//Es findet gar keine Kollision statt
			//also ist myCircleCorrectDest = myCircleDest
			myCircleCorrectDest.SetPosition( z );
			return;
		}
 
		float cosAlpha = MathUtils::DotProduct( v, pl2 - pl1 ) / 
				( MathUtils::VectorLen( v ) *  
				  MathUtils::VectorLen( pl2 - pl1 ) );
 
 
		float sinAlpha = sqrt( 1 - cosAlpha * cosAlpha );
 
		if( sinAlpha != 0 ) {
			float x = ( r - d ) / sinAlpha;
 
			sf::Vector2f z2 = z - x * v0;
			myCircleCorrectDest.SetPosition( z2 );
		}
	} else {
		//Normale konnte nicht berechnet werden, 
		//also liegen pl1 und pl2 auf einem Punkt,
		//also ist BoundingLine nicht vorhanden,
		//also ist myCircleCorrectDest = myCircleDest
		myCircleCorrectDest.SetPosition( z );
	}
}

Übersicht:

1. Problem
2. Lösungsansatz
3. Die Lösung
4. Geradenschnittpunkt
5. Parametergleichung umgekehrt
6. Ende und Demo

Das Problem

Beim Herumspielen mit dem Demoprogramm fällt schnell auf, was wir noch beachten müssen. Die Kollision wird selbst dann berechnet, wenn die Bewegung gänzlich außerhalb der Begrenzungskante verläuft, wie hier veranschaulicht:

Dabei wäre die unkorrigierte Zielposition die korrekte. Wir müssen also entscheiden, ob eine Bewegung eine Begrenzungskante berührt oder nicht.
Dazu könnten wir einfach den Schnittpunkt der Geraden und bestimmen und überprüfen, ob dieser innerhalb der Strecke zwischen und liegt. Wenn nicht, wird keine Kollisionserkennung durchgeführt. Allerdings würde dann folgendes passieren:

Der Schnittpunkt liegt außerhalb der Strecke zwischen und und eine Kollisionserkennung würde nicht durchgeführt werden.
Allerdings findet eine Kollision statt, wie der rote Kreis verdeutlicht.

Lösungsansatz

Dadurch dass wir nicht nur eine Kollision für einen Punkt sondern für Kreise berechnen wollen, müssen wir auch die äußeren Begrenzungslinien der Bewegung daraufhin überprüfen, ob die Bewegung mit der Begrenzungskante kollidiert:

Die Punkte , , und spannen ein Rechteck auf, welches die Bewegung vollständig erfasst. Jetzt muss überprüft werden ob einer der Schnittpunkte und zwischen und liegen. Zusätzlich kann es noch einen Schnittpunkt geben, der durch die Strecke , entsteht. Für diesen muss die Überprüfung auch durchgeführt werden.
Sollte das einer der Schnittpunkte zwischen und liegen, ist eine Kollision mit der Begrenzungskante eingetreten, die erkannt und korrigiert werden muss.

Die Lösung

Zuerst müssen allerdings die Punkte , , und berechnet werden. Das ist relativ einfach:

Wie prüft man nun, ob zwei Strecken sich kreuzen? Erstmal sollte man überprüfen, ob sich die beiden Geraden die durch die beiden Strecken aufgespannt werden überschneiden. Sollte das der Fall sein kann man an Hand des Schnittpunktes, testen ob dieser innerhalb der beiden Strecken liegt.
Alle Punkte auf einer Strecke zwischen und sind durch die Parametergleichung

bestimmt.
Haben wir den Schnittpunkt der beiden Geraden also erst einmal gefunden, müssen wir für diesen Punkt nur noch den Parameter für beide Strecken bestimmen. Liegen beide Parameter innerhalb des Intervals , so kreuzen sich die Strecken:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

bool TestBoundedMovement::DoLineSegmentsIntersect( sf::Vector2f s1, sf::Vector2f e1, 
	sf::Vector2f s2, sf::Vector2f e2 )
{
	sf::Vector2f v1 = e1 - s1;
	sf::Vector2f v2 = e2 - s2;
	sf::Vector2f intersection;
	if ( LinesIntersection( s1, v1, s2, v2, intersection ) ) {
		float k = LineParam( s1, v1, intersection );
		float m = LineParam( s2, v2, intersection );
		if( ( m >= 0 ) && ( m <= 1 ) &&
			( k >= 0 ) && ( k <= 1 ) ) {
			return true;
		} else {
			return false;
		}
	}  else 
		return false;
}

Geradenschnittpunkt

Die mathematischen Hintergründe für die Berechnung eines Geradenschnittpunktes sind hier zu finden : Schnittpunkt zweier Geraden

Daraus ergibt sich folgender Programmcode:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

bool TestBoundedMovement::LinesIntersection( sf::Vector2f s1, sf::Vector2f v1, 
	sf::Vector2f s2, sf::Vector2f v2, sf::Vector2f &intersection )
{
	if( v1.x != 0 ) {
		float a = v2.x * v1.y / v1.x - v2.y;
		if( a != 0 ) {
			float m = ( s2.y - s1.y - ( s2.x - s1.x ) * v1.y / v1.x ) / a;
			intersection.x = s2.x + m * v2.x;
			intersection.y = s2.y + m * v2.y;
			return true;
		} else {
			return false;
		}
	} else {
		if ( v2.x != 0 ) {
			float m = ( s1.x - s2.x ) / v2.x;
			intersection.x = s2.x + m * v2.x;
			intersection.y = s2.y + m * v2.y;
			return true;
		} else {
			return false;
		}
	}
}

Parametergleichung umgekehrt

Möchte man den Parameter aus der Parametergleichung eines Punktes auf einer Geraden berechnen, muss man diese nur umstellen. Auf Grund der Trivialität dieses Vorgangs lasse ich die mathematischen Hintergründe hier ganz außen vor. Folgender Quellcode ergibt sich:

1
2
3
4
5
6
7
8
9
10

float TestBoundedMovement::LineParam( sf::Vector2f s, sf::Vector2f v, sf::Vector2f p )
{
	float k = 0;
	if( v.y != 0 ) {
		k = (p.y - s.y) / v.y;
	} else if ( v.x != 0 ) {
		k = (p.x - s.x) / v.x;
	}
	return k ;
}

Ende und Demo

Nun muss nur noch die Überprüfung für die beiden Strecken eingebaut werden:

//...
if( ! DoLineSegmentsIntersect( s + nh0 * r, z + v0 * r + nh0 * r, pl1, pl2 ) &&
    ! DoLineSegmentsIntersect( s - nh0 * r, z + v0 * r - nh0 * r, pl1, pl2 ) &&
    ! DoLineSegmentsIntersect( z + v0 * r + nh0 * r, z + v0 * r - nh0 * r, pl1, pl2 )) {
	//Bewegungslinie und BoundLine überschneiden sich nicht,
	//also wird keine Kollisionserkennung vorgenommen,
	//also ist myCircleCorrectDest = myCircleDest
	myCircleCorrectDest.SetPosition( z );
	return;
}
//...

Dazu gibt es wieder ein Demonstrationsprogramm:
Demonstrationsprogramm zu diesem Teil

Zur Demonstration der bisherigen Lösung habe ich ein kleines Programm geschrieben, in welchem man sich die berechnete Lösung für beliebe Ausgangssituationen anzeigen lassen kann. Es zeigt intuitiv die Probleme, die bisher noch nicht gelöst wurden.
Screenshot:

Bedienung :
Linke Maustaste, Drag&Drop : roter und schwarzer Kreis, Enden der schwarzen Linie
Rechte Maustaste, Drag&Drop : Bildschirmausschnitt
Mausrad : Zoomen

Ausprobieren : win-04.02.2011-21.26

Relevanter Quellcodeausschnitt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

void TestBoundedMovement::UpdateCorrectDest()
{
	sf::Vector2f s = myCircleStart.GetPosition();
	sf::Vector2f v = myVector;
	sf::Vector2f pl1 = myLineBound.GetP1();
	sf::Vector2f pl2 = myLineBound.GetP2();
 
	sf::Vector2f z = s + v;
 
	sf::Vector2f ng0;
 
	if ( MathUtils::ComputeNormal( pl1, pl2, ng0 ) ) {
 
		if( MathUtils::DotProduct( v, ng0 ) > 0 ) {
			//Bewegungsvektor zeigt von BoundingLine weg,
			//also wird keine Kollisionserkennung vorgenommen,
			//also ist myCircleCorrectDest = myCircleDest
			myCircleCorrectDest.SetPosition( z );
			return;
		}
 
		if( MathUtils::DotProduct( s - pl2, ng0 ) < 0 ) {
			//Der Startpunkt liegt hinter der Line
			//also wird keine Kollisionserkennung vorgenommen,
			//also ist myCircleCorrectDest = myCircleDest
			myCircleCorrectDest.SetPosition( z );
			return;
		}
 
 
		float r = radius;
		float d = ( MathUtils::DotProduct( z - pl2, ng0 ) );
 
		if( d >= r ) {
			//Es findet gar keine Kollision statt
			//also ist myCircleCorrectDest = myCircleDest
			myCircleCorrectDest.SetPosition( z );
			return;
		}
 
		float cosAlpha = MathUtils::DotProduct( v, pl2 - pl1 ) / 
				( MathUtils::VectorLen( v ) *  
				  MathUtils::VectorLen( pl2 - pl1 ) );
 
 
		float sinAlpha = sqrt( 1 - cosAlpha * cosAlpha );
 
		if( sinAlpha != 0 ) {
			float x = ( r - d ) / sinAlpha;
 
			sf::Vector2f z2 = z - x * v / MathUtils::VectorLen( v );
			myCircleCorrectDest.SetPosition( z2 );
		}
	} else {
		//Normale konnte nicht berechnet werden, 
		//also liegen pl1 und pl2 auf einem Punkt,
		//also ist BoundingLine nicht vorhanden,
		//also ist myCircleCorrectDest = myCircleDest
		myCircleCorrectDest.SetPosition( z );
	}
}

Übersicht:

1. Rechenweg
2. Quellcode und Demo

So jetzt wissen wir was wir brauchen. Damit fangen die Berechnungen auch schon an. Zusätzlich brauchen wir aber noch den Lot von der Begrenzungslinie zu den beiden Zielpunkten und . Der Lot zu sollte eine Länge von , also dem Radius des Figurenkreises haben, damit die Figur die Begrenzungslinie gerade so nicht überschreitet. Die Länge des Lotes zu bezeichnen wir mit .

Das führt uns zu folgender Skizze des zu Grunde liegenden mathematischen Problemes:

Die gepunktete Seite unter der Geraden ist der abzugrenzende Bereich.

Nochmal eine Zusammenfassung aller Variablen:

	Startpunkt
	Bewegungsvektor
	unkorrigierter Zielpunkt
	korrigierter Zielpunkt
	Radius der Figur
	Abstand des unkorrigierten Zielpunktes zur Begrenzungskante
	Abstand des unkorrigierten Zielpunktes zum korrigierten Zielpunkt
	Gerade, die von und aufgespannt wird
	Gerade, die von und aufgespannt wird
	Winkel zwischen den Geraden und
	Normale zur Geraden
	Normale zur Geraden
	Schnittpunkt des Lotes mit dem korrigierten Zielpunkt
	Schnittpunkt des Lotes mit dem unkorrigierten Zielpunkt
	Erster Endpunkt der Begrenzungskante
	Zweiter Endpunkt der Begrenzungskante

Wichtig ist dabei noch zu erwähnen, dass die Endpunkte der Begrenzungskanten einer BoundingBox gegen den Uhrzeigersinn angegeben werden müssen. Damit können wir an Hand der Normale der Begrenzungskante bestimmen, ob ein Punkt außerhalb der BoundingBox oder innerhalb liegt. Wenn die Punkte richtig angegeben sind zeigt die Normale nach außen wie in der Skizze zu sehen ist.

Achtung Fehlerquelle !!!

In der Computergrafik ist das Koordinatensystem normalerweise kopfüber gezeichnet, so dass die linke obere Ecke des Zeichenbereichs den Koordinatenursprung bildet und die Achsen nach rechts und nach unten verlaufen. Auf Grund dessen ändert sich hier die Reihenfolge in der die Kanten angegeben werden müssen. Bei seltsamen Ergebnissen, sollte man überprüfen, ob man hierauf geachtet hat.

Nun zum Rechenweg

Der korrigierten Zielpunkt kann berechnet werden indem vom unkorrigierten Zielpunkt der auf Länge skalierte Bewegungsvektor abgezogen wird:

Offensichtlich wird also der Wert von benötigt. Anhand der Skizze ist zu erkennen, das die Hypotenuse des durch , und aufgespannten rechtwinkligen Rechteckes ist. Es gilt also folgende Beziehung:

Der Sinus von kann über den Kosinus von berechnet werden, welcher über das Skalarprodukt zweier Vektoren, die die Richtung der beiden Geraden und darstellen, berechnet wird:

Weiterhin muss noch der Abstand des unkorrigierten Zielpunktes zur Geraden berechnet werden.

Eigentlich ist das nicht wirklich der Abstand, da nicht der Betrag, sondern ein vorzeichenbehafteter Wert übernommen wird. Hier ist die Orientierung der Normale der Geraden wichtig. Sollte außerhalb des von der Begrenzungskante begrenzten Bereiches liegen, ist dieser Wert positiv, sollte er innerhalb liegen, ist er negativ. Sollte dies der Fall sein ergibt sich folgende Situation:

Da negativ ist, gilt weiterhin folgende Beziehung:

Die Normale einer Gerade in der Ebene (also in 2D) wird einfach durch den Richtungsvektor der Gerade berechnet:

Damit lassen sich alle benötigten Werte auf bekannte Werte zurückführen und die korrigierte Zielposition kann ausgerechnet werden.

Da die Begrenzungskante nicht alleine ist, sondern zusammen mit anderen Kanten einen Bereich abgrenzt, wollen wir nur die Kollision von einer Seite der Kante aus betrachten. Es könnte sonst zu ungewollten Ergebnissen kommen wie hier dargestellt:

Wenn die rote Linie zuletzt verarbeitet würde, würde die „korrigierte“ Zielposition immer noch falsch sein. Wirklich korrekte Positionen werden wie hier durch den grünen Kreis nur durch Kollisionen mit Linien aus der richtigen Richtung (in den abgrenzenden Bereich hinein) erzeugt.
Es muss also überprüft werden, ob die Bewegung auf die Kante zu geht oder von ihr weg. Dazu folgende Skizze:

Die blaue Gerade führt in den abgegrenzten Bereich hinein und die rote Gerade von ihm weg.
Um herauszufinden welcher Fall für die aktuelle Gerade eingetreten ist, berechnen wir den vorzeichenbehafteten Abstand und überprüfen das Vorzeichen. Nur Geraden mit negativen Werten müssen beachtet werden.

Demo und Quellcode

Wer das alles einfach mal ausprobieren will, oder ein wenig Quellcode dazu sehen will, dem empfehle ich mein Demoprogramm hierzu anzuschauen :
Demonstrationsprogramm zu diesem Teil

Allerdings ist es damit noch nicht getan, denn es gibt Situationen wo dieser einfache Ansatz nicht ausreicht. Momentan behandeln wir die Begrenzungskante nämlich als Gerade und nicht als begrenzte Strecke mit Start- und Endpunkt. Das Demoprogramm verdeutlicht dies noch einmal.

Was dazu beachtet werden muss zeige ich im nächsten Teil.

Momentan arbeite ich daran eine sinnvolle Kollisionserkennung bei den Bewegungen zu implementieren.
Zum Berechnen einer korrekten Bewegung habe ich die Welt folgendermaßen modelliert:
Die Regale, oder später auch andere behindernde Objekte, bekommen eine BoundingBox, in die die Figuren sinnvollerweise nicht eindringen können sollten.
In folgenden Screenshots habe ich mal eine solche BoundingBox verdeutlicht und im zweiten Bild gezeigt was nicht passieren sollte.

Die BoundingBox besteht nun aus einzelnen Begrenzungskanten (Linien) und die Figur habe ich als Kreis abstrahiert:

ist dabei die Position der Figur.
ist der Vektor, der der gewünschten Bewegung der Figur entspricht. Er ist bestimmt durch Richtung und Länge.
und sind Endpunkte einer Begrenzungskante, welche nicht überschritten werden sollte.

Würde die Bewegung wie angefordert ausgeführt, hätten wir folgendes Ergebnis:

ist dabei die Position der Figur nach der Bewegung (das Ziel).

Wie man unschwer erkennt hat die Figur in diesem Fall die Begrenzungskante nicht beachtet und ist an einer ungültigen Position.

Jetzt müssen wir wissen was bei einer solchen Kollision getan werden soll und wie sich die Figur verhalten soll. Es wäre zum einen möglich eine elastische Kollision mit Bewegungsreflektion, wie bei Billiardkugeln die von der Bande abprallen, zu simulieren, oder wie in diesem Kontext besser, eine unelastische Kollision. Dabei wird einfach nur soweit „gegangen“ wie möglich. Die Bewegung wird abgeschnitten und Bewegungsenergie geht dabei verloren. Steht man im Spiel z.B. neben einem Regal und versucht in die Richtung des Regals zu gehen, sollte einfach nichts passieren. Das ist das gewünschte Verhalten.
Möchte man eine solche perfekt unelastische Kollision erreichen, ist eine Platzierung wie hier veranschaulicht gesucht.
.

Gesucht ist also die korrigierte Zielposition .

Wie man diese ausrechnet zeige ich im nächsten Teil.

Hähnchenkeule

Zuletzt habe ich an eine Regal gebaut. Dieses sieht man hier: win-02.02.2011-21.51

Bewegung mit den Pfeiltasten ist erstmals auch möglich.

Aber noch viel interessanter ist eine neue Version zum Ausprobieren.

Die zweite Figur ist da schon drin und nen Cursor.

EInfach mal ausprobieren : win-26.01.2011-15.57

Entschieden habe ich mich für eine Verwendung von C++, KDevelop, SDL, Cairo und CMake.
Und puh… Das einzige was ich bis jetzt geschafft habe ist ein paar simple SDL und Cairo und jetzt auch schon Pango (für Textdarstellung) Beispiele darzustellen. Im Endeffekt baue ich mir Wrapper für die ganzen C like Libraries SDL, Cairo und Pango. Probleme hat auch die Verwendung von CMake gemacht, da ich für Cairo und Pango noch zusätzlich CMake Module auftreiben musste. Hab ich mir im Endeffekt von Webkit (http://gitorious.org/webkit/webkit/trees/master/Source/cmake) geklaut.
Das mag alles recht lehrreich sein, und am Ende ist vlt auch alles schön portabel… Aber das ist es echt nicht wert. Mein Ziel für das Spiel Kaufhausschlacht war ein kleines Spiel zu programmieren, was in sich komplett ist und auch zu Ende gestellt werden kann. Wenn ich jetzt aber bereits dabei bin, ein Wrapper Framework zur Bändigung von SDL & Co zu schreiben, kann man absehen WANN das fertig wird. Oder besser gesagt, wann NICHT.

Also habe ich mich jetzt dazu entschieden meine Zeit sinnvoller zu nutzen und nach einer anderen, leichter zu handhabenderen Technologie zu suchen.

Visual C# und XNA wollte ich nicht benutzen, wegen der Windowsabhängigkeit. Allegro hab zwar auch schon Erfahrung, aber da damals irgendwas grundlegend schlecht war, so dass ich es neu implementieren musste, habe ich jetzt keine Lust das nochmal zu probieren.
Also Google auf und nach Alternativen gesucht.

Habe clanlib und sfml gefunden. Clanlib hat erst nen schöneren Eindruck gemacht, aber die größere Community, mehr Tutorials und einfachere Quellcodes und der Verwendungsgrad in meinem sozialen Umfeld von sfml sprechen einfach für sich.

Werde mich dann wohl dafür entscheiden.
Also alles was ich hab (ist ja nichts im Endeffekt…) in die Tonne und neu und frisch geht’s los!

mindeeper

Zusätzliche Idee:
Einkaufszentrum oder Warenhauses mit mehrere räumlich getrennten Sektionen als Metagame Menü, ähnlich wie bei Lego Starwars / Harry Potter etc