Comic-Bug fixed

Der Comic-Shader ist jetzt richtig einsatzbereit.
Ein paar Bugs bezüglich Culling-States waren vorhanden,
sollten jetzt nicht mehr auftreten, da jetzt nicht mehr direkt manuell
mit DirectX (PDIRECT3DDEVICE9, ...), sondern mit Irrlicht gearbeitet wird.

Das Flugzeug in dem Bild wird mit dem Comic-Shader dargestellt.

Restartbug fixed

Probleme hat es beim Restart gegeben, wenn von Vollbild auf
Vollbild geswitched wird. Problem wurde schließlich identifiziert:
Folgendes wurde im Destruktor von CIrrDev durchgeführt. Da
von dieser Klasse allerdings eine statische Instanz angelegt wird
(Singleton) wird der Destruktor mehr oder weniger irgendwann
aufgerufen. Beim Wechsel von Vollbild auf Fenstermodus bzw.
umgekehrt hat es seltsamerweise keine Probleme gegeben.


void sktx::CIrrDev::free()
{
if (IRRINST != NULL)
IRRINST->drop();
if (KLAINST != NULL)
KLAINST->drop();
if (hreghandle)
UnregisterDeviceNotification(hreghandle);
idev = NULL;
sdev = NULL;
}

Zusätzlich wurde ein Irrlicht-Bug gefixed, der möglicherweise auch
damit zu tun hat. (Wollte es jetzt nicht mehr entfernen):

if (DepthBuffers.size() >= 1) //ENGINE-FIX
DepthBuffers[0]->drop();

Es wird einfach der Buffer[0] entfernt und freigegeben,
jedoch ist dieser nicht immer gesetzt => Speicherzugriffsfehler

Joystick-Fixes

Joystick und Gamepads werden jetzt korrekt zur Laufzeit erkannt.
Probleme dabei:

• Erkennung, dass Gamepad kein Joystick ist, d.h. über XInput zu steuern ist.
  Normalerweise ist ja ein Gamepad auch ein Joystick, aber über XInput kann man mehr steuern (Vibration, etc.)
• Eventgesteuert Erkennung, da die peridische Suche bei Nichtfinden eines Controllers relativ "viel" Zeit der Renderschleife kostet. Es wurde wieder einmal die Irrlicht-Engine erweitert und ein solch ein Handler installiert und sauber wieder gelöscht. Über die Window-Events empfängt man das Anstecken eines Gerätes. Jetzt müssen nur mehr die relevanten Events heraus gepickt werden und die XInput-Devices heraus gefiltert werden.
  

Interpolation

Eine Erstversion einer Interpolation wurde entwickelt. Bei Updates pro 1/4 Sekunde sieht das ganze recht gut aus; Der Client ist aber allerdings halt maximal 1/4 Sekunden hinterher; Vorteil: Positionsdaten und Rotationsdaten werden übertragen, die Newtonprobleme werden somit umgangen. Nachteil: Keine exakte Berechnung der Physik, wobei das wahrscheinlich auch nicht notwendig sein wird.
Extrapolation wird wahrscheinlich eventuell noch mit Berkley-Algorithmus folgen.
Zusätzlich wurde die Turm-Animation entfernt, was vor allem eine erhebliche Leistungssteigerung bewirkt. Die Animation (bestehend aus 100 Einzelmeshes) hat ziemlich viel Leistung gebraucht. Zusätzlich ist die Texturierung einfacher bzw. fürn Christian leicht durchzuführen. Kleinere Bugfixes wurden vorgenommen, der Render to Texture-Bug ist leider immer noch vorhanden und es muss wohl genauer in der Engine gesucht werden.

Controller zur Laufzeit erkennen / auf Abwesenheit reagieren

Mit der Taste '´' kann neu nach Joysticks und GamePads gesucht werden.
Status wird IN JEDEM ZUSTAND gezeichnet (rechts unten).
Neu suchen zur Laufzeit war zu langsam und wurde deswegen eventgesteuert
mit Taste eingeführt. Außerdem ist die stetige Suche auch irgendwie unnötig.
Der Benutzer braucht nicht anddauernd die Eingabegeräte aus- und einstecken,
wenn der das will, muss er halt von jetzt an Taste drücken ;).

Neu starten verbessert

Sktx ist jetzt refreshsicher und springt nach einem Neustart automatisch
wieder in das Einstellungsmenü!

sktx_0.7

Viele, viele Bugs wurden gesichtet und entfernt.
Das Design wurde rundum erneuert und verbessert, diverse
Einstellungen wurden dazugefügt, so lässt sich jetzt zum Beispiel
Postprocessing zur Laufzeit ein und aus schalten. Weiters wurden einige AI-Konzepte überlegt und bei der Physik wurde weitergearbeitet.

Etwas Intelligenz wäre doch cool...

IrrlichtAI wäre vielleicht ein Anfang. Ich habe zwar einige Bücher über das Programmieren von AI in Computerspielen, allerdings wäre es dumm dies zu implementieren, wenn es eigentlich schon fertige AIs gibt, die primitive Aufgaben wie PathFinding unterstützen.

Newton-Problem

Weil ich sonst nichts zu tun habe, mir fad ist, mich der Newton-Typ wieder mal aufregt und ich das
Problem ohnehin gerne mal gepostet habe, geht es jetzt noch einmal kurz um das Newton-60-FPS-Problem:
Das Problem tritt nur bei Rechnern auf, die die 60-FPS-Grenze nicht schaffen, also für einen Zeichendurchlauf (Rendervorgang) mehr als 1/60 Sekunden benötigen. Lokal ist das ganze ja wunderbar und die Maßnahme erscheint (mehr oder weniger) sinnvoll. Wenn also jemand der NewtonUpdate-Funktion reportet, dass er 1/40 Sekunden für einen Renderdurchgang benötigt hat, macht Newton einfach 1/60 daraus und aus diesem Grund fliegt der Flieger so gesehen langsamer, weil wenn man in die Geschwindigkeitsgleichung (s = v * t) einsetzt, natürlich eine geringere Wegdifferenz heraus kommt.
Problematisch wird es aber über das Netzwerk: Normalerweise sollte sich alles "von selbst synchronisieren". Da die Newton-Update bei schnelleren Rechnern sowieso öfters aufgerufen wird und bei langsameren Rechnern weniger oft, aber dafür mit größeren Zeitwerten und es sich bei den Zeitwerten um reale Werte handelt, hat eigentlich jeder immer den Realzustand (Annahme: gleichbleibende Geschwindigkeit und Rotation!). Das Flugzeug würde sich also unter der Annahme, dass es gerade aus mit konstanter Geschwindigkeit bewegt, vollkommen gleich auf jedem Rechner fort bewegen. Mangelnde Leistung wird durch größere Fortschritte kompensiert. Newton allerdings drosselt bei einer Framrate unter 60 FPS und somit wird ein Flugzeug am langsameren Rechner langsamer und das selbe Flugzeug am schnelleren Rechner fliegt mit Normalgeschwindigkeit weiter. Positionspatches würden also zu "Rucklern" führen.
Mögliche Lösungen und ihre Probleme:

• Auf andere Engine umsteigen, Problem: Welche Alternative? Nvidia PhysX => Probleme mit ATI-Karten, Havok? Aufwand? Zeitverschwendung?
• Geschwindigkeit so manipulieren, dass langsamere Rechner "schneller" fliegen (mehr v); Problem: Kollisionsverhalten wird sich verändern und vor allem wird sich ein anderes Stoßverhalten ergeben, etc...
• Geschwindigkeit so manipulieren, dass Flieger von langsameren Rechnern auf schnelleren Rechnern langsamer fliegen. Problem: wie oben, unterschiedliches Kollisionsverhalten
• Gesamtes Newton drosseln? NewtonUpdate nicht mit Realzeit, sondern mit Realzeit / FAKTOR aufrufen? FAKTOR könnte Werte zwischen 2.f und 4.f annehmen? Problem dabei: Geschwindigkeit müsste dies kompensieren, eigentlich in dem Punkt nicht schwerwiegend; Allerdings bedeutet dies auch eine Verschiebung des Kollisionsverhaltens, jedoch ist dies überall gleich. Langsamere Rechner (Rechner, die unter 60 / FAKTOR Frames per Second kommen, müssten dann allerdings ausgeschieden werden oder man gibt sich mit Rucklern zu frieden. Generell könnte man sich hier auch mit Rucklern zufrieden geben, weil auch im Internet diverse Ruckler keine Seltenheit darstellen und langsame Rechner ab einer gewissen Überlastung sowieso "ruckeln".
  => currently the best solution

Zur Netzwerksynchronisation generell würde dies mit der Vorraussetzung gelöst werden, dass jeder die gleiche Zeit hat (Berkley-Algorithmus oder Algorithmus von Christian, etc.).
Aufgrund der vergangenen Zeit zwischen Absenden des Paketes vom Client und der jetztigen Zeit kann eigentlich ziemlich unschwer auf die aktuelle Situation geschlossen werden. Natürlich handelt es sich hierbei nur um eine Vorhersage und die Vorhersage muss natürlich auch nicht stimmen, jedoch in den meisten Fällen kann man davon ausgehen, dass das Flugzeug trotzdem weiter fliegt. Auch können nach Implementierung der physikalischen Eigenschaften diverse radikale Geschwindigkeitsänderungen nicht durchgeführt werden, da auch nach Absetzen der Kraft und des Schubes noch immer aufgrund der Trägheit, etc. das Flugzeug fliegt.

Um Interpolation und Extrapolation geht es auch hier, die Seite stimmt auch ziemlich mit unseren Vorstellungen von der Thematik überein!

TERRAIN!!!

Es ist geschafft! Die Kollision des Terrains wurde über Newton realisiert! Es ist jetzt möglich, zur Laufzeit ein Terrain zu generieren, denn es wird sowohl das Mesh für die Darstellung, als auch das Mesh für die Physik dynamisch zur Laufzeit generiert.


Weiters wurde die Umrechnung von Newton nach Irrlicht-Meshes vorgenommen.
Irrlicht-Positionen müssen über * IrrToNewton nach Newton transformiert werden und umgekehrt müssen Newton-Positionen mit * NewtonToIrr ins Irrlicht-System transformiert werden. NewtonToIrr ist 32.0f normalerweise und deswegen wird das Gegenstück als Kehrwert angenommen. Durch diese Umrechnung sind die Ausschläge nicht mehr soo krass, allerdings ist das Flugverhalten äußerst seltsam...

Bezüglich des 60 FPS-Limits lässt sich nur sagen:

• Edit post
• Report this post
• Reply with quote

NewtonSetMinimumFrameRate?

by newtonfan » Tue Jan 20, 2009 9:32 am

Does Newton perform sub-steps per default? or is this just enabled after calling NewtonSetMinimumFrameRate?
It is important, because I don't want to limit my program to at least 60fps.
There would occur fatal network synchronization problems, because not every client can handle 60fps
thx

newtonfan

Posts: 1

Joined: Mon Dec 15, 2008 11:21 am

• Private message

Top

---

• Report this post
• Reply with quote

Re: NewtonSetMinimumFrameRate?

by Julio Jerez » Tue Jan 20, 2009 11:26 am

not fps lower than 60.
you can just take control of the time step by take mutiple update call at a fix step.

Julio Jerez

Moderator

Posts: 1154

Joined: Sun Sep 14, 2003 1:18 pm

Location: Los Angeles

• Private message
• Website

WIESO KANN MAN NICHT EINFACH DIESE SPERRE AUSSCHALTEN??? Das nenn ich benutzerfreundlich! Man braucht ja nur für jeden Mist einen Thread anwerfen und synchronisieren, warum nicht! Ist auf jeden Fall einfacher, als den Wertebereich eines Parameters auszuweiten.

PhysX - first steps

Es wurden einige Klassen entwickelt, um die realitistische Implementierung der Flugzeugphysik vorzubereiten. Der PhysXConstantMngr kümmert sich um das Parsen eines XML-Files, in dem sich eigentlich beliebig viele Definitionen von Flugzeugtypen befinden können. CMultiMatrix erlaubt das Generieren einer Matrix eines beliebigen Typs mit beliebiger Dimension. Diverse Rechenoperationen wie zum Beispiel die Multiplikation werden unterstützt. Zusätzlich wurden wichtige Operatoren wie = und auch der Kopierkonstruktor implementiert, um das Handling einfach zu gestalten. Dabei wurde besonders auf Effizienz geachtet (Referenzen wo möglich!). CAirPhysXCalc schließlich kümmert sich um die latheralen und longitudinalen PhysikEffekte.

Synchronisationsproblem behoben, erweiterte Levelübertragung

Das Übertragen von Files wurde komplett neu überarbeitet. Jetzt wird auch der MD5 als Kriterium herangezogen, ob ein File existiert oder nicht.
Folgender Bug wurde am Server gefunden (der nach wie vor multithreaded ist) und behoben:
Beim Kicken eines Spielers muss das Handle in der Liste vorher kopiert, dann auf NULL gesetzt, der Lock freigegeben und schließlich auf die Beendigung des Threads gewartet werden. Wenn zum Beispiel in der WaitForSingleObject - Zeile statt hnd cln->hnd stehen würde und dieses erst nachher auf NULL gesetzt werden würde, würde der Main-Thread das Handle schon in der Zwischenzeit manipulieren können. Das ganze führt dann dazu, dass ein Thread ohne Beendigung weiterläuft und Speicher nicht freigegeben wird und das Programm stürzt im Endeffekt mit einer Exception ab (in genau der blöden Situation, wenn dem Thread die Zeitscheibe zwischen Freigabe und erneuten Anforderung des Locks entnommen wird).

HANDLE hnd = cln->hnd;
...
cln->hnd = NULL;
LOCKSRV(false);
WaitForSingleObject(hnd, INFINITE); //blockierender systemaufruf!
LOCKSRV(true);

Es muss leider vor dem WaitForSingleObject entsperrt werden, weil auch der 2. Thread sperren und entsperren kann und es sonst zu einem Deadlock kommen kann. (Thread1 wartet auf Beendigung von Thread2, Thread2 wartet auf Lock vom Thread1)

Terrain-Kollision?

Die Terrain-Kollision muss irgendwie gelöst werden. Normalerweise kann man einen Meshbuffer (oder auch ein ganzes Mesh) direkt in das Newton-Mesh Format umwandeln. Beim Terrain, das ja dynamisch von Irrlicht aus einer Height-Map generiert wird, funktioniert das seltsamerweise nicht.

Folgendes wurde bereits versucht (tscene ist ein ITerrainSceneNode*):

• CDynamicMeshBuffer mb(video::EVT_STANDARD, video::EIT_32BIT);
  tscene->getMeshBufferForLOD(mb, SKTXTERR_LOD - 1);
  //spezielles level of detail verwenden
  
• tscene->getRenderBuffer() //renderbuffer direkt verwenden
• tscene->getMesh() //ganzes mesh verwenden

Möglichkeiten:

• Kollision mit einem optimierten OctTreeTriangleSelector prüfen?
  Problem dabei: "händisch" dazupfuschen, stimmt natürlich nicht mit Physikengine überein!
  Bei der ersten Kollision => Explosion?

1. Viele Rays erzeugen und prüfen, ob diese mit TriangleSelector kollidieren
2. Mit Ellipsoid prüfen? - Wird allerdings eher bei FPS-Shooter eingesetzt, in diesem Fall wahrscheinlich eher unpassender...
   

• ...?
  

Leveleditor

Ab jetzt ist es möglich, das Terrain im Editor sinnvoll zur Laufzeit zu verändern. Problematisch zeigt sich auf jeden Fall noch die Terrainkollision im Spiel. Ein ganzes, vollständiges Mesh zu erzeugen ist merklich zu aufwändig. Möglicherweise könnte die Kollision vereinfacht festgestellt werden und bei einer einmaligen Kollision könnte das Flugzeug sofort explodieren.

Strategiekamera

Die Strategiekamera wurde etwas manipuliert. Es ist jetzt möglich, eine Art Schrägansicht zu setzen. Von dieser Ansicht profitiert natürlich auch der Leveleditor, weil auch dieser eine Strategiekamera einsetzt.

Leveleditor

Der Leveleditor wurde vervollständigt. Folgende Funktionen sind jetzt vorhanden:

• Level laden
• Level speichern
• Objekte setzen
• Objekte verändern
• Objekte löschen
• Objekte zu Teams zuordnen
  
• Height-Map setzen
• Skybox setzen
• Height-Map verändern (noch etwas buggy zur Zeit):
  Zur Laufzeit kann die Höhe vom Terrain verändert werden
  

Folgende Funktionen wären optional später noch geplant:

• Terrain selber generieren (zufällig, aufwändig?)
  Lösung über diverse Algorithmen: Procedural Terrain Generation

Folgendes wird noch benötigt:

• Texturen
• Icons
• visuelle Improvements

Irrlicht Bug gefunden

Es wurde ein neuer Bug entdeckt, bzw. konnte jetzt wirklich auf Irrlicht zurück geführt werden.

getHeight des TerrainSceneNodes hatte eine Access-Violation wegen einer Speicherbereichsüberschreitung. Vertice-Arrays werden intern überschritten. Mittels folgender Abfrage vor der Prüfung kann das Problem vorläufig behoben werden:

Das Gebäude (bounds) muss innerhalb des Terrains sein, sonst wird keine Kollision geprüft!

aabbox3df terrbx = terrain->getTransformedBoundingBox();
if (bounds.MinEdge.X >= terrbx.MinEdge.X && bounds.MaxEdge.X < terrbx.MaxEdge.X &&
bounds.MinEdge.Z >= terrbx.MinEdge.Z && bounds.MaxEdge.Z < terrbx.MaxEdge.Z)
ret.Y = terrain->getHeight(ret.X, ret.Z);

Level-Checks

Ab sofort werden in der Auswahl nur mehr gültige Levels angezeigt. Ein Level ist gültig wenn:

• mindestens 2 Teams vorhanden sind
• mindestens eine Basis, ein Spawn-Punkt und ein Zwischenturm pro Team vorhanden ist
• alle MD5-Hashes korrekt sind (sowohl vom Level, als auch der Images)
• eine SkyBox und ein Terrain definiert sind
  

"Bauen" - Leveleditor + Stratege einsetzbar

Eine Erstversion des Bauens wurde fertiggestellt: Gebaut werden darf nur, wenn die durchschnittliche Höhe des Bodens ungefähr (Abweichung von 20 zulässig) gleich ist. Zur Zeit wird in diesem Zustand die Boundingbox angezeigt, andernfalls ist sie ausgeblendet. Später wird man wahrscheinlich die Texturen verändern, sodass wahrscheinlich eine rote Schicht drübergelegt wird und andernfalls eine grüne Texturschicht sichtbar wird.

• Nicht Bebaubar:

• Bebaubar:

#include - Rekursion verhindern?

Eine Sache fehlt bei C++ immer noch: Eine Erkennung der gegenseitigen Inkludierung zweier Header-Files. Es ist zwar möglich mit einer #ifndef (Include-Guards) oder #pragma once (im C++-Standard NICHT enthalten) - Konstruktion das gegenseitige Inkludieren aufzuhalten, aber die gegenseitige Verwendung ist dann auch nicht möglich und es entstehen ziemlich viele Build-Fehler. Die Feststellung der Ursache kann (vor allem bei einer indirekten Include-Rekursion) sehr schwer sein.
Links: Include-Guards

Netzwerk - gepuffert und eventgesteuert

Netzwerknachrichten (außer Ping) werden jetzt nicht mehr sofort behandelt, sondern in einer queue gepuffert und danach jedes mal im Run der Engine behandelt. Mit Hilfe folgender Methode des InputManagers wird die Queue im Run geleert:

bool sktx::CInptManager::postQueuedNetPackets()
{
keptnetpckts.begin();
int i = 0;
for (i = 0; i <>(GMINST->getCurr()) == MAININST)
sendNetPacket(keptnetpckts.pop_unsafe());
keptnetpckts.end();
return i > 0;
}

Zusätzlich wurden einige andere Threads "gespart": Thread für Joystick, Xinput (Gamepad)
Problem dann, wenn sehr geringe Anzahl FPS: aufgrund der Geschwindigkeit des Rechners kann (und wird) es natürlich vorkommen, dass ein gedrückter Knopf nicht erkannt wird, weil zu dem Zeitpunkt, zu dem abgefragt wird, der Knopf bereits wieder losgelassen wurde!

#include - Hilfe oder Last?

In C++ ist so ziemlich alles eine Wissenschaft. Selbst über das Inkludieren von Headern könnte man ein Studium erfinden... Bis jetzt gab es zigtausend include-Konflikte, Probleme, etc. die durch Herumprobieren der Reihenfolge, Hinzufügen von #include "WinSock2.h", #include "string", #include "list", #include "d3dx9math.h", #include "xtree", ... "gelöst" wurden.
Zum Glück existiert eine Compileroption "/showIncludes" beim Microsoft C++ 2008 - Compiler, die jedes (auch indirekt) inkludiertes File anzeigt. Somit wird klar, dass 220 WinSock-Fehler zum Beispiel deswegen kommen, weil windows.h irgendwo in irgendeinem versteckten File vor WinSock2.h inkludiert wird.
Irgendwie sollte das primitive "include" schön langsam in ein intelligenteres verwandelt werden. Das Übersetzen dauert sowieso endlos lang, also kommts auf diese zusätzliche Prüfung irgendwie auch nicht mehr drauf an!
Weiters wurde herausgefunden, dass, wenn die Multithreaded-Runtim von Microsoft verwendet wird (eine andere gibt es bei Visual C++ 2008 sowieso nicht mehr) diverse Operationen von Haus aus multithreaded sind und außerdem zum Beispiel der Operator new angeblich thread-safe sein sollte. Das würde erklären, warum bis jetzt kein Fehler zur Laufzeit aufgetreten ist!

"Bauen" am Gefälle? - Editor, Strategiespieler

Um nicht auf dem Gefälle Gebäude errichten zu können, wäre folgender Ansatz möglich: Das Bauen wird nur erlaubt (Gebäude grün eingefärbt), wenn die Differenz zwischen den Terrainhöhen an den X- und Z-Positionen der 4 Ecken der Boundingboxen nicht zu sehr schwankt. Überschreitet diese Differenz den zulässigen Grenzwert (steiles Gefälle), dann wird das Gebäude genauso rot eingefärbt, wie wenn man zwei Gebäude übereinander errichten würde.

Speichern - MD5

Speichern des Levels, Positionieren weiterer Elemente, sowie das Einbinden einer Hash-Bibliothek wurde implementiert. Dabei wurde jetzt erst richtig verstanden, wie das Einbinden von dynamischen Bibliotheken funktioniert und aus diesem Grund statt dem Übertragen von C++-Strings zwischen Anwendung und Dll, diverse Interfaces (eigentlich abstrakte C++-Klassen) definiert. Andernfalls ist es nicht möglich von einem Objekt, das nur über eine DLL-Funktion angelegt und mitgegeben wird, Methoden aufzurufen.

Scrubs - Staffel 8

SkyTactix feiert den Start der 8. Scrubs-Staffel! :)

Leveleditor - first ideas

A first version of a leveleditor was added. This version is capable of setting diverse objects and loading the level-file. Later an MD5-hash should be used to identify every file. Important is that the placement of game-objects is implemented in a general class and so a new game-object can be easily added. Therefore it is just necessary to add the new object and define the new bounding-box.

MST-Heuristik optimiert und bugs fixed

Der Algorithmus zum Suchen der Eulertour wurde modifiziert, das Auflösen der konsekutiven Kanten wurde auch verbessert.

MST-Heuristik Prerelease

Erstversion einer MST-Heuristik wurde implementiert, weite Optimierungen sollten noch folgen. 2-Opt Optimierung sieht vernünftig aus; Ein Vehicle Routing Problem wäre auch nicht schlecht als Unterstützung für den Strategen. Insbesondere folgende Variante wäre passend meiner Meinung nach:

• Multiple Depot VRP (MDVRP)
  The customers get their deliveries from several depots.

Ein Algorithmus wurde noch nicht wirklich gefunden, aber hier gibt es einige Informationen dazu:
http://osiris.tuwien.ac.at/~wgarn/VehicleRouting/vehicle_routing.html

send - Zuverlässige Übertragung?

Important TODO: Sicherstellen, dass Daten an der Gegenstelle ankommen. Die send-Funktion tut dies anscheinend laut der MSDN-Dokumentation NICHT! Mögliche Lösungen:

• Sliding-Window-Algorithmus von TCP nachprogrammieren? Aufwand?
• Time-Out so setzen, dass, wenn ein Packet nicht ankommt, sofort ein Reconnect durchgeführt wird und die Daten wieder neu synchronisiert werden.
• Accepts schicken - Netzwerkauslastung? Aufwand?
• ...
  

Reconnect-Improvements

Der Reconnect-Algorithmus arbeitet jetzt gezielter, gewisse TimeOut-Einstellungen wurde optimiert. Ein Mechanismus, der eine Datei eindeutig identifiziert (MD5, SHA?) wäre nicht schlecht und würde für die File-Übertragung noch fehlen.

Netzwerk - Beitreten zu jeder Zeit möglich!

Client-Daten werden jetzt mit Server synchronisiert. Das ist auch der Grund, warum das Netzwerk bei dem Spiel so aufwändig ist, weil eigentlich der Server einen Teil der Daten (Positionsdaten, entwickelte Updates, Gebäudedaten, Teamleistungsdaten, ...) immer halten muss. Das macht es möglich, dass auch Clients zwischendurch dem Spiel beitreten können. Level-Loading wurde optimiert, Client muss Level nicht immer neu laden, wenn alle Files vorhanden sind.

Netzwerk - Reconnect, Client-seitiger Ping, erweiterte Netzwerkphysik-klasse, ...

Heute wurden wieder einmal einige Bugfixes behoben...Schön langsam sollten der Mist bugfrei werden? Threads unter C++ sind verdammt aufwändig und man muss verdammt genau und gewissenhaft programmieren! Ein Client-seitiger Ping wurde implementiert, bei einer 3-fachen Übertretung dieser Zeit wird wieder in das Hauptmenü gewechselt. Ein Problem besteht weiters und muss noch gefixed werden: Ein reconnect dauert im Extremfall (kein Netzwerkkabel) zu lange und Program befindet sich im Prinzip in einem temporären Deadlock. Timeouts lassen sich leider keine neuen setzen, also muss eine Alternativlösung mit einem eigenen Timer gefunden werden. To be continued...