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