Layoutmanager

Das Grundkonzept für einen einfachen, jedoch ziemlich mächtigen und vielseitig einsetzbaren Layoutmanager wurde fertiggestellt. Es sollen viele bereits bekannte Elemente des GridBagLayouts von Java inkludiert werden, jedoch sind einfache dazugehörige Animationen und Effekte im Manager dabei.

Erfolgreicher build

Mittlerweile existiert ein erster erfolgreicher Build eines Teiles der SkyEngine!
Betroffen sind über 130 cpp- und h-Files. Vernünftige Schnittstellen (damit die dynamische Bibliothek auch wirklich verwendet werden kann) müssen jetzt entworfen werden und stellen die nächste Hürde dar. Als problematisch stellt sich die FontLibrary dar, da diese auch bei SkyTactiX immer wieder zu seltsamen Verhalten geführt hat. So kann beispielsweise unter Umständen eine gewisse Font einer bestimmten Auflösung nicht erzeugt werden, obwohl alle Vorkehrungen getroffen sind. Diese Fehler (die wahrscheinlich in dem FontTool der Engine verankert sind) müssen jedoch auch dringend behoben werden.

Weitere Bibliotheksfortschritte

Inzwischen wurden Teile der Physikengine von SkyTactiX in die SkyEngine portiert.
Weiters sind (allerdings noch in einem eingeschränkten Ausmaß) gewisse Teile der Grafikbibliothek (beispielsweise ShaderManager) und allgemeine Teile (GameState, Logger, GCollector etc.) verfügbar. Sobald ein erster, erfolgreicher und vollständiger Build existiert, werden die bereits implementierten Bestandteile auf Mac und Linux portiert.

squirrel - integration, fortschritte der ganzen bibliothek

Aufgrund der Tatsache, dass sqplus (Library zum Einbinden von Squirrel in C++) laut der sourceforge-Homepage nicht kompatibel mit einem gcc ist, wurde eine Einbindung selbst programmiert. Im Wesentlichen muss ein eigener Stack verwaltet werden, da das Design der Sprache sehr an Lua angelehnt ist. Es wurden folgende Klassen implementiert:

Klasse	Beschreibung
CSqFunc	Aufrufen von Funktionen / Methoden / Konstruktoren
CSqClass	Erzeugen von Klassen (Hinzufügen von Methoden und Eigenschaften) / Instanziieren von Objekten
CSqInstance	Auslesen und Setzen von Eigenschaften
CSqVMMngr	Verwalten der virtuellen Maschine / Ausführen von Squirrel-Code (auch als Byte-Code) / Setzen und Auslesen von globalen Variablen / Registrieren von globalen Funktionen (mit Überprüfung der formalen und realen Parameter)

Release

Eigentlich finden sich hier bis jetzt keine Screenshots / Videos vom fertigen Spiel!
Hier folgt also das Intro-Video, das einen kurzen Überblick über die Spielelemente geben soll:

Für ein weiteres Projekt (Hauptdarsteller Eyan Mon durchlebt seine Alpträume) wird direkt aus SkyTactiX die SkyEngine entwickelt, die zukünftige Spieleentwicklungen erleichtern soll und aus Darstellungs (GUI, 2D, 3D)-, Netzwerk-, AI-, Sound- und Skriptkomponenten bestehen soll.

Bugfixes

Zahlreiche Erweiterungen wie: verstellbare Sichtweite /
Umschalten auf die "reale", doch leider nicht ganz einfache Physik /
skippen von Tracks /
nächster Track (in der Reihenfolge) /
Anzeige des aktuellen Tracks wurden /
Neues Album von Tone Intimacy wurde hinzugefügt => SkyTactiX verfügt nun über 9 unique Tracks!

Gefixed wurde folgendes:
credits problem bei schnellen rechnern
tankmenue problem mit sounds
steuerung problem beim menü
kollisionen problem bei ganz flachen terrains (normalvektor (0,0,0)!)
einstellungsmenü fehlerhaft manchmal
lvedit buttons

sonstiges:
buttons hinzugefügt

Graph improved

Es wurden die Texturen eingebunden, sowie mit Hilfe von 2D-Sprites die Pfeile gezeichnet. Zusätzlich sind jetzt einige Funktionen wie Neu, Aktiv setzen sowie das Verändern der Höhe und Rotation der Ziele möglich.
Die Kollision wurde bereits im Rahmen der vorigen Arbeiten verschärft! Anfliegen an dem Energiefeld bedeutet Zerstörung des Flugzeuges!

Bauen - Bugfix

Es wurde ein Bug im Zusammenhang mit dem Bauen von Gebäuden im Strategiespieler behoben. Im Wesentlichen wurde die selbe ausgelagerte Funktion, die auch beim Leveleditor verwendet wurde, jetzt verwendet. Dabei wurde anscheinend wieder ein Irrlicht-Bug umgangen, der verhindert, dass bei einer Kollisionsabfrage außerhalb des Terrains Probleme (Speicherzugriffsfehler?, etc.?) entstehen.

Vergleich der diversen graphischen Einstellungskombinationen Postprocessing + Comic-Effekt:



Normal:

Postprocessing:

Comic-Effekt:

Postprocessing + Comic-Effekt:

Screenshots v 0.9

fixes

Nach vielen Fixes, wurden heute erste Testspiele veranstaltet. Es haben sich noch diverse Bugs beim Bauen und bei der Info-Verwaltung ergeben, jedoch waren alle ziemlich beeindruckt von dem Ergebnis. Die Stabilität von SkyTactiX war ziemlich herausragend, ich kenne kommerzielle Spiele, die teilweise nicht ziemlich stabil sind und bin deshalb ziemlich stolz drauf. Die Musik passt offenbar sehr gut dazu. Kommentare wie "wo habts ihr das herunter geladen?" oder "die spielmusik klingt wie die bei einem kommerziellem spiel!" haben uns heute den Tag versüßt. Steuerungsoptimierungen wären nicht schlecht sowie die verbleibenden Bugfixes sind auch noch auszubessern. Die realen Physikberechnungen wuren heraus genommen, werden aber natürlich in der Diplomarbeit erwähnt werden. Für den normalen Spielverlauf ist es aber zu kompliziert und aufwendig, mit "realer" Physik zu spielen. Außerdem ist es ziemlich schwierig bis unmöglich gewesen, mit der Steuerung umzugehen. Ansonsten dürfte sich das Ergebnis auf jeden Fall sehen lassen.

RTT-Bug hopefully fixed

Jetzt sollte der RTT-Bug wirklich gefixed sein.
Irrlicht hat zwar sonst auf das Viewport Rücksicht genommen,
allerdings nicht bei den 2D-GUI-Funktionen, was vor allem
ein Zurücksetzen erforderte. Das Zurücksetzen allerdings verfälschte
zum Beispiel die restliche Kollision sowie diverse berechnete Strahlen.
Es wird jetzt nicht mehr zurückgesetzt, stattdessen wurden die Irrlicht
GUI-Funktionen modifiziert und eine eigene RTT-Klasse geschrieben sowie
alle bestehenden RTTs umgeschrieben.

Transparent Shaders

Die Probleme bezüglich transparenter Shader wurden immer noch nicht behoben, daher sind diese jetzt auch in das Irrlicht-Forum eingetragen worden.
Bug-Bilder wie folgt:

Bugfixes

Diverse Bugs wurden behoben, zusätzlich wurde entdeckt, dass noch immer unter bestimmten Bedingungen Anzeigeprobleme bestehen (Render Targets, irrlicht zeichnet intern nicht mit dem richtigen DirectX9-Viewports => Engine-FIX).
Zusätzlich wurde der reportete Bug von hybrid gefixed: Sourceforge Seltsamerweise tritt der Fehler auch bei Auflösungen auf, die keine Potenz von 2 ist.

RTT-Bug 2 done

Der 2. RTT-Bug wurde mehr oder weniger behoben. Einer der Irrlicht-Entwickler hat mir versichert, dass er spätestens beim nächsten Release behoben sein wird. Inzwischen hab ich einfach einen Trick angewendet.
Mit ist aufgefallen, dass der Fehler immer nur bei der höchsten Auflösung auftritt, die der aktuelle Monitor darstellen kann. Also hab ich mal herumprobiert und bei zb. 1280x800 funktionieren 1280x795 und 1280x801. Daher wird ab jetzt im Fenstermodus eine slightly größere RTT angelegt. Der Hintergrund: Irrlicht shared, wenn die Größe des Rendertargets kleiner oder gleich der Auflösung ist gemeinsam einen Backbuffer. Mit 1280x801 wird also quasi erzwungen, einen neuen Buffer anzulegen, was eigentlich recht sinnlos ist, aber dafür kann es nicht mehr vorkommen, dass einfach nichts mehr gezeichnet wird. Spätestens beim nächsten Release könnte man die eine Zeile, die die Höhe entsprechend vergrößert sowieso wieder entfernen.
Forum: Irrlicht Forum
Bug-Report: SourceForge

windoof is seltsam

Also da würd man doch meinen, dass Windows mehr oder weniger fortschrittlich ist, jedoch gibt es nicht einmal ein UNIX-select!!!
Wie wartet man auf Eingabe / prüft ob Eingabe verfügbar ist? - Gute Frage!
Diverse Foren meinen lediglich, dass in der MSDN-Hilfe was zu finden ist. Man kann meines Wissens zwar den Buffer auslesen, jedoch ist dieser dann nicht mehr verfügbar / Eingabe wird nicht angezeigt! Selber anzeigen wäre auch eine Möglichkeit, jedoch müsste man die diversen Sondertasten extra behandeln...WARUM??? Ist es so schwer ein select zur Verfügung zu stellen? - Das nächste Spiel wird PLATTFORMUNABHÄNGIG, weil irgendwie will ich dieses Schrott-OS mit seiner Schrott-Speicherverwaltung und seinen Schrott-SDKs nicht auch noch fördern. Visual Studio schmeißts auch ständig auf:

1. Interner Compilerfehler


2. Interner Linkerfehler


3. Problembericht


4. Speicherzugriffsfehler


5. IntelliSense streikt wieder


6. Markieren im Header-File: 40 Sekunden warten (Markieren ist sehr kostspielig, vergleichbar mit Crysis!)

Ist schon schwer mit 10 Jahren Erfahrung ein IntelliSense für C++ hinzubekommen, das sehe ich ja ein. Außerdem ist Microsoft ja nur ein kleines Familienunternehmen, das geht einfach nicht besser!
Getreu dem Firmenmotto:

Microsoft - wir sind immer für uns da"

Threading - Forschritte

Der select-basierte Server verläuft ganz gut! Vor allem das Beitritt-Menü hat davon profitiert, da jetzt ruhig "unendlich" lange "gewartet" werden kann. Das "Warten" ist einfach ein Pollen in der Render-Schleife und verbraucht vergleichsweise wenig Resourcen.
Ein Thread musste allerdings am CLIENT geschaffen werden: Duch lange "Wartezeiten" könnte es sein, dass Client gekickt wird, was vor allem durch den Ping-Thread verhindert wird.
Am Server ist dieser Thread nicht notwendig, da diese sowieso nicht so lange blockieren soll (und hoffentlich auch nicht tut!)!!!
Der Downloadmanager wurde erweitert und optimiert, es werden nun generell (im Hinblick auf den Filedownload!) die Puffer am Server und am Client mit jeweils maximal 1024 Zeichen gefüllt, was einen ziemlichen Fortschritt für den Filedownload bewirkt. Der Downloadmanager wurde so geschrieben, dass er leicht erweitert werden kann. Geladene Dateigröße in KB, sowie die Filenr und die Datei werden angezeigt.

Threading

Nachdem ich vor ein paar Tagen eine Thread-Klasse angefangen habe
und begonnen habe, die vielen _beginthreadex und _endthreadex gegen
die gekapselten Methoden einzutauschen, bin ich die ganze Multithreading-
Geschichte noch einmal durchgegangen.

• 
  Es lief ein einziger Input-Thread, der peridisch nach Eingabegeräte polled.
  Die Daten werden in eine Queue geworfen, allerdings kann mit dem normalen Windows-SDK keine vernünftige zustandsabhängige Steuerung mit wait und notify programmiert werden. (WAS TUN WENN QUEUE VOLL???) Bedingungsvariablen funktionieren auch erst ab Windows Vista (WARUM???), was irgendwie seltsam erscheint, da das Konzept der Threads und die dadurch entstandene Notwendigkeit der Synchronisation sicher schon länger existiert. Anyway, dieser Thread hat zwischendurch gesleept mit 1000 / 30 Millisekunden. Ein Spiel allerdings, das 15-20 FPS erreicht, ist schwer spielbar, also kann dieses Abfragen genauso gut in der normalen Schleife erfolgen.
  


• 
  Der Client war multithreaded, und wurde dann später ebenfalls durch ein Queue-System ausgetauscht. Jedoch werden im Wesentlichen die Daten erst in der Schleife bearbeitet, also wird der Teil auch in die Main-Schleife versetzt werden. However, select zum Beispiel erlaubt das Abfragen, ob Daten vorhanden sind und dieses pollen funktioniert (bereits getestet!) auch periodisch ziemlich vernünftig mit einem Timeout von 0 Millisekunden! Warum also überhaupt threaden?
  Es ergeben sich eigentlich nur Nachteile:
  
  
  
  • Einbruch im Bezug auf die Skalierbarkeit: Thread erzeugen und löschen ist immer noch eine ziemlich kostspielige Aktion, selbst Thread-Pooling wird auch auf Dauer nicht viel helfen, da erst wieder mit Performance-Einbußen zu rechnen ist (bei zb. fiktiv angenommen 1000 Clients!)
  
  
  • Threads sind eigentlich bei Spielen ziemlich unüblich! Wenn man zum Beispiel das Uralt-Quake hernimmt, glaube ich, dass dieses diverse Netzwerkaktivitäten ohne Threads verarbeitet.
    
  
  
  • 
    Synchronisationsaufwand! Man darf den Aufwand für das periodische Reservieren und Freigeben der Locks nicht vergessen.
    
  
  
  • 
    Gefahr von Fehlern! Threads potenzieren die Gefahr von Fehlern, da das nichtdeterministische System eigentlich noch nichtdeterministischer gemacht wird und man überhaupt keine Vorhersage mehr treffen kann, wann etwas durchgeführt wird.
    
  
  
  
  


• 
  Der Server war multithreaded und wird jetzt wsl. auch vollkommen durch eine iterative Variante ausgetauscht werden. Nachdem Daten verfügbar sind (select!), wird das lesen wsl. sowieso nicht mehr diesen Performanceeinbruch mit sich bringen!
  

Zusammengefasst: Im Endeffekt werden nach den Veränderungen nicht mehr viele
Threads übrig bleiben!

Controller

Die Steuerung der Eingabegeräte wurde komplett überarbeitet.
Es ist möglich, ganz einfach ein neues Gerät dazu zu implementieren. (Nintendo Wiimote?)
Problem ist dabei vor allem, dass die "normalen" Maus-Events nicht weitergeleitet werden dürfen, sondern im Falle einer Joystick-Steuerung ignoriert werden müssen. Weiters ist auch ein eigener virtueller Cursor erforderlich, der sich um die gesamte Cursor-Steuerung kümmert. Andere Probleme dabei betreffen die Event-Reihenfolge, die gelöst werden mussten. Es wurde außerdem von der normalen Eingabeverarbeitung wieder auf eine Variante mit Threads und einer synchronisierten Queue umgestellt.

Restoresicher

SkyTactiX ist (zur Zeit noch) restoresicher!
Das bedeutet, man kann die Anwendung starten, dann
zum Beispiel in den Standbymodus wechseln und es kommt
zu keinem Speicherzugriffsfehler! Das hört sich vlt. für einen DirectX-Laien
selbstverständlich an (ich habe es selbst zu Beginn auch für selbstverständlich gehalten), jedoch
muss man, damit dieses erreicht wird, Texturen mit der Memory-Class D3DPOOL_MANAGED anlegen. Alternativ ist es auch möglich zum Beispiel D3DPOOL_DEFAULT zu nehmen, jedoch müssen nach einem restart die Texturen neu angelegt werden. Bei D3DPOOL_MANAGED kümmert sich Direct3D9 darum, dass automatisch wieder Texturen wiederhergestellt werden.
Ab 1.5 sollte die Engine von selbst restoresicher sein, jedoch war SkyTactiX nicht restoresicher! Der Grund war, dass wir selbst CubeMaps hinzugefügt haben und dabei nicht auf dieses Problem geachtet haben! Man sieht also, dass man eigentlich bei DirectX normalerweise so ziemlich an alles denken muss, um eine vernünftige Anwendung zu erhalten.

Auszug aus der DirectX Dokumentation (Unten sieht man zum Beispiel D3DUSAGE, offensichtlich auch eine eigene Wissenschaft für sich... ;)):

D3DPOOL
Defines the memory class that holds the buffers for a resource.

typedef enum D3DPOOL
{
D3DPOOL_DEFAULT = 0,
D3DPOOL_MANAGED = 1,
D3DPOOL_SYSTEMMEM = 2,
D3DPOOL_SCRATCH = 3,
D3DPOOL_FORCE_DWORD = 0x7fffffff,
} D3DPOOL, *LPD3DPOOL;

Constants

D3DPOOL_DEFAULT
Resources are placed in the memory pool most appropriate for the set of usages requested for the given resource. This is usually video memory, including both local video memory and AGP memory. The D3DPOOL_DEFAULT pool is separate from D3DPOOL_MANAGED and D3DPOOL_SYSTEMMEM, and it specifies that the resource is placed in the preferred memory for device access. Note that D3DPOOL_DEFAULT never indicates that either D3DPOOL_MANAGED or D3DPOOL_SYSTEMMEM should be chosen as the memory pool type for this resource. Textures placed in the D3DPOOL_DEFAULT pool cannot be locked unless they are dynamic textures or they are private, FOURCC, driver formats. To access unlockable textures, you must use functions such as IDirect3DDevice9::UpdateSurface, IDirect3DDevice9::UpdateTexture, IDirect3DDevice9::GetFrontBufferData, and IDirect3DDevice9::GetRenderTargetData. D3DPOOL_MANAGED is probably a better choice than D3DPOOL_DEFAULT for most applications. Note that some textures created in driver-proprietary pixel formats, unknown to the Direct3D runtime, can be locked. Also note that - unlike textures - swap chain back buffers, render targets, vertex buffers, and index buffers can be locked. When a device is lost, resources created using D3DPOOL_DEFAULT must be released before calling IDirect3DDevice9::Reset. For more information, see Lost Devices (Direct3D 9).
When creating resources with D3DPOOL_DEFAULT, if video card memory is already committed, managed resources will be evicted to free enough memory to satisfy the request.

D3DPOOL_MANAGED
Resources are copied automatically to device-accessible memory as needed. Managed resources are backed by system memory and do not need to be recreated when a device is lost. See Managing Resources (Direct3D 9) for more information. Managed resources can be locked. Only the system-memory copy is directly modified. Direct3D copies your changes to driver-accessible memory as needed.

Differences between Direct3D 9 and Direct3D 9Ex:
D3DPOOL_MANAGED is valid with IDirect3DDevice9; however, it is not valid with IDirect3DDevice9Ex.

D3DPOOL_SYSTEMMEM
Resources are placed in memory that is not typically accessible by the Direct3D device. This memory allocation consumes system RAM but does not reduce pageable RAM. These resources do not need to be recreated when a device is lost. Resources in this pool can be locked and can be used as the source for a IDirect3DDevice9::UpdateSurface or IDirect3DDevice9::UpdateTexture operation to a memory resource created with D3DPOOL_DEFAULT.

D3DPOOL_SCRATCH
Resources are placed in system RAM and do not need to be recreated when a device is lost. These resources are not bound by device size or format restrictions. Because of this, these resources cannot be accessed by the Direct3D device nor set as textures or render targets. However, these resources can always be created, locked, and copied.

D3DPOOL_FORCE_DWORD
Forces this enumeration to compile to 32 bits in size. Without this value, some compilers would allow this enumeration to compile to a size other than 32 bits. This value is not used.

Remarks
All pool types are valid with all resources including: vertex buffers, index buffers, textures, and surfaces.
The following tables indicate restrictions on pool types for render targets, depth stencils, and dynamic and mipmap usages. An x indicates a compatible combination; lack of an x indicates incompatibility.

Pool D3DUSAGE_RENDERTARGET D3DUSAGE_DEPTHSTENCIL
D3DPOOL_DEFAULT x x
D3DPOOL_MANAGED
D3DPOOL_SCRATCH
D3DPOOL_SYSTEMMEM

Pool D3DUSAGE_DYNAMIC D3DUSAGE_AUTOGENMIPMAP
D3DPOOL_DEFAULT x x
D3DPOOL_MANAGED x
D3DPOOL_SCRATCH
D3DPOOL_SYSTEMMEM x
For more information about usage types, see D3DUSAGE.
Pools cannot be mixed for different objects contained within one resource (mip levels in a mipmap) and, when a pool is chosen, it cannot be changed.
Applications should use D3DPOOL_MANAGED for most static resources because this saves the application from having to deal with lost devices. (Managed resources are restored by the runtime.) This is especially beneficial for unified memory architecture (UMA) systems. Other dynamic resources are not a good match for D3DPOOL_MANAGED. In fact, index buffers and vertex buffers cannot be created using D3DPOOL_MANAGED together with D3DUSAGE_DYNAMIC.
For dynamic textures, it is sometimes desirable to use a pair of video memory and system memory textures, allocating the video memory using D3DPOOL_DEFAULT and the system memory using D3DPOOL_SYSTEMMEM. You can lock and modify the bits of the system memory texture using a locking method. Then you can update the video memory texture using IDirect3DDevice9::UpdateTexture.

RTT-Bug1 done

Der 1. Bug von Render Targets wurde gefixed. Es kann vorkommen, dass eine groessere Textur, als die Auflösung genommen wird (Grafikkarte kann zum Beispiel nur Texturen, die als Groesse eine 2er Potenz haben). Um dieses Problem zu lösen, wird im Prinzip einfach das Bild abgeschnitten, jedoch muss dieses Abschneiden mit Versetzen der Texturkoordinaten des TransformRects passieren. Extra zu behandeln ist allerdings das Zeichnen der restlichen Geometrie, diese muss mit Hilfe Methode "SetViewport" des DirectX9-Devices auf die richtige Groesse gesetzt werden.
Beispiel: Auflösung 1280x800
Grafikkarte 1 setzt 1280x800 Rendertarget-Textur
Grafikkarte 2 setzt 2048x2048 Rendertarget-Textur (warum auch immer!)
Es muss bei beiden sowohl die Geometrie, als auch die 2D-Elemente richtig gezeichnet werden. (Behandlung im Wesentlichen wie eigene fiktive Auflösung, wenn man so will!)

Irrlicht-Bug?

2 Bugs? wieder gefunden:
-> bei manchen PCs werden RTTs nicht in der richtigen Größe erstellt
-> RTTs funktionieren nicht bei jeder Auflösung:
vs

Plane-Selector fixes, unabhängiger DownloadManager

Es wurde ein Downloadmanager implementiert (Klasse), der sich um leglichen Download kümmert
und dabei MD5-Hashes generiert und überprüft. [Refactoring im Wesentlichen]
Neben einer Vielzahl an Bugfixes wurde ein Planeselector implementiert, der
es erlaubt Flugzeuge auszuwählen, jedoch werden im Endeffekt dann die Flugzeuge
vom Server genommen, damit ein einheitliches Spiel möglich ist. Um den Unterschied zu erkennen, wurde nur bei einem Flugzeug der Burner richtig im File gesetzt.
Um ein neues Flugzeug zu implementieren, ist es lediglich notwendig, die Physik-Werte im XML-File einzutragen sowie ein Physik-Mesh, ein Mesh zur Darstellung und die ColorMap zu setzen. Probleme waren vor allem beim Handling mit dem RenderTarget vorhanden (Doppeltes Rendern, ein mal das Menü + ein Flugzeug mit Hintergrund und unabhängiger Kamera in die Textur; Textur dann anzeigen!). Problematisch war, dass Irrlicht nicht das Zeichnen einzelner SceneNodes unterstützt, sondern die gesamte Szene gezeichnet werden muss. Ergebnis => erneuter Engine-Fix, ab jetzt kann man mit setRange vom ISceneManager den Bereich der IDs der Nodes setzen, die gezeichnet werden sollen oder DRAW_ALL mitgeben. Es ist daher überhaupt nicht aufwendig (Alternative: Liste von Ids mitgeben => aufwendiger und ziemlich öde!) und ziemlich einfach zu verwenden. Lediglich die richtige ID muss beim SceneNode gesetzt werden, was die Funktionalität (im Vergleich zum Array / dynamische Liste, etc.) etwas einschränkt.

Physik-Fixes

Das Verhalten des Flugzeuges ist mittlerweile (nach meinem Ermessen) doch ziemlich vernünftig. Natürlich besteht noch Tuningarbeit und vor allem muss noch herausgefunden werden, warum die Winkel der Irrlicht-Engine so seltsam berechnet werden (Eulersche Winkel: Y-Rotation begrenzt zwischen 0 und 180 Grad, muss evtl. noch umgerechnet werden!) Mit Hilfe der Matrizen des Buches "Flight Dynamics And Automatic Flight Controls" von Roskam J. und der Unterstützung von Professor Dellinger verhält sich das Flugzeug schon realitätsnahe.

Setup-Projekt

Da früher oder später sowieso ein Setup-Projekt erforderlich ist, wurde dieses jetzt erstellt.

Mit Hilfe eines Klicks wird automatisch ein Setup-File erstellt, wobei auch alle

notwendigen Abhängigkeiten der diversen Projekte berücksichtigt werden. In diesem Zusammenhang wurde auch gleich die Projektorganisation neu eingeteilt und ist jetzt wie in der Abbildung gestaltet. CopyFonts (benutzerdefinierte SETUP-Aktion) dient zum Kopieren der SkyTactiX-Fonts (TTF) in den Windows-Ordner, wobei interessanterweise das Löschen nicht so einfach möglich ist. Eigentlich braucht auch das Font-File nicht wirklich mehr heraus gelöscht werden, ich kenne viele Programme die das nicht tun. Das SkyTactiX-Setup kennt folgende Abhängigkeiten:

• SkyTactiX (exe)
• Irrlicht (dll)
• Irrklang (extra über "Content" angegeben)
• Newton (-"-)
• SkyFontTool (dynamisches Generieren der bmp-Fonts zur Laufzeit)
• SktxHashLib++ (basiert auf HashLib++, kleine Änderungen; Überprüfen, ob Levels unterlaubterweise manipuliert wurden)
• SktxServer (standalone-Server)

Die Squirrel-Language und die IrrAI-API wird statisch gelinkt, da dies anscheinend von den Entwicklern so vorgesehen ist und ein Umschreiben wahrscheinlich ziemlich aufwendig wäre (einzelne Funktionen über Interfaces bereitstellen, da sonst Probleme mit Speicher => dll-Speicher nicht direkt eigener Speicher!).

LEIDER muss der data-Ordner vor dem Build manuell in den Explorer "hineingezogen" werden, man müsste eventuell die Config-Files editieren (wenn nicht proprietär! Python-Skript?), um einen vollautomatischen Build hinzubekommen. Es gäbe eine Möglichkeit Dateien als "Content" zu markieren, jedoch müsste man da jede einzelne Datei markieren => Aufwand? Visual Studio ist manchmal echt ziemlich dumm, was die Frage aufwirft wieso dieses komische Programm so viel kostet.

Zur Vorbearbeitung des data-Ordners (Löschen von "CVS"-Ordner (inklusive Inhalt), ".cvsignore", "*.wings", "*.xcf", etc.) wurde ein Python-Skript implementiert, das diese Aktionen mit einer Rekursionsstufe von bis zu 10 und mit Hilfe von Listen von regulären Ausdrücken durchführt.

Folgendes muss also durchgeführt werden, um einen Build hinzubekommen:

• Ausführen von cvsremove.bat (Löschen der unnötigen Dateien + Ordner)
• Hineinziehen des data-Ordners
• Build ausführen
• NICHT speichern, da der Data-Ordner nicht mehr wegzubekommen ist: VStudio meldet: Ordner nicht leer => Jede Datei einzeln löschen (Bilder, Models, Sounds, etc.)

map, lots of improvements

Neben wieder einer Liste von Fixes wurde schon seit längerer Zeit eine ziemlich geniale Actionplayermap implementiert. Das ganze basiert auf einen GPU-Shader a la Rechberger. Die Karte wird dynamisch von der aktuellen Map erstellt und die korrekte Rotation der Karte ermöglicht eine einfache Navigation.

Zusätzlich werden spezielle Ziele (Meldungen, Befehle, Infos, die der Stratege den Actionspieler erteilen kann) auf der Karte markiert und der Pfeil richtet sich danach aus. Weitere Verbesserungen betreffen zum Beispiel die Konsole, das Pausemenü (Actionspieler wie auch Strategiespieler werden einfach "angehalten", war leider notwendig, da sonst das Gameplay vor allem für den Actionplayer ziemlich ungewöhnlich und das Pausemenü eigentlich sinnlos wäre), oder die Delegationsliste, die dem Strategiespieler ab jetzt zur Verfügung steht.

Pausemenü

Zur besseren Handhabung wurde ein Pausemenü eingeführt,

das ab jetzt dynamisches Namenwechseln erlaubt.

Alle weiteren Einstellungen können wie gewohnt geändert werden,

jedoch ist ein Neustart während eines Spieles nicht möglich

und es muss entweder manuell neu gestartet oder die

Änderungen müssen im Menü vorgenommen werden.

tons of bugfixes and extensions

In letzter Zeit wurden viele Probleme behoben und Lösungen optimiert.
Zusätzlich gibt es auch einige Erweiterungen und Neuheiten. Das Servermenü zum Beispiel wurde erweitert und erlaubt mehr Konfigurationsmöglichkeiten, was auch natürlich die Anzeige beim Serversuch-Menü verändert hat. Eine vorläufige Version der Titelmusik wurde komponiert und ist bereits auf dem CVS. Die Menügestaltung wurde vielmals verbessert (z.B.: Soundeinstellungen). Wenn die Netzwerkverbindung abbricht, lässt sich dies rechts oben in der Ecke anhand eines Icons erkennen! Bugs wurden zum Beispiel folgende behoben:

• ToolTip-Bug (von Irrlicht): ging nicht weg, mit Events weggecheatet!
• Tasten-Bug (Events wurden "gefressen"); jetzt werden Events, wenn Textbox den Fokus hat, nicht mehr einbehoben und für zum Beispiel die Kamera verwendet.
• Sound-Bugs
• Credits schneller und an Rechner angepasst
• diverse Leveleditor-Fixes
• Console-Fixes (garantiert jetzt immer im Hintergrund, wenn unsichtbar!)

Neuer Zwischenstand

Das Konzept des Bauens von Gebäuden wurde für den Strategie - und Actionspieler fertiggestellt und funktioniert. Der Stratege hat nun die Möglichkeit einzelne Gebäude auf dem Spielfeld zu platzieren und diese zu entwickeln. Der Actionspieler kann diesen "Rohbau" daraufhin mit einem Energieball fertigstellen, indem er diesen Energieball auf das unfertige Gebäude fallen lässt. Dabei wurden neue Materialien für die Physik - Engine erstellt, um die Kollisionerkennung zu ermöglichen.

Weiters wurde die Funktionalität der Upgrades für den Actionspieler implementiert. Es ist nun möglich die einzelnen Eigenschaften des Flugzeuges wie Geschwindigkeit, Beschleunigung und Spritverbrauch zu beeinflussen, indem man sich die Upgrades über das Tankstellenmenü installieren lässt.

Im grafischen Bereich gibt es einige Bugfixes. Das Schutzschild wird nun korrekt für alle Modelle dargestellt. Weiters wird beim Bauen im Leveleditor und beim Strategiespieler durch verschiedene Farben und Alpha-Werte angezeigt, ob ein Platzieren des Gebäudes an dieser Stelle möglich ist. Erste Versionen von verschiedenen Explosionen mittels Partikelsystem wurden erfolgreich erstellt. Im Bereich des Benutzerinterfaces wurde ein Fehler behoben, welcher die FPS - Zahl bei Anzeige des Informationstextes deutlich verringerte. Interessant bei diesem Fehler war, dass lediglich die Berechnung des Zeilenumbruchs für einen gewissen Anzeigebereich für den Performance - Einbruch verantwortlich war. Dabei wurden Strings und Substrings mittels der String - Klasse der Irrlicht - Engine verwendet.

Texturen wurden für die Tankstellen- und Ballausgabegebäude fertiggestellt. Weitere Texturen für die Respawn-Gebäude wurden ebenfalls fertiggestellt.

Die Rotation der abgrasenden Kameras wurde durch sogenannte Quaternions neu implementiert bzw. verbessert. Die Übertragung der Rotation über Netzwerk ist nun problemlos und soweit ruckelfrei möglich. Fehler die vereinzelt durch die Berechnung falscher Rotationsgrade bei der Übertragung über Netzwerk aufgetreten sind, wurden dadurch ebenfalls beseitigt.

Generell steht die Implementierung bereits ziemlich am Fertigwerden. Einzelne Bugfixes und funktionale Umsetzungen im Bereich des Netzwerks sind noch fertigzustellen. Ansonsten ist das Spiel in seinen geplanten Funktionen spielbar. Größere Veränderungen oder Zusätze sind nicht mehr geplant.

Kamera

Die Kamerapositionen werden übers Netzwerk übertragen und zu Beginn synchronisiert.

Musikalische Begleitung

Für Titelmusik und evtl. Untermalung der Credits wird die Band Even sorgen,
dessen Schlagzeuger ich sehr gut kenne und der auch unser Projekt Spheropuzzle
damals musikalisch aufgebessert hat. Zusätzlich werden diverse Soundeffekte
(positioniert im 3D-Raum)
und auch die Melodie des Hauptspiels von meinem Bruder komponiert und
arrangiert. Das ganze sollte im Prinzip spätestens Ende April fertiggestellt sein.

PhysX - erste Eindrücke

Physik-Bugs wurden behoben, es ist jetzt der Learjet mit seinen Eigenschaften realisiert. Mit Hilfe von Datensets (in Form von XML) wäre es nun möglich, im Prinzip beliebig viele Flieger auszuwählen. Das Problem ist nur, dass diese Flieger auch jemand modellieren müsste, die Datenhaltung erlaubt es jedenfalls.
Zusätzlich sind erste AI-Eindrücke entstanden und es wurden kleine Kameras programmiert, die die Türme abgrasen (patrollieren) und diese schließen, sobald ein Feind in Sicht ist (im Field of View). Dabei passen sie auf, dass sie nicht kollidieren (Abtastung des Untergrunds und der Gebäude in der Nähe). Netzwerkfixes wurden eingespielt und fertige Texturen, Icons und Modelle werden hoffentlich bald fertig gestellt.

Strenges Spiel

Die Konsistenz wird ab jetzt nur mehr bei der Spieloption "strenges Spiel" überprüft. Diese Option erzwingt allerdings nur, dass der Strategiespieler vorhanden ist.

Konsistenz des Spielzustandes

Ab jetzt wird die Konsistenz sicher gestellt:
Es kann nicht sein, dass weniger als ein Action- und ein Strategiespieler pro Team beigetreten sind. Aus diesem Grund lässt sich ein Spiel erst ab einem Action- und einem Strategiespieler pro Team starten. Zusätzlich kann es vorkommen, dass ein Strategiespieler hinausfliegt (schlechte Verbindung, Rechner stürzt ab, Teamwechsel, Typwechsel, etc.). In diesem Fall wird ein Actionspieler "zwangsbeglückt". Sollte dieser wieder wechseln, wird der nächste Strategiespieler. So wird mehr oder weniger erzwungen, dass immer jemand den strategischen Teil regelt.
Sollte ein Actionspieler hinausfliegen und kein weiterer Actionspieler ist dem Team beigetreten, wird das Spiel angehalten, bis wieder ein Actionspieler pro Team vorhanden ist.

Tankstellen - Menü

Ein weiterer Punkt im Spiel - Prinzip wurde fertiggestellt: das Tankstellen - Menü. Es ist soweit fertig und einsatzbereit. Der Actionspieler kann mit seinem Flugzeug durch die Tankstelle fliegen und das Menü öffnet sich. Hier kann er kostenlos tanken oder Upgrades, die vom Strategen bereits erworben wurden, gegen wenig Entgeld, installieren lassen. Die Synchronisierung mit dem Server funktioniert ebenfalls schon.

Strategie-Bugs

Weiter Bugs in der Strategie-Logik wurden entfernt. Vor allem werden jetzt die Updates richtig angezeigt und außerdem wurden weitere Speicherprobleme behoben (VORSICHT!)
Zusätzlich lässt sich schnell zwischen den unterschiedlichen Sichten problemlos wechseln und bereits gekaufte Objekte werden weiter entwickelt. (Erweiterung, Basis war bereits vorhanden.) Bufferüberläufe wurden auch einige behoben (sollten eher nicht vorkommen!).

Strategie-Bugs behoben, PhysX in Arbeit

Es wurden endlich nach langer Suche (heute alleine ca. 3-4 h) die "argen" Strategiefehler behoben. Es waren sehr viele Abstürze die Folge, obwohl die "argen" Fehler gar nicht so "arg" sind.
Folgendes war falsch:

• C-Fehler Nr. 1: Verwechseln von = und ==: eigentlich ziemlich traurig, aber Schlampigkeitsfehler passieren leider auch unachtsamen erfahreren Programmierern
• Cast-Fehler: die SkyTactiXLogik wurde fälschlicherweise in eine Strategielogik gecastet. Statt (LOGICINST->getLogic()) wurde LOGICINST auf CStrategyLogic* gecastet! Was ich nicht verstehe, ist, dass es in diesem Fall keine Typüberprüfung gibt! Zumindest eine Microsoft Exception wäre fein, weil ja auch zur Laufzeit mi RTTI der Typ bestimmt werden kann und somit könnte man so etwas doch einfach verhindern!

Neuigkeiten bezüglich Physik haben sich ergeben: Es hat sich gezeigt, dass die Matrixmultiplikationen doch nicht so aufwendig sind, wie ursprünglich angenommen, sondern dass diese auf jeden Fall für die Flugdynamik eingesetzt werden können!
Sonst kann man sagen, dass vor allem an der Texturierung weiter gearbeitet wird und nebenbei diverse Erweiterungen und Bugfixes hinzugefügt werden.

Graph - Punkte setzen

Der Actionspieler kann jetzt zwischen seine definierten Ringe durchfliegen.
Zur Ermittlung der aktuellen Höhe werden wieder Strahlen geschickt und
der kleinste Abstand der Rays von den Triangle-Selektoren wird ermittelt.
Dies stellt sicher, dass die Platzierung immer auf der richtigen Höhe erfolgt
und nicht nur auf dem Boden des Terrains ausgerichtet ist.
Die Pfeil-Animation ergänzt das Ringe-Setzen. Der Strategiespieler hat die Möglichkeit Ringe für den Actionspieler zu setzen und kann somit aktiv in das Verhalten der Spieler eingreifen. Unterschiedliche Ringtypen mit unterschiedlichen Prioritäten sind geplant.

UDP

Diverse Netzwerkfixes wurden behoben, außerdem ist ab jetzt immer ein 2. Socket offen, der sich um das auffinden der Server und um die Versendung von Positions-Updates bemüht. Prinzipiell ist alles so ausgelegt, dass man "umschalten" kann, ob für den jeweiligen Nachrichttyp (immerhin bis jetzt schon über 40 Nachrichten-Typen) TCP oder UDP eingesetzt wird. Weiters wurden diverse Synchronisationsbugs und sonstige Fehler behoben, die Bewegungen schauen schon ziemlich gut aus, vor allem UDP hat zu dieser Verbesserung beigetragen. Zusätzlich soll eventuell für die Extrapolation noch der vereinfachte Algorithmus von Cristian eingesetzt werden.

AI

Prinzipien der AI wurden implementiert (AI-library eingebunden, AIManager geschrieben, Wegpunkte festgelegt, verlinkt, etc...)
Probleme dabei:
-> Flugzeug kann sich nicht einfach "umdrehen" wie Mensch
-> Flugzeug sollte nicht durch Wände fliegen
-> Flugzeug muss genauso steuern und denken, wie Mensch das machen würde

Es muss daher irgendwie eine Art "Roboter" geschaffen werden, der irgendwie
mit Sensoren erkennt, wie seine Umgebung aussieht!
Dies wäre möglich mit Strahlen, die mit Hilfe der Triangle-Selektoren ausgesendet und
geprüft werden können. Problem läge in der Auswertung und Positionierung dieser Strahlen.

Tipps von Herrn Professor Haberstroh würden wir gerne annehmen, bzw. erhoffen wir!
Im Prinzip wäre das ja so eine Art Roboter-Problem oder?
Sie haben mit der Robotik wahrscheinlich doch schon ziemlich viel Erfahrung, wie
könnte man das möglichst effizient lösen?

bug-fixes, extensions, schießen

Schießen ist jetzt (zumindest lokal möglich), wobei das ganze gar nicht so einfach ist.
Es werden geschosse nicht mit der newton-engine verschossen (komischerweise gehen ab bestimmten geschwindigkeiten die kollisionen nicht mehr), sondern "händisch" geprüft. Dazu werden die geschosse händisch weiterbewegt. Mit Hilfe einiger Triangle-Selektoren wird geprüft ob der aktuelle Strahl (Position - Position + Geschwindigkeit) mit Triangle-Selektoren kollidiert. Davon wird sogleich das minimalste genommen. Aufgepasst werden muss noch mit Schutzschild (ist nur manchmal aktiv, also darf nicht geprüft werden, wenn das ganze invisible ist!). Diverse andere Optimierungen sind noch nötig und - voala => Schießen möglich.
Diverse weitere Netzwerkoptimierungen wurden vorgenommen, das Interpolieren verbessert.
Komischerweise funktioniert es nicht auf Rechnern, die nicht Server sind, weil die Zeiten zu groß sind. => Bug?