ZFX + Developia

@Schrompf: Das Projekt is nach wie vor sehr sexy! Schön, dass es weitergeht.

Hier ist schon zu lange ruhig!

Ich werf mal ein kleines Experiment in den Raum: WMB-Rendering in OpenGL. WMB ist das Level-Format von Gamestudio, wäre praktisch, da den Leveleditor in eigenen Projekten verwenden zu können, also mal rumgespielt. Ergebnis:

Spezifikation her! Ich habe als Teenager Levels gebastelt; die liegen jetzt hier rum und kann sie seit 15 Jahren nicht anzeigen :)

Leider nur die Spec für WMB7, aber ich denke, die anderen Formate finden sich in den älteren Handbüchern:
http://www.conitec.net/beta/prog_mdlhmp.htm

Für A3-Level kann ich dir sogar nen Loader anbieten, der Firoball hat da mal einen gebaut.

Och schade; in meinen Headern steht WMB4 … aber gut; ist schonmal ein Anfang :)

Krishty, kannst du mir ggf. ein paar Samples deiner Level zukommen lassen? Ich würde da Nachforschungen anstellen, grade weil ich auch n bisschen historischen Kontext der Engineentwicklung sehen kann ;)

Sicher: http://krishty.com/3dgamestudio.7z

Gib bei Problemen bescheid. Ich habe die Dinger, wie gesagt, seit dutzenden Jahren nicht geöffnet.

https://www.infranken.de/regional/nuern ... 23,3815913

der Bier-Automat ist unsere.

Coole Sache! Wir waren auch mal auf der iENA mit einer Erfindung:

Das Einkaufsnavi Nein, ernsthaft!

Mehr von Gamestudio Map Rendering:

Pfade aus der Map extrahieren sowie Map Entities ("rekursive" Unter-Karten) werden jetzt korrekt gerendert (siehe Türe und Brücke)

MasterQ32 hat geschrieben:WMB ist das Level-Format von Gamestudio, wäre praktisch, da den Leveleditor in eigenen Projekten verwenden zu können, also mal rumgespielt.

Ich wünsche mir ja bis heute eine 3D Modeller welcher vom Prinzip her so einfach wie der QERadiant bzw Q3Radiant ist.
Auch das .map Format war quasi selbsterklärend und im Zweifelsfall in den Source schauen welcher frei verfügbar ist.
Habe vor Jahren mal ein kleiner WebGL Renderer mit GWT geschrieben, keine Ahnung warum.
Kenne zwar die neue Version vom GtkRadiant nicht, evtl ist es aber ein Blick wert:
http://icculus.org/gtkradiant/

Ja, GTKRadiant bzw. Netradiant muss ich mir irgendwann auch mal noch angucken

Bisschen rumgespielt und versuche mich jetzt an einem NavMesh:

Ich hab mir das Bild schon paar mal angeschaut und verstehe nicht wirklich was ich sehe. Sind diese Zacken gewollt, oder Fehler weil WIP?

Die roten Linien verbinden jeweils das Zentrum eines Dreiecks mit dessen Nachbarn. Die Zacken ergebnen sich aus dem Basis-Mesh, das der Map Compiler ausspuckt, da kann ich nix dafür ... ;) Ich weiß, die Farbwahl ist auch echt kacke, da erkennt man sowieso nix

Damit wir hier nicht komplett einschlafen:

Ein Prototyp für einen Level-Editor-Gizmo:

Es geht weiter im selben Projekt: Asynchrones Texturladen mit separatem OpenGL-Context+Thread:



Anmerkung: Das Texturladen wird momentan künstlich verzögert, um zu prüfen, ob sich die Anwendung irgendwie doch noch aufhängt

MasterQ32 hat geschrieben:Anmerkung: Das Texturladen wird momentan künstlich verzögert, um zu prüfen, ob sich die Anwendung irgendwie doch noch aufhängt

Application Verifier → ☑ Cuzz

Krishty hat geschrieben:Application Verifier → ☑ Cuzz

Wie meinste das? Ich hab bisher von der WinAPI afaik nur den Kram, der SDL macht (also Message Pumping, Window erstellen, ...). Der Rest ist ja komplett Crossplattform

Auch die Cross-Plattform-Bibiliothek muss ja irgendwie beim Betriebssystem Threads erstellen und synchronisieren – und sobald sie das tut, kann man via AppVerif unter Windows solche Sachen wie Starvation provozieren. Kein Grund, da von Hand Sleeps oder Spins einzubauen.

Krishty hat geschrieben:Auch die Cross-Plattform-Bibiliothek muss ja irgendwie beim Betriebssystem Threads erstellen und synchronisieren – und sobald sie das tut, kann man via AppVerif unter Windows solche Sachen wie Starvation provozieren.

Das wäre dann die C++-Standard-Library (was ja endlich geht und man keine Frickeleien mehr braucht)

Krishty hat geschrieben:Kein Grund, da von Hand Sleeps oder Spins einzubauen.

Ja, wenn man unter Windows entwickelt, sicher nicht verkehrt, aber eigentlich versuche ich grade sogar noch, Windows als "compile platform" aus meinem Environment zu werfen und von Linux aus zu Crosscompilen. Einzig das Testen muss dann noch auf nem Windows gemacht werden

Es geht voran! Das asynchrone Laden ist jetzt noch asynchroner und läuft jetzt auf mehreren Kernen. Zudem gibts nen kleinen Feature Show-Off des bisherigen Krams:




Ich sollte langsam mal nen Projektthread anfangen…

Weiter gehts... Heute mal viele der vorhandenen Features zusammengeklebt und poliert. Das Ergebnis:



Man kann jetzt tatsächlich ein Level bauen! Aber noch nicht speichern...

MasterQ32 hat geschrieben: ↑24.01.2019, 01:11Aber noch nicht speichern...

Hrhrhr. Aber im Ernst: geht doch schick vorwärts! Speichern und Laden sind eigentlich schnell gemacht, die sind nur lästig zu warten.

Sieht schick aus!!! *thumbs_up*

Mein Voxelprojekt ging mal wieder vorwärts. Ich stecke gerade mitten im Infrastruktur-Schrubben, aber ein wichtiger Meilenstein ist geschafft: das detailreduzierte Generieren.

Das Spiel läuft ja in einer Voxelwelt. Die Voxelwelt darf sehr groß werden und passt weder auf Festplatte noch in den Speicher. Daher wird um jeden Spieler herum die Spielwelt deterministisch generiert. Um jeden Spieler herum existieren (anpassbar) 6x6x6 Segmente zu je etwa 100m Würfelkantenlänge. Und wenn ein Spieler etwas weiterläuft, wird hinter ihm eine Schicht Segmente verworfen und vor ihm die nächste Schicht an Segmenten generiert.

Allerdings sind 300m Voxelwelt in jede Richtung ein bissl wenig, um dem Spieler informierte Entscheidungen zu ermöglichen, in welche Richtung sie jetzt losziehen will. Daher habe ich in den letzten Tagen detailreduzierte Landschaftsgenerierung eingebaut. Jetzt gibt es zusätzlich einen oder zwei weitere Voxelmodelle nur um den jeweils lokalen Spieler herum, die mit jeweils einem Achtel bzw. einem 64stel Auflösung generiert werden und entsprechend dann 800m bzw. 6400m große Segmente ausspucken, die aus 40cm bzw. 3,2m großen Voxeln bestehen. Diese detailreduzierten Voxelmodelle sind reine Deko, aber sie sollen die echten Landschaftsstrukturen grob nachbilden, so dass es in der Entfernung zumindest so aussieht wie nachher, wenn man da hin latscht.

Dazu notwendig war auch ein Umschreiben des Landschaftsrenderers, der nun Voxelmeshes fließend aus den drei Voxelmodellen erzeugen kann, je nachdem welches das detaillierteste am Ort verfügbare Voxelmodell ist. Der Landschaftsgenerator ist aktuell sehr simpel: er macht 100m große Säulen zufälliger Höhe mit jeweils einem Baum in der Mitte. Man sieht im Bild aber schön (bzw. man sieht's eben nicht), wo die tatsächlich existierende Spielwelt aufhört und wo die reine Fern-Optik anfängt.

Da ich so ein ähnliches System in meinem Flugsimulator habe zu implementieren versuche, höchste Anerkennung! LOD ist die Hölle. Vor allem, wenn es irgendwann zeitlich veränderlich wird (Schadensmodell; oder … Schornsteine sollen nicht erst zu dampfen anfangen, wenn sie in die Nähe eines Betrachters kommen, sondern dann schon eine ordentliche Fahne haben.)

Noch geht da wenig. Aber ich bin die Woche gut vorwärts gekommen, und versuche jetzt, jeden Abend ne Stunde dranzubleiben, um das Bewegungsmoment nicht zu verlieren.

Bin momentan tief in Projektarbeit eingebunden. Habe heute morgen dennoch etwas Zeit investiert und meine erste App Aurora als VR Version geprototyped.
Hier mal ein ganz kurzer Ausschnitt wie das so ausschaut.



Funktionalität ist noch super eingeschränkt und es ist auch nur normale Gravitation als Ablenkung für die Partikel. Ich weiss auch noch ned, ob ich da noch Zeit weiter investiere. Die App damals hat sich nicht so gut verkauft, aber das Userfeedback war sehr gut.

Hier nochmal die 2D-Version für Android

Finde beides ziemlich cool! Eventuell fehlt eine zündende Idee damit es längerfristig interessant bleibt? Die Aurora abfackeln (wenn ich schon von zündend spreche)? Auto-Aurora wie ein Screensaver, das man im Bett liegend zur entspannung nutzen könnte.