Seite 1 von 2

[Projekt] TAW-Klon

Verfasst: 24.02.2018, 13:23
von Krishty
Ich arbeite seit ein paar Jahren mit ein paar Leuten an einem Flugsimulator, der auf dem 1998er F-22 Total Air War aufbaut (und sich dessen Content borgt).



Natürlich sind wir noch meilenweit von einem fertigen Spiel entfernt. Andererseits gibt es aber viel zu viel aus der Entwicklung, wovon ich erzählen könnte – ich wollte das schon seit Jahren irgendwie sortieren, aber ich finde einfach keine Zeit dafür. Und es wird nicht besser.

Darum werde ich nun einfach mittendrin anfangen und hier Updates posten. Und vielleicht zwischendurch ein paar Geschichten aus der alten Zeit. Wenn euch was auffällt oder interessiert, fragt einfach!

Grobe Timeline:
  • 2011 habe ich Total Air War ausgegraben und wollte prüfen, ob man es gut modden kann.
  • Ich bin schnell auf TAW 2.0 gestoßen – eine großartige Community-Mod, in die dutzende Jahre Entwicklung geflossen sind. (Ende der 90er waren Flugsimulatoren irre populär.)
  • Die Mod war technisch am Limit – alles textbasierte und die Texturen waren ausgeschöpft. Neue Modelle wären das nächste gewesen, aber zu schwer – das Modellformat ist das Durchgeknallteste, was ich bisher gesehen habe (grob gesagt eine VM für Glide-Befehle).
  • Wir haben also 2011 einen Model Viewer programmiert, um dem Modding auf die Sprünge zu helfen.
    2011-05-16 dunev.jpg
  • Als der Model Viewer lief, dachte ich mir: Warum nicht die Kacheln der Landschaft nebeneinander anzeigen? … und so hatten wir dann einen Terrain Viewer.
    2011-07-20 targetnames.png
  • Dann dachte ich mir: Warum nicht das Cockpit-Modell vor dem Betrachter rendern? Und warum nicht ein paar Variablen für Geschwindigkeit hinzufügen? … und so hatten wir Ende 2012 einen furchtbar, furchtbar primitiven Flugsimulator.
    2012-08-16 TFXplorer.png
  • 2013 lief dann auch der Sound.
  • Immer, wenn wir dahintergekommen sind, wie das Originalspiel z.B. Schaden verarbeitet, habe ich das natürlich in unserer Software nachgerüstet. So hatten wir Ende 2014 zerstörbare Gebäude.
    2015-01-04 cannon hits.png
  • Ein großer, großer Sprung war dann 2015. Da haben wir die primitive Flugsimulation über Bord geschmissen und den Originalcode reversed – also zwei Monate lang nur Disassembly zu C zurückübersetzt. Im Debugger die Variablen des Originalspiels mit unseren Verglichen. Das war haareraufend, aber seitdem haben wir richtig gute Flugphysik.
  • Ebenfalls 2015 haben wir eine halbwegs brauchbare Physik-Engine programmiert, damit das Flugzeug auch richtig auf den Boden aufsetzen kann und mit dem Terrain kollidieren kann und so. (Verdammt, waren die Reifen schwierig. Die Haftung beim Rutschen habe ich immer noch nicht fertig.)
  • Dann kamen UI-Verbesserungen. Instrumente im Flugzeug, mit denen man richtig interagieren kann. Vernünftiges HUD. Dass man Innen- und Außenperspektive umschalten kann. Usw usf.
  • Ach ja – man kann übrigens auch als Panzer oder als Tankflugzeug spielen; aber das ist augenblicklich noch sehr lieblos.
    Bild
  • Nachdem wir so kompatibel zu Total Air War geworden waren, haben wir Unterstützung für den Vorgänger EF-2000 (1995) eingebaut.
    2016-01-19 TFX2.png
  • Letztens habe ich Kondensstreifen angefangen. Die sind zwar hässlich wie die Nacht, aber sie setzen eine vernünftige Simulation von Wind/Temperatur/Luftfeuchtigkeit voraus, und die funktioniert endlich. (Meinen Recherchen nach bereits besser als in X-Plane, das mit uniformer Luftfeuchte arbeitet.)
  • Aktuell bin ich beim Aufräumen. Weil der Code immer nur zur Benutzung im Model Viewer ausgelegt war, und eher zufällig ein Spiel draus wurde, ist das alles eine einzige Katastrophe. Wir möchten z.B. endlich die Landschaft durch ordentliche Modelle in einem ordentlichen Dateiformat ersetzen können – aber im Originalspiel sind Grafik, Physik, und Gameplay alle im Modell selber definiert, und das muss ich jetzt irgendwie aufgedröselt kriegen.
  • Nächste Schritte also:
    • Ordentliche API, um die Simulation von Rendering/Leveln/Flugzeugen zu trennen.
    • Neues Terrain aus Geodaten. (Ich persönlich möchte auch gern meine extrahierten Ace Combat-Levels durchfliegen können.)
    • Simulationstiefe verbessern. (Aktuell haben wir ein paar tausend Schiffe und ein paar hundert Flugzeuge ohne K.I. im Level, aber das ist alles noch nicht rund.)
    • Netzwerkunterstützung.
    • Neuer Renderer (hoffentlich Vulkan).
    • KI.
Falls ihr es selber antesten wollt: http://community.combatsim.com/topic/31051-tfxplorer/
(Ihr braucht aber entweder Total Air War oder F-22 Air Dominance Fighter oder Super EF-2000!)

Re: [Projekt] TAW-Klon

Verfasst: 24.02.2018, 16:47
von RustySpoon
Sehr, sehr, SEHR geiler Shit, den du da wieder machst! Ich bin immer wieder erstaunt und beeindruckt, wo du die Muse her nimmst über so lange Zeit solchen Sachen zu basteln. Bitte, bitte mehr davon! :D

Ich konnte auch nie richtig verstehen, warum diese Flugsimulatoren praktisch "ausgestorben" sind. Gerade für heutige Konsolen und VR müsste das doch das ideale Genre sein. Apropos, habt ihr schon mal über VR-Support nachgedacht?

Re: [Projekt] TAW-Klon

Verfasst: 24.02.2018, 17:41
von Krishty
Danke!
RustySpoon hat geschrieben:Apropos, habt ihr schon mal über VR-Support nachgedacht?
Klar, aber
  • der aktuelle Renderer ist viel zu langsam
  • Ich weiß auch gerade nicht mehr, wie der VR-Support von D3D 9 ist – wir nutzen noch D3D 9.0c, denn wir haben (oder hatten? Letztes Jahr jedenfalls) tatsächlich noch XP-User :)
  • Ich hatte 2011 TrackIR ausprobiert, aber die haben eine scheiß DRM-geschützte API
Mit dem neuen Renderer dann gern. Übrigens soll Oculus’ Audio-API ganz gut sein (und gratis auch für nicht-VR-Spiele); weiß jemand was darüber?

Außerdem, den letzten Umfragen nach: Wichtiger als VR ist den Leuten, Instrumente auf eigene Bildschirme ausgeben zu können (für selbstgebaute Cockpits). Das wird der neue Renderer wahrscheinlich noch vor VR können.

Re: [Projekt] TAW-Klon

Verfasst: 24.02.2018, 19:23
von joggel
Sieht wieder mal sehr cool aus, und glückwunsch zum dem bisherigem Ergbenis!

Entschuldige die (vlt dumme) Frage.
Habt ihr den SourceCode zu diesem TAW?
Wenn nein, wie geht man dann dabei vor, eine(n) Mod zu programmieren. Man müsste sich ja dann in die Exe "hooken" oder wie man das nennt, und die Resource-Referenzen verbiegen und so.

Auch stelle ich mir immer die Frage, wie man Spiele "seziert", um bspw. an die Assets heranzukommen? Disassemblieren?

Re: [Projekt] TAW-Klon

Verfasst: 24.02.2018, 21:14
von odenter
Krasser scheiss! *thumps up*
Ich habe früher gerne Spiele wie F-117A [1] und EF-2000 gespielt. Habe dafür sogar hunderte Seiten kopiert, wegen des Kopierschutzes. :lol:
Tatsächlich habe ich schon lange keine Flugsimulation mehr gespielt hätte aber Lust auf eine WK2 Simulation weil es nicht das einfache "lock and shoot" ist sondern auch Flugmanöver gefordert sind.

[1] https://www.youtube.com/watch?v=_ij2WAaLPEM

Re: [Projekt] TAW-Klon

Verfasst: 25.02.2018, 02:51
von Krishty
joggel hat geschrieben:Entschuldige die (vlt dumme) Frage.
Habt ihr den SourceCode zu diesem TAW?
Haben wir nicht, und das wäre eigentlich einen eigenen Thread wert. Jemand hat tatsächlich einen Vertrag mit Atari geschlossen, dass das Spiel gemoddet werden darf, mit Quelltextzugang. Als der unterschrieben war, fragte er Atari nach dem Quelltext. Deren Antwort: Haben wir nicht; sucht selber danach :)

Seit jeher melden sich alle paar Monate Leute bei uns und fragen nach dem Quelltext (vor einigen Wochen z.B. jemand von der türkischen Luftwaffe für ein Ausbildungsprogramm). Wir haben aber nichts und wissen nichts.

Ist also keine dumme Frage, sondern eine häufige ;)

Meine Meinung dazu, dass der Quelltext zu großen Teilen wertlos ist, wäre auch einen eigenen Post wert – stellt euch nur mal vor, zwei Millionen Zeilen Code von Visual C++ 5 und Assembler in modernes C++ zu portieren. Außerdem gibt es das 1995er DirectX-SDK, Glide-SDK, und die anderen Abhängigkeiten ja gar nicht mehr zum Download. Interviews mit den Entwicklern lassen auch darauf schließen, dass die Code-Qualität unter aller Sau war.
joggel hat geschrieben:Wenn nein, wie geht man dann dabei vor, eine(n) Mod zu programmieren. Man müsste sich ja dann in die Exe "hooken" oder wie man das nennt, und die Resource-Referenzen verbiegen und so.

Auch stelle ich mir immer die Frage, wie man Spiele "seziert", um bspw. an die Assets heranzukommen? Disassemblieren?
Also, als erstes schaut man sich die Dateien an, die das Spiel benutzt. Ziemlich genau so, wie ich es hier schonmal geschrieben habe – Daten anglotzen und Muster finden.

Bei TAW waren die Archive verschlüsselt und komprimiert; dafür musste tatsächlich disassembliert werden. Das war aber vor meiner Zeit; der Thread dürfte hier sein. Jemand namens Benjamin Haisch hatte in den Dateidaten ein LZ77-Derivat erkannt.

Das Flugmodell war besonders schwer. Hier hat mein Partner DrKevDog einen Debug-Modus in der UI entdeckt, der in der Bildschirmecke anzeigt, wie der aktuelle Geschwindigkeitsvektor des Flugzeugs ist. Wir konnten dann die EXE nach dem String durchsuchen. Dort, wo er verwendet wurde, musste die Adresse des Geschwindigkeitsvektors liegen. Dann konnten wir den Code drumherum disassemblieren und ungefähr erraten, wo die anderen Sachen liegen. (Beispiel: Wenn Geschwindigkeit = x * y, dann kann man sicher sein, dass x und y die Beschleunigung und Dauer darstellen. Man verfolgt „einfach“ die Berechnungskette zurück. Bei uns kamen am Ende um die 400 Variablen raus. Ich poste den Code irgendwann mal. Wir haben auch ein paar dicke Fehler entdeckt.)

Re: [Projekt] TAW-Klon

Verfasst: 25.02.2018, 02:53
von Krishty
odenter hat geschrieben:Krasser scheiss! *thumps up*
Ich habe früher gerne Spiele wie F-117A [1] und EF-2000 gespielt. Habe dafür sogar hunderte Seiten kopiert, wegen des Kopierschutzes. :lol:
Tatsächlich habe ich schon lange keine Flugsimulation mehr gespielt hätte aber Lust auf eine WK2 Simulation weil es nicht das einfache "lock and shoot" ist sondern auch Flugmanöver gefordert sind.

[1] https://www.youtube.com/watch?v=_ij2WAaLPEM
Jemand hat sich bei uns gemeldet, weil er ein F-117A-Remake mit Unity aufziehen wollte. Der Fortschritt war anfangs rasant, aber er bekam Probleme mit Unitys Rechengenauigkeit, wenn die Spielwelt größer als ein paar Kilometer wurde, und seitdem haben wir nichts mehr von ihm gehört. Thread hier: http://community.combatsim.com/topic/43 ... simulator/

EF 2000 würden wir gern komplett emulieren, aber ich möchte den Horror mit dem Reverse Engineering der Flugphysik nicht mit dem Eurofighter wiederholen. ABER wir können bereits TAW-Daten in EF2000-Levels nutzen. Hier z.B. ein schöner Screenshot, für den mein Partner mikew extra Paletten und die Übersichtskarte repariert hatte:
2016-12-05 Norway in TFX3 mode.png
(Ist dunkel, aber so war das Originalspiel eben.)

Re: [Projekt] TAW-Klon

Verfasst: 25.02.2018, 09:06
von joeydee
Top Arbeit von eurem Team, und deine Plaudereien aus dem Nähkästchen sind sowieso immer interessant zu lesen! :)

Re: [Projekt] TAW-Klon

Verfasst: 26.02.2018, 08:34
von joggel
Scheint eine unheimlich aufwendige Arbeit zu sein, also das sezieren... bzw aus den Daten irgend ein Muster zu erkennen.
Zu mal man ja erstmal einige Muster kennen muss..

Das sezieren verstehe ich ja, um an die Assets heranzukommen; die machen das ja Spiel aus, sozusagen
Was ich aber nicht verstehe ist, warum ihr nicht gleich alles selber neu schreibt. Die Assets habt ihr ja. Wieso so umständlich einen Mod schreiben?
Oder geht es um Nostalgie? Also... vong feeling her ?^^

Re: [Projekt] TAW-Klon

Verfasst: 26.02.2018, 10:07
von Krishty
joggel hat geschrieben:Das sezieren verstehe ich ja, um an die Assets heranzukommen; die machen das ja Spiel aus, sozusagen
Was ich aber nicht verstehe ist, warum ihr nicht gleich alles selber neu schreibt. Die Assets habt ihr ja. Wieso so umständlich einen Mod schreiben?
Oder geht es um Nostalgie? Also... vong feeling her ?^^
Das IST ja alles neu geschrieben :) Das spezielle Datenformat erfordert nur leider auch sehr speziellen Code. Die TAW 2.0-Mod ist übrigens auch kompatibel zu unserem neuen Code :)

Re: [Projekt] TAW-Klon

Verfasst: 04.03.2018, 19:02
von Krishty
Etwas, das auf dem Weg von Model Viewer -> Terrain Viewer -> Spiel mitgewachsen ist, sind die Koordinaten.

Am Anfang waren’s drei floats, dann drei ints, nun ist es ein 32768²-Raster mit drei ints pro Zelle. Das ist ein riesen Problem für die APIs und die Austauschbarkeit des Terrains, weil sich die Zellengröße ebenfalls ändern soll.

Eine vierte megakluge Koordinatenklasse ist keine Lösung, denn das Problem hört ja nicht auf. Bei hinreichend großen Levels möchte man Erdkrümmung haben, und da ist der kürzeste Weg zwischen zwei Punkten keine Linie, sondern eine Geodäte. doubles mit Erdzentrum wären eine Option, aber nur mit viiieel Trigonometrie.

Stattdessen schiebe ich so viel wie möglich in die Simulation und sorge dafür, dass die API für Flugzeuge nur noch mit lokalen (Flugzeug-zentrischen) Gleitkommakoordinaten rechnet. Damit wäre das Koordinatenproblem für zukünftige Flugzeuge erledigt und eine saubere Implementierung Sache des Simulationskerns. Dadurch gewinne ich hoffentlich Zeit, ohne was zu riskieren.

Re: [Projekt] TAW-Klon

Verfasst: 31.03.2019, 23:05
von Krishty
Weil Datei-Hoster mal wieder mein TAW-Modding-Tool gelöscht haben, und Image-Hoster mal wieder meine Schnappschüsse gelöscht haben, hoste ich nun alles selber.

Hier habe ich mal 140 Screenshots hingeklatscht, die beim Dekodieren von Total Air Wars Dateiformat angefallen sind: http://krishty.com/taw/3view_en#gallery

Re: [Projekt] TAW-Klon

Verfasst: 04.04.2019, 03:52
von marcgfx
Lädt grad ein bisschen viel Bilder auf einmal (bei mir gehts mega langsam, habe auch nicht die beste Leitung), evtl. erst auf Klick die nächsten 10 laden oder sowas?
edit: Ist glaub wirklich mein Netz, hat inzwischen geladen. Schon gut dass du so viele Bilder über die verschiedenen Schritte machst, könnt ich mir auch ne Scheibe von abschneiden.

Re: [Projekt] TAW-Klon

Verfasst: 04.04.2019, 06:24
von Krishty
Die PNGs waren auch noch nicht optimiert; heute abend müsste die Seite von anfangs 140 MiB auf ca. 60 geschrumpft sein. Habe halt erstmal hochgeladen statt drauf zu warten :)

Re: [Projekt] TAW-Klon

Verfasst: 10.06.2019, 14:05
von Krishty
Sooo, der nächste große Dump – einige hundert Screenshots und Videos über Partikelsysteme, Physik, Kollisionsabfragen, Datenformate, und viele viele Fails: http://krishty.com/taw/tfxplorer_en#gallery

Wenn man von unten nach oben durchscrollt, kann man geradezu sehen, wie aus einem Model Viewer ein Spiel wird.

So ziemlich jedes Bild/Video erzählt eine Geschichte, aber ich bin nicht ansatzweise dazu gekommen, alles aufzuschreiben. Bei Fragen könnt ihr hier einfach den Link zur Bilddatei posten und ich werde antworten.
2013-05-19 not quite right.png
Wenn ich mir das angucke wird mir übrigens auch klar, warum ich seit 2014 so wenig hier auf ZFX gepostet habe …

Re: [Projekt] TAW-Klon

Verfasst: 10.06.2019, 14:34
von xq
Generelles: Sehr geil! Ich kenn leider die Orginalspiele nicht, aber was ihr da macht, sieht gut aus!

Re: [Projekt] TAW-Klon

Verfasst: 16.05.2020, 12:03
von Krishty
Ein neuer Satz Screenshots von meiner Webseite, aber mit dem nötigen Tech-Blabla dabei:


Bild

Ich baue das Spiel gerade vom TAW-Klon zur generellen Flugsimulation um. Bisher war die Farbe des Himmels fest einprogrammiert, weil das in TAW so war. Nun brauche ich aber veränderbare Farbverläufe. Um alle Stellen zu finden, an denen die fest einprogrammierte Farbe benutzt wird, habe ich sie auf was penetrantes geändert.


Bild

Mein Spiel braucht endlich mal eine vernünftige GUI. Da ich Win32-Fan bin, wollte ich die mit Win32 umsetzen.

Hier mein Versuch eines Level-Auswahlbildschirms.

Das Ding ist nicht nur im übelsten Windows-7-Look, es war auch eine Pest, das zu programmieren. Rund 400 Zeilen C++, bis es so aussah.
  • Es ist ein Standard-Win32-List-View.
     
  • Die unterstützen Gruppierung, aber nur durch extra Funktionsaufrufe. Die Gruppen müssen vor den Items hinzugefügt werden, das ist aber nirgends dokumentiert und hat mich eine Stunde Debugging gekostet.
     
  • Die Ansicht dort ist die Tile-Ansicht. Die wurde „erst“ mit Vista eingeführt und erfordert aus Gründen der Abwärtskompatibilität jede Menge Flags und Funktionsaufrufe in der richtigen Reihenfolge.
An dem Punkt habe ich mich entschieden, drauf zu scheißen und die Controls selber in Win32 zu machen.


Bild

Bild

Hier mein eigener Versuch im UWP-Look. Die Controls sind noch immer komplett Win32, aber eben selber geschrieben. Weil Windows drei verschiedene Theming-APIs hat (GetSysColor() bis Windows XP; HTHEME bis Windows 8, UWP danach) und das ein riesiger Haufen Legacy-Scheiße ist, habe ich Themes als First Class Citizen in meine Controls eingebaut.

Windows 10 bietet keine offizielle Win32-API für Light/Dark Theme an. Ich gehe davon aus, dass sie das mit Absicht machen, um UWP zu pushen. Scheiß auf die. Ich greife also in undokumentiertes Territorium, um Light/Dark zu unterstützen:
  • Der Schlüssel Software\Microsoft\Windows\CurrentVersion\Themes\Personalize\AppsUseLightTheme sagt, ob das Dark Theme verwendet wird. Ist er vorhanden, aber 0, ist es Dark.
     
  • Ändert der User das Theme, erhält jede Anwendung eine WM_SYSCOLORCHANGED-Nachricht. Hier solltet ihr einen Timer stellen und kurz warten, bevor das neue Theme übernommen wird, da o.g. Registry-Schlüssel nicht sofort aktualisiert wird.
     
  • Einige wenige Win32-Controls können Dark Theme. Das musste MS für den File Explorer machen, der ja (zum Glück) noch immer nativ Win32 ist. Auch Scroll Bars sind direkt von Dark Theme betroffen. Falls ihr ein eigenes Win32-Control habt, das eine dunkle Scrollbar erhalten soll, müsst ihr folgendes aufrufen: SetWindowTheme(control, L"DarkMode_Explorer", nullptr);
     
  • Die Farbe der Fensterrahmen – unter Windows 10 die Accent Color – wird seit Vista durch DwmGetColorizationColor() mitgeteilt. Das ist nicht undokumentiert, wird aber oft übersehen.
     
  • Ändert der User die Accent Color, erhält jede Anwendung eine WM_DWMCOLORIZATIONCOLORCHANGED-Nachricht.
Ohne Legacy konnte ich außerdem DPI-Awareness als First Class Citizen behandeln. Die UI skaliert tadellos auch auf Bildschirmen mit unterschiedlichen DPI.

Das oben sind die ersten Schnappschüsse; mittlerweile ist auch die Zentrierung der Knopftexte fertig und so.

Ein sehr sehr großes Problem waren die flüssigen Scroll-Effekte. Dafür müssen Fenster passend zum VSync neu gezeichnet werden. Bei UWP passiert das automatisch, da es auf DirectX basiert. In Win32 scheint DwmFlush() zu funktionieren. Die Abfolge von ScrollWindow(), InvalidateRect() und Konsorten richtig hinzukriegen bis nichts mehr flackert oder stottert – weder auf Windows 7 mit Classic Theme noch auf Windows 10 Modern – war richtig hart. Aber nun hat man butterweiche Scroll-Effekte.


Bild

Ich habe testweise das Gameplay in die UI eingebettet. Das war aber totale Scheiße aus zwei Gründen:
  1. DirectX kann zwar in ein Child Window rendern, braucht aber zusätzlich ein Focus Window. Man kann das Gameplay-Fenster also nicht unabhängig vom Anwendungsfenster realisieren.
  2. Raw Input kann sowas nicht. Ich erinnere mich nicht mehr genau, aber irgendwie kamen keine Maus-/Tastatur-/USB-HID-Nachrichten mehr an oder wurden ans falsche Fenster geschickt.
Jetzt ist das Gameplay wieder im Hauptfenster. War eh nur ein Test.


Bild

Testweises Hauptfenster. Beachtet, dass die Vektorgrafik im Hintergrund nicht antialiased ist – das kann GDI nicht. Neben dem VSync-Desaster ein weiterer Punkt, in dem UWP einfach voraus ist.

Dafür läuft die komplette GUI in weniger als 4 MiB RAM. Das reicht bei UWP nicht einmal zum Laden der grundlegenden DLLs (Direct3D + Grafiktreiber schlagen schonmal mit über 100 MiB zu Buche).

Mittlerweile ist die GUI auch deutlich ausgereifter und hübscher; ich muss mal neue Schnappschüsse machen.

P.S.: Noch etwas, das nicht ganz rund ging: Bei Win32-Dialogen bekommt man automatisch die Tastaturnavigation mit; die übernimmt Windows’ Dialog Manager. Also Tab für das nächste Control usw.

Das geht aber nicht, sobald das Spiel Raw Input benutzt. Dann ist das alles einfach tot. Das muss ich also jetzt selber nachprogrammieren.

Ist vielleicht auch besser so, weil ich dann direkt einbauen kann, dass die Controller-Tasten wie Pfeiltasten/Tab funktionieren. Wer möchte schon den Controller beiseite legen und zur Tastatur wechseln müssen, um sich durch die Menüs zu hangeln.

Re: [Projekt] TAW-Klon

Verfasst: 16.05.2020, 20:18
von Krishty
Soo; hier noch ein GIF der Oberfläche:

Bild

Viele Flächen sind noch leer, aber ich fülle das schrittweise mit (asynchronem) Leben.

Ich kann übrigens jedem empfehlen, seine Oberfläche bei normaler Bedienung aufzuzeichnen (ScreenToGif in meinem Fall) und sich das Video in Zeitlupe anzusehen. Man sieht sofort Fehler, die sonst schwer auffindbar wären – etwa Controls, die sich erst im zweiten Frame richtig positionieren; Scrollbars, die erst mit Mausberührung an die richtige Stelle springen, usw.

Hier hatte ich versehentlich die Streufunktion für Luft auf Schwarz gesetzt. Der Himmel ist ja blau weil die Luft blaues Licht stärker streut als rotes (Scattering). Umgekehrt sind rote Objekte deshalb weiter sichtbar als blaue (Extinction). Hier funktionierte die Extinction korrekt, aber das Scattering nicht – und so sah es aus, als würde man durch Cola fliegen.

Bild

Bild

Bild

Re: [Projekt] TAW-Klon

Verfasst: 16.05.2020, 22:44
von Schrompf
Ich finde es enorm, was Du da auf die Beine stellst. Und ich hoffe, dass ich nie in die Gegend komme, um all diese Weisheit selbst zu brauchen.

Re: [Projekt] TAW-Klon

Verfasst: 16.05.2020, 22:48
von Alexander Kornrumpf
Krishty hat geschrieben: 16.05.2020, 20:18
Hier hatte ich versehentlich die Streufunktion für Luft auf Schwarz gesetzt. Der Himmel ist ja blau weil die Luft blaues Licht stärker streut als rotes (Scattering). Umgekehrt sind rote Objekte deshalb weiter sichtbar als blaue (Extinction). Hier funktionierte die Extinction korrekt, aber das Scattering nicht – und so sah es aus, als würde man durch Cola fliegen.
Gibt es viele Spiele die das implementieren? Erwartet die Flight-Sim crowd das? Siegt es subtil unrealistischer aus, wenn man es nicht hat?

Re: [Projekt] TAW-Klon

Verfasst: 16.05.2020, 23:10
von Krishty
Alexander Kornrumpf hat geschrieben: 16.05.2020, 22:48Gibt es viele Spiele die das implementieren?
Seit zehn Jahren gibt es sehr viele Spiele, die das implementieren, ja. Crysis war beispielsweise eines der ersten größeren. Ich sehe gerade, dass die Unreal Engine eine super Dokumentation dazu hat: https://docs.unrealengine.com/en-US/Eng ... index.html
Erwartet die Flight-Sim crowd das? Siegt es subtil unrealistischer aus, wenn man es nicht hat?
In bodenbasierten Spielen sieht es kaum realistischer aus als gut gemachter Exponential Fog mit Dual Color Blending (als RGB unabhängig voneinander vermischt statt über Alpha für alle drei); und deutlich realistischer als normaler Linear Fog. Vor allem weil durch den Redshift die Landschaft an Details verliert, zugleich das eingestreute Blau die Konturen betont.

In Flugsimulatoren ist das seit zehn Jahren eigentlich nicht mehr wegzudenken.

Meine Implementierung ist arg gecheatet und kaum mehr als o.g. Exponential Fog mit Dual Source Color Blending. Trotzdem war vor zehn Jahren einer der ersten Kommentare: „Die Landschaft sieht steinalt und hässlich aus, aber die dunstigen Berge da in der Ferne, das ist echt fotorealistisch“. Hat sich also durchaus gelohnt.

(Hier die Schnappschüsse, auf die sich das bezog)

Bild

Bild

Re: [Projekt] TAW-Klon

Verfasst: 17.05.2020, 00:29
von Krishty
Schrompf hat geschrieben: 16.05.2020, 22:44Ich finde es enorm, was Du da auf die Beine stellst. Und ich hoffe, dass ich nie in die Gegend komme, um all diese Weisheit selbst zu brauchen.
Ja, es ist ein Kaninchenbau.

Das hier habe ich in einer abgespulten Aufnahme entdeckt:

Bild

Das ist das Einblenden einer neuen Seite, aber 60× verlangsamt. Da taucht die Scrollbar auf, bevor der Inhalt angezeigt wird – erster Fehler, okay. Aber die Scrollbar hat Windows 95-Look. Und im darauffolgenden Frame hat sie plötzlich Windows 10-Look. WTF?!

Bin dann eher durch Zufall auf diesen Stack Overflow-Post gestoßen: https://stackoverflow.com/questions/352 ... escrollbar

Da schildert jemand genau das gleiche, aber von C# aus, und auf Windows 7. Und niemand findet einen Workaround, außer das Zeichnen temporär abzuschalten, sobald die Scrollbar das erste Mal angezeigt wird.

Da denke ich also, ich hätte alle Legacy-Scheiße hinter mir gelassen, und vergesse, dass Windows die Scrollbars für mich rendert. Und natürlich haben die Scheißdinger einen Jahrzehnte alten Fehler, der aus Kompatibilitätsgründen nie korrigiert werden wird. FML

Re: [Projekt] TAW-Klon

Verfasst: 17.05.2020, 02:43
von Mirror
Auch ich finde es beeindruckend wieviel Ahnung Du hast. Ich hatte ja schon mehrfach geschrieben dass Du für mich eine Kompetenzbestie bist. Leider bin ich selber nicht der Klügste, nicht der Hellste wie man mir immer gesagt hat. Es gibt wohl kaum ein Thema wo Du Schwächen aufweist. Es ist außerordentlich wie sehr Du dich in fremde Programme einfuchst. Meine Hochachtung, auch wenn meine Hochachtung nicht viel wert ist.

Re: [Projekt] TAW-Klon

Verfasst: 17.05.2020, 09:57
von Krishty
Mirror hat geschrieben: 17.05.2020, 02:43Auch ich finde es beeindruckend wieviel Ahnung Du hast. Ich hatte ja schon mehrfach geschrieben dass Du für mich eine Kompetenzbestie bist. Leider bin ich selber nicht der Klügste, nicht der Hellste wie man mir immer gesagt hat. Es gibt wohl kaum ein Thema wo Du Schwächen aufweist. Es ist außerordentlich wie sehr Du dich in fremde Programme einfuchst. Meine Hochachtung, auch wenn meine Hochachtung nicht viel wert ist.
Ach komm – du weißt, wie gespannt ich immer MirrorCAD verfolge während meine eigenes Tool hier verschimmelt. Das mit der Kompetenz ist auch eher durch Zeit erkauft. Ich mag mich in vielem gut auskennen, aber erst nach Jahren der Einarbeitung (und mit dem Alter wird das immer länger). Als Produktivprogrammierer dürfte ich der Horror sein :D

Re: [Projekt] TAW-Klon

Verfasst: 17.05.2020, 10:43
von Alexander Kornrumpf
Krishty hat geschrieben: 16.05.2020, 23:10 Meine Implementierung ist arg gecheatet und kaum mehr als o.g. Exponential Fog mit Dual Source Color Blending. Trotzdem war vor zehn Jahren einer der ersten Kommentare: „Die Landschaft sieht steinalt und hässlich aus, aber die dunstigen Berge da in der Ferne, das ist echt fotorealistisch“. Hat sich also durchaus gelohnt.

Danke für die Erklärung, in dem Bild kann man den Effekt auch wirklich gut erkennen. Sieht gut aus!

Re: [Projekt] TAW-Klon

Verfasst: 18.07.2020, 23:11
von Krishty
Ich habe den Splash Screen überarbeitet.

Seit Windows 8 ist es ja so, dass Apps keinen Splash Screen mehr haben sollen. Stattdessen öffnet das App-Fenster sofort, ist aber völlig leer – bis auf das App-Logo, das in der Mitte des Fensters angezeigt wird. Sobald die App fertig geladen ist, taucht der tatsächliche Content auf.

Ich finde das verdammt gut. Splash Screens bringen meist furchtbare Fokusprobleme mit sich – dauert das Laden lange und man wechselt zu einer anderen Anwendung, springt einem irgendwann die just gestartete ins Gesicht; schlimmstenfalls, wenn man gerade wo anders tippt. Außerdem kann ich das App-Fenster schonmal auf den richtigen Bildschirm schieben oder auf die passende Größe bringen, während die App noch lädt. Und zu guter Letzt hat man als Anwender sofort die App auf dem Bildschirm; das fühlt sich einfach viel responsiver an. Zwischen dem ganzen UWP-Schmarrn ist das eine Sache, die ich richtig begrüße.

Also wollte ich das ähnlich realisieren. Konkret:
  • Das Hauptfenster soll sofort öffnen. Es soll kein I/O stattfinden und keine Abhängigkeit geladen werden, bevor das Hauptfenster offen ist und eine laufende Nachrichtenschleife hat.
  • Die Initialisierung (DirectX, XAudio, HID API, …) soll in Threads stattfinden. Das brauche ich ja einerseits sowieso, da der Haupt-Thread das Hauptfenster laufen lässt. Andererseits beschleunigt es die Sache ungemein.
  • Statusinformationen sollten im Hauptfenster angezeigt werden. Ich habe manchmal Probleme mit zu langsamen GPUs, nicht installiertem DirectX, etc. Sowas sollte direkt ins Hauptfenster gemeldet werden. (Modale Message Boxes funktionieren kaum mit Threading; Log-Dateien lesen die User nicht.)
  • Falls alles glatt läuft, sollte der Benutzer möglichst schnell im Hauptmenü landen und nicht weiter aufgehalten werden.
Im Resultat zeige ich eine Liste der Hauptaufgaben an (Grafik, Sound, Input-Controller und Plugins). Diese werden abgehakt, sobald der entsprechende Thread erfolgreich abschließt. Ist alles abgehakt, springt das Programm automatisch ins Hauptmenü. Trat ein Fehler auf, wird er direkt im Splash angezeigt und der Benutzer muss händisch auf Accept klicken um ins Hauptmenü zu gelangen. (Oder in die Optionen, sobald es sowas gibt.)

Als GIF vom Start zum Spiel:
Bild

Ich habe das Ganze künstlich ausgebremst, weil man bei realen 0.2 s Startzeit nicht viel sieht. Aber hier wird gemeldet, dass es keinen Ton gibt, weil die DirectX-Runtime nicht installiert ist, und ich muss dann auf Accept klicken.

Wenn alles glatt läuft, sieht man beim Start für einen Sekundenbruchteil den Bildschirm aufblitzen und alles abhaken. In der Zeit, in der sonst halt ein klassischer Splash Screen auf dem Bildschirm gewesen wäre.

Was ganz deutloich fehlt, ist Wiedererkennungswert. Ein dickes Logo oder so; dafür sind Splash Screens ja bekannt. Das ist aber gerade ganz allgemein ein Problem aller Menüs. Ich sollte so langsam Hintergrundbilder implementieren.

Direct3D 9 hat mir einen Strich durch die Rechnung gemacht, weil das nicht mit Multithreading initialisiert werden kann. *Spuck* Sonst wäre die Initialisierungszeit glatt halbiert. Naja, nicht lange bis D3D 11 oder Vulkan.

Re: [Projekt] TAW-Klon

Verfasst: 19.07.2020, 11:00
von Schrompf
Begeistertes Nicken für die Abschaffung der SplashScreens. Ich finde es bemerkenswert, wie konsequent Du jede beliebige Unmöglichkeit abfängst und trotzdem weiter machst. Ich meine: kein Sound wegen DX9-Runtime? Die ist seit Win7 vorinstalliert, soweit ich weiß.

Wenn ich mal groß bin, komme ich auch in die Nähe Deiner Startzeiten. Ne eigene Standardlib werde ich sicher nie schreiben, aber man kann auch so noch einiges rausholen, da bin ich überzeugt.

Bei Vulkan muss übrigens auch einiges im Hauptthread passieren, soweit ich weiß. Kontext-Erstellung auf jeden Fall, Ressourcen vielleicht auch, soweit geht mein Verständnis noch nicht. Das Allokieren, Hochladen und die RenderQueues kann man dann beliebig threaden.

Re: [Projekt] TAW-Klon

Verfasst: 19.07.2020, 12:04
von Krishty
Schrompf hat geschrieben: 19.07.2020, 11:00kein Sound wegen DX9-Runtime? Die ist seit Win7 vorinstalliert, soweit ich weiß.
Leider nicht die Debug-Runtime. Die scheint sich auch kaum jemand installieren zu wollen, der am Quelltext rumdoktort oder debuggt, daher passiert das recht häufig. Und XP unterstütze ich ja auch noch so halb …
Bei Vulkan muss übrigens auch einiges im Hauptthread passieren, soweit ich weiß. Kontext-Erstellung auf jeden Fall
NEEEEEEIIIIIIIIIIIIIN
Bild

Re: [Projekt] TAW-Klon

Verfasst: 19.07.2020, 13:36
von Spiele Programmierer
Schrompf hat geschrieben: 19.07.2020, 11:00Bei Vulkan muss übrigens auch einiges im Hauptthread passieren, soweit ich weiß. Kontext-Erstellung auf jeden Fall, Ressourcen vielleicht auch, soweit geht mein Verständnis noch nicht. Das Allokieren, Hochladen und die RenderQueues kann man dann beliebig threaden.
Woher hast du diese Information? Was meinst du mit einem Context? Ein Device?
Das es da Limitierungen gibt, habe ich nämlich noch nie gehört und schockiert mich gerade ein wenig.

Ich habe gerade mal einen Blick in die Spec geworfen. Ich lese das so, als ob es erlaubt ist. Bei Threading Behaviour wird nämlich behauptet:
VulkanSpec hat geschrieben:All commands support being
called concurrently from multiple threads, but certain parameters, or components of parameters are defined to be
externally synchronized.
und
VulkanSpec hat geschrieben:Any command parameters that are not labeled as externally synchronized are either not mutated by the command or are internally synchronized. Additionally, certain objects related to a command’s parameters (e.g.
command pools and descriptor pools) may be affected by a command, and must also be externally
synchronized. These implicit parameters are documented as described below.
In der Liste steht nur das vkDestroyDevice nicht parallel aufgerufen werden darf. Das ist eh klar.

Im Device-Kapitel selbst finde ich auch keine weiteren Limitierungen zum Threading.

Re: [Projekt] TAW-Klon

Verfasst: 19.07.2020, 13:37
von Schrompf
Krishty hat geschrieben: 19.07.2020, 12:04
Bei Vulkan muss übrigens auch einiges im Hauptthread passieren, soweit ich weiß. Kontext-Erstellung auf jeden Fall
NEEEEEEIIIIIIIIIIIIIN
Keine Garantie, vielleicht geht's ja doch. Ich lese Dokus immer nur, wenn ich muss. Und die Vulkan-Doku soll auch zum Thema Threading sehr gut sein.

Aha, ich sehe gerade, meine Einschränkung wurde bereits von SpieleProgrammierers Richtigstellung überholt.