Enginepfad - Versionsgeschichte

Openglerf: Wiederspiegeln -> Widerspiegeln

2012-03-21T14:30:39Z

Wiederspiegeln -> Widerspiegeln

Darkinsanity: Ageia NovodeX ist schon seit einiger Zeit nVidia PhysX

2011-03-05T12:27:16Z

Ageia NovodeX ist schon seit einiger Zeit nVidia PhysX

Traude: /* Link auf Newton Physics Engine richtiggestellt */

2010-05-19T15:21:05Z

‎Link auf Newton Physics Engine richtiggestellt

TAK2004: /* Die ersten Schritte in eine nicht reelle Welt */

2009-03-03T04:31:24Z

‎Die ersten Schritte in eine nicht reelle Welt

TAK2004: /* Unit Test */

2008-09-24T12:41:14Z

‎Unit Test

TAK2004 am 24. September 2008 um 12:35 Uhr

2008-09-24T12:35:05Z

TAK2004 am 24. September 2008 um 10:15 Uhr

2008-09-24T10:15:36Z

Yogu: /* Vorbereitung */ Was zum Teufel ist AI? (-> Künstliche Intelligenz)

2008-07-08T14:11:03Z

‎Vorbereitung: Was zum Teufel ist AI? (-> Künstliche Intelligenz)

Thoronador: Kategorie:Trampelpfad hinzugefügt

2008-05-27T20:03:43Z

Kategorie:Trampelpfad hinzugefügt

TAK2004: /* Planung */

2008-05-14T00:01:33Z

‎Planung

@@ Zeile 135: / Zeile 135: @@
 ===Design Brainstorming===
-Wenn es mal wieder Zeit ist und ein neues Feature implementiert werden soll, dann sollte man sich erstmal einem Brainstorming unterziehen und dazu sind Tools hilfreich, die einfach nur die Gedanken wiederspiegeln und nicht auf UML oder ähnliche Konzepte basieren. Denn man will in dieser Phase noch nichts konkretes sondern nur Lösungsansätze.
+Wenn es mal wieder Zeit ist und ein neues Feature implementiert werden soll, dann sollte man sich erstmal einem Brainstorming unterziehen und dazu sind Tools hilfreich, die einfach nur die Gedanken widerspiegeln und nicht auf UML oder ähnliche Konzepte basieren. Denn man will in dieser Phase noch nichts konkretes sondern nur Lösungsansätze.
 Hierfür gibt es komerzielle und freie Tools, die entsprechend unterschiedlich viel können und arbeiten.
 *[http://freemind.sourceforge.net/wiki/index.php/Main_Page FreeMind](freies OpenSource Tool, cross platform)

@@ Zeile 60: / Zeile 60: @@
 :*[http://www.havok.com/ Havok]
 :*[http://newtondynamics.com/ Newton]
-:*[http://www.ageia.com/novodex.html NovodeX]
+:*[http://www.nvidia.de/object/nvidia_physx_de.html PhysX]
 :*[http://www.ode.org/ ODE]
 :Fenster:

@@ Zeile 59: / Zeile 59: @@
 :Physik:
 :*[http://www.havok.com/ Havok]
-:*[http://www.physicsengine.com/ Newton]
+:*[http://newtondynamics.com/ Newton]
 :*[http://www.ageia.com/novodex.html NovodeX]
 :*[http://www.ode.org/ ODE]

@@ Zeile 178: / Zeile 178: @@
 #[[Kamera]]
 #[[Schrift]]
-#[[Input]] (Maus/Tastatur)
+#[[IODevice|Input]] (Maus/Tastatur)
 #[[Adapter Muster]]

@@ Zeile 106: / Zeile 106: @@
 Wenn wir z.B. eine Aufgabe haben "berechne Hashwert von einer Datei", dann würden wir unsere Funktion, die einen Hashwert berechnet, in mehrere Unit Tests zerlegen und einen Unit Test anlegen, der die Hashfunktion auf eine Dummy File IO Klasse testet.
 Die Dummyklasse ist in der Regel ein Interface, welcher Konstante Daten enthält und somit eine 100% funktionierende Netzwerkverbindung, Datenbank, Dateisystem oder ähnliches Simuliert. Das hat den Vorteil, dass unsere Unittest auf jedem System laufen, auch wenn garkeine Netzwerkkarte da ist. Denn wir wollen ja die Funktionalität testen und nicht die Lauffähigkeit auf irgendwelchen Systemen.
-Mehr zum Thema ist [[UnitTest|hier]] zu finden.
+Mehr zum Thema ist [http://de.wikipedia.org/wiki/Modultest hier] zu finden.
 ===Automatisierte Builds können sehr Hilfreich sein.===

← Nächstältere Version		Version vom 24. September 2008, 12:35 Uhr
Zeile 86:		Zeile 86:

	:Wer sich in der Material nur ausprobieren will, kann anfangen, so viel wie möglich selber zu programmieren. Wenn es aber darum geht, eine Engine zu schreiben, welche man auch benutzten will, dann sollte man versuchen, so viel Code wie möglich wieder zu verwerten. Viele Programmierer haben schon Funktionen, Strukturen und Lösungen geschrieben und diese gilt es so gut wie möglich wieder zu verwerten. Dies hat viele Vorteile, denn man spart Zeit, man kann sich sicher sein, dass der Code standardmässig läuft und man hat sich viel Zeit mit der Konzeptphase gespart. Man muss in der konstruktiven Entwicklung nicht mehr das Rad neu erfinden. Der Trend in der professionellen Programmierung geht seit vielen Jahren in diese Richtung. [[SDL]], [[OpenAL]], DirectX, [[OpenGL]], zLib und viele andere Bibliotheken haben sich so ihren Stellenwert erkämpft.		:Wer sich in der Material nur ausprobieren will, kann anfangen, so viel wie möglich selber zu programmieren. Wenn es aber darum geht, eine Engine zu schreiben, welche man auch benutzten will, dann sollte man versuchen, so viel Code wie möglich wieder zu verwerten. Viele Programmierer haben schon Funktionen, Strukturen und Lösungen geschrieben und diese gilt es so gut wie möglich wieder zu verwerten. Dies hat viele Vorteile, denn man spart Zeit, man kann sich sicher sein, dass der Code standardmässig läuft und man hat sich viel Zeit mit der Konzeptphase gespart. Man muss in der konstruktiven Entwicklung nicht mehr das Rad neu erfinden. Der Trend in der professionellen Programmierung geht seit vielen Jahren in diese Richtung. [[SDL]], [[OpenAL]], DirectX, [[OpenGL]], zLib und viele andere Bibliotheken haben sich so ihren Stellenwert erkämpft.
		+
		+	==Helfende Tools==
		+
		+	Wenn man ein Projekt beginnt, dann sollte man auch entsprechend ausgerüstet sein, denn eine gute Toolchain erspart viel Zeit.
		+
		+	===Versionierung===
		+	Unabhängig von der Größe eines Projektes sollte der Quellcode und die damit verbundenen Ressourcen Versioniert werden, damit keine Daten verloren gehen. Hier mal eine Liste mit Versionierungstools.
		+	*[http://subversion.tigris.org/ SVN](frei,OpenSource,cross platform, der Nachfolger von CVS)
		+	*[http://git.or.cz/ git](frei,OpenSource,cross platform, der Linuxkernel wird darüber verwaltet)
		+	*[http://www.nongnu.org/cvs/ CVS](frei,OpenSource,cross platform, weit verbreitet)
		+	*[http://www.perforce.com/ Perforce](kommerziel ab 2 Nutzern,closed Source,cross platform, im Komerziellen Bereich verbreitet z.B. UnrealEngine3)
		+
		+	===Unit Test===
		+	Hierfür gibt es je nach Sprache und geschmack mehere Möglichkeiten.
		+	*Frameworks([http://junit.sourceforge.net/ JUnit], [http://camelos.sourceforge.net/fpcUnit.html FPCUnit], [http://sourceforge.net/projects/cppunit CPPUnit], [http://dunit.sourceforge.net/ DUnit])
		+	*komplett eigener Code
		+	Ein Unittest dient dazu, einen einzelne Funktion aus dem großen ganzen zu testen und alle Unittests zusammen ergeben dann die benötigte Funktionalität der Software.
		+	Schlagen einige Unittests fehl, tut die Software nicht mehr das, was sie eigentlich Leisten sollte.
		+	Wenn wir z.B. eine Aufgabe haben "berechne Hashwert von einer Datei", dann würden wir unsere Funktion, die einen Hashwert berechnet, in mehrere Unit Tests zerlegen und einen Unit Test anlegen, der die Hashfunktion auf eine Dummy File IO Klasse testet.
		+	Die Dummyklasse ist in der Regel ein Interface, welcher Konstante Daten enthält und somit eine 100% funktionierende Netzwerkverbindung, Datenbank, Dateisystem oder ähnliches Simuliert. Das hat den Vorteil, dass unsere Unittest auf jedem System laufen, auch wenn garkeine Netzwerkkarte da ist. Denn wir wollen ja die Funktionalität testen und nicht die Lauffähigkeit auf irgendwelchen Systemen.
		+	Mehr zum Thema ist [[UnitTest\|hier]] zu finden.
		+
		+	===Automatisierte Builds können sehr Hilfreich sein.===
		+	Ein Automatisierter Build wird verwendet, um z.B. Nightbuilds, Dailybuilds zu erstellen, Unittest, Systemtest und so weiter zu machen.
		+	Die komplexität von Buildsystemen ist hierbei sehr unterschiedlich.
		+	Hier ein paar Tools.
		+	*make
		+	*[http://www.scons.org/ scons](python basierte toolchain, cross platform)
		+	*[http://www.cmake.org/ CMake](Projektdatei Generator für viele Buildsysteme)
		+	*[http://ant.apache.org/ Ant](java basierte toolchain, cross platform)
		+	So kann man z.B. sein Projekt in einer makefile umsetzen, indem man sogenannte Targets für Kompilieren, Aufräumen, Unittests einbaut.
		+	Wenn man dann als Programmierer den Sourcecode lädt, kann man einfach make machen und man bekommt ein fertiges Build zurück.
		+	Damit hat man den ersten Stein für den Weg, zur nutzung der Software, gelegt.
		+	Der neue Programmierer will sich nicht erst mit den ganzen Konfigurationen, abhängigkeiten und Flags beschäftigen und wenn man als Entwickler der Software nach 1Jahr wieder den Code generieren will und die Befehle nicht mehr weiß, hat man sogar selber die Probleme.
		+	Daher lohnt es sich schon gleich zum anfang sich ein Generierungssystem auszusuchen und diese mit neuen Datein immer zu aktualisieren.
		+
		+	===Komplexe Buildsystem===
		+	Wer vor hat an ein größeren Projekt zu arbeiten, der sollte sich ein Buildsystem zulegen, welches über make und anderen hinaus geht.
		+	Eines der weit verbreitesten Systeme ist CruiseControl.
		+	CruiseControl ist ein Buildsystem, im welchen man Projekte anlegen kann, diesen bestimmte Aufgaben zuweist und es selbständig für sie Arbeit verrichtet.
		+	So kann man das erstellen von Binaries, UnitTest und Systemtest durchführen, Installer erstellen, E-Mails versenden und noch vieles mehr.
		+	Mehr zu CruiseControl findet man [[BuildGrids\|hier]].
		+
		+	===Systemtests===
		+	Systemtests sind Tests, die auf eine möglichen Zielumgebung ausgeführt werden, um zu sehen ob noch Funktionen in der Software fehlen. Wenn z.B. die Netzwerkverbindung mittem beim Senden zusammenbricht und daraus ein Fehler entsteht.
		+	Der Unittest testet ja nur die Funktion selber erfolgreich aber nicht System oder Fremdcode Fehler.
		+	Buildtools wie Ant in Verbindung mit CruiseControl können Systemtests sehr angenehm zu testen machen und vorallem automatisiert.
		+
		+	===Design Brainstorming===
		+	Wenn es mal wieder Zeit ist und ein neues Feature implementiert werden soll, dann sollte man sich erstmal einem Brainstorming unterziehen und dazu sind Tools hilfreich, die einfach nur die Gedanken wiederspiegeln und nicht auf UML oder ähnliche Konzepte basieren. Denn man will in dieser Phase noch nichts konkretes sondern nur Lösungsansätze.
		+	Hierfür gibt es komerzielle und freie Tools, die entsprechend unterschiedlich viel können und arbeiten.
		+	*[http://freemind.sourceforge.net/wiki/index.php/Main_Page FreeMind](freies OpenSource Tool, cross platform)
		+	*[http://www.gnome.org/~dscorgie/labyrinth.html Labyrinth](freies OpenSource Tool, Linux only)

	==Planung==		==Planung==

@@ Zeile 174: / Zeile 174: @@
 ==Links==
-[http://x-dream.neroneus.de X-Dream Engine]
+[http://karmarama.linuxprofessionals.org Karmarama Engine]
 [http://www.omorphia.de Projekt omorphia]

@@ Zeile 69: / Zeile 69: @@
 :Kompression:
 :*[http://www.zlib.net/ zLib]
-:AI:
+:Künstliche Intelligenz:
 :*[http://opensteer.sourceforge.net/ openSteer]

@@ Zeile 41: / Zeile 41: @@
 :4. Nun kommen wir zu allgemeinen Bibliotheken für das Ansteuern unserer Hardware.
-:Im Voraus ist zu sagen, dass ALSA und OSS Treiber unter Linux sind, die das Abspielen von Sound ermöglichen. Nur nur ein Bruchteil der Bibliotheken ist für 3D Sound ausgelegt und man müsste bei bedarf noch einen eigene Doppler Effekt hinzufügen.
+:Im Voraus ist zu sagen, dass ALSA und OSS Treiber unter Linux sind, die das Abspielen von Sound ermöglichen. Nur nur ein Bruchteil der Bibliotheken ist für 3D Sound ausgelegt und man müsste bei Bedarf noch einen eigene Dopplereffekt hinzufügen.
 :Sound:
 :*ALSA (Linux)
@@ Zeile 85: / Zeile 85: @@
-:Wer sich in der Material nur ausprobieren will, kann anfangen so viel wie möglich selber zu programmieren. Wenn es aber darum geht eine Engine zu schreiben, welche man auch benutzten will, dann sollte man versuchen so viel Code wie möglich wieder zu verwerten. Viele Programmierer haben schon Funktionen, Strukturen und Lösungen geschrieben und diese gilt es so gut wie möglich wieder zu verwerten. Dies hat viele Vorteile, denn man spart Zeit, man kann sich sicher sein, dass der Code standardmässig läuft und man hat sich viel Zeit mit der Konzeptphase gespart. Man muss in der konstruktiven Entwicklung nicht mehr das Rad neu erfinden. Der Trend in der professionellen Programmierung geht seit vielen Jahren in diese Richtung. [[SDL]], [[OpenAL]], DirectX, [[OpenGL]], zLib und viele andere Bibliotheken haben sich so ihren Stellenwert erkämpft.
+:Wer sich in der Material nur ausprobieren will, kann anfangen, so viel wie möglich selber zu programmieren. Wenn es aber darum geht, eine Engine zu schreiben, welche man auch benutzten will, dann sollte man versuchen, so viel Code wie möglich wieder zu verwerten. Viele Programmierer haben schon Funktionen, Strukturen und Lösungen geschrieben und diese gilt es so gut wie möglich wieder zu verwerten. Dies hat viele Vorteile, denn man spart Zeit, man kann sich sicher sein, dass der Code standardmässig läuft und man hat sich viel Zeit mit der Konzeptphase gespart. Man muss in der konstruktiven Entwicklung nicht mehr das Rad neu erfinden. Der Trend in der professionellen Programmierung geht seit vielen Jahren in diese Richtung. [[SDL]], [[OpenAL]], DirectX, [[OpenGL]], zLib und viele andere Bibliotheken haben sich so ihren Stellenwert erkämpft.
 ==Planung==
@@ Zeile 179: / Zeile 179: @@
 [http://andorra.sourceforge.net/ Andorra 2D]

@@ Zeile 101: / Zeile 101: @@
 In der Industrie verwendet man in größeren Engines Wrapper. Dieser ist dazu da, dass OpenGL/SDL und DirectX über eine eigene API angesteuert werden kann und somit ist es möglich die Engine mit den verschiedensten Plattformen (PC, Konsole, etc.) zurecht kommt. Laut einer neueren Umfrage schreiben 75% alle amerikanischen Publisher ihren Entwicklerteams vor, dass sie eine Engine mit genau dieser Eigenschaft nutzen. Des weiteren ist es auch immer häufiger, dass Publisher auf der ganzen Welt ihren Entwicklerteams vorschreiben, dass sie eine fertige Engine (Middleware) zu verwenden haben. Dies hat den Grund, dass der Publisher somit das Risiko eines Spiels vermindert und Geld spart - schließlich kostet das Entwickeln einer Engine eine große Summe an Geld und die Künstler sitzen währenddessen ohne Arbeit herum. Diese kalkulierten Kosten sind in der Summe höher als der Preis einer aktuellen Engine, wie zum Beispiel die "Vision" oder "Source" Engine.
-Wenn Sie es noch nicht getan haben, dann schauen Sie sich am besten noch ein Buch oder Artikel über Pattern/Muster an. So sind [[Adapter]], [[Singleton]], [[Observer Muster]] sehr sinnvoll zu kennen.
+Wenn Sie es noch nicht getan haben, dann schauen Sie sich am besten noch ein Buch oder Artikel über Pattern/Muster an. So sind [[Adapter_Muster|Adapter]], [[Singleton_Muster|Singleton]], [[Observer_Muster|Observer]] Muster sehr sinnvoll zu kennen.
 So kann man z.B. für Materials, Texturen, Shader, Models, Animationen und alle anderen auf Daten basierte Komponenten mit dem [[Adapter Muster]] sehr flexibel sein.
 Für ein SceneGraph kann man das Observer Muster prima anwenden und Singleton kann man für alle Manager verwenden.