Console Mode (aka Editor) Remake

Nachdem Projekt nun doch etwas mehr Zeit einnimmt, will ich hier einmal die Fortschritte am neuen Qt-Editor vorstellen. Dies ist nicht der Dateimanager-Editor aus Clonk Rage, sondern das, was als Konsolenmodus bekannt war. Dies ist der Modus, in dem das Spiel aus dem Editor heraus startet; der Modus in dem man live die Landschaft malen und Objekte umherziehen kann (fuer ein remake des CR-Editors, siehe Windmill).

Zunaechst die Probleme des aktuellen Editors:
1. Er ist schwer benutzbar, weil alles irgendwie in kleinen Fenstern steckt, die sich gegenseitig ueberlappten und wahllos nach vorne und hinten springen, wenn man das Werkzeug wechselt
2. Es fehlen Basisfunktionen wie ein Objekt aus einer Liste aller Definitionen zu waehlen und einfach zu erstellen, ohne Script oder Explorer-Drag+Drop zu bemuehen
3. Einige Funktionen wie die Pinselgroessenvorschau sind durch den Zoom inzwischen kaputt
4. Newbies muessen scripten koennen, um banale Aenderungen wie Drehung eines Objektes oder Basiseigenschaften fuer ein Spielziel zu setzen
5. Es fehlen globale Funktionen wie die Kartengroesse zu aendern, die selbst mit Scriptkenntnissen relativ schwer umzusetzen sind

Ausserdem hat keiner hat am Konsolenmodus gearbeitet, weil jede Neuerung fuer drei Platformen parallel entwickelt werden musste (Win32, Mac und GTK fuer Linux). Leider sind Win32 und Mac-Implementierung nicht portabel. Der erste Ansatz, den GTK-Editor fuer alle Platformen verfuegbar zu machen, hat sich als schwierig herausgestellt. Die Windows-Unterstuetzung von GTK ist nicht besonders toll. Deshalb nutze ich als Toolkit Qt, welches sich relativ problemlos in den CMake-Buildprozess integrieren laesst.

Ein Screenshot zum aktuellen Status:


Neuigkeiten bislang:
✓ Alle Editorfenster sind Docks, die sich umherschieben und kombinieren lassen. So ist die Standardoberflaeche etwas aufgeraeumter. Man kann fuer mehr Platz und Entwicklung auf mehreren Monitoren auch alle Docks (z.B. die Viewports herausziehen) und wie bisher zu eigenen Fenstern machen.
✓ Die Objektliste (bekannt aus dem GTK-Editor) wurde uebernommen und um Effekte erweitert
✓ Properties vom ausgewaehlten Objekt lassen sich ebenso anzeigen von von Effekten
✓ Der Landschafts-Tools-Dialog wurde abgeschafft und die Elemente direkt in die Toolbar am oberen Rand integriert. Falls wir irgendwann zu viele Knoepfe haben, kann es auch wieder ein eigenes Dock werden; momentan macht es das Interface erst einmal etwas einfacher
✓ Objekte koennen sehr einfach platziert werden: Definition in der Liste (Sortiert nach Sortierung in Objects.ocd) auswaehlen und mit Linksklick im Viewport beliebig erstellen
✓ Neues Szenario direkt aus dem Editor erstellen
✓ Integration fuer Newbies: Konsole direkt aus dem Hauptmenue starten, Zugriff auf den Benutzerpfad
✓ Einfache Objekteigenschaften setzen (z.B. Eigenschaften fuer Spielziele, Respawnpunkte, etc.): Bislang unterstuetzt sind int, string, color, enum, def, object, shape, proplist, array, any
✓ Startpositionen, Bauplaene und Startmaterial setzen
✓ Objekte drehen und skalieren
✓ Object actions, also z.B. ein Knopf in den Eigenschaften am Tor, der es oeffnet/schliesst
✓ Verbessertes Viewport-Kontextmenue
✓ Bessere Duplizieren-Funktion (dupliziert auch Eigenschaften und verbindet duplizierte Objekte)

Was fehlt und noch kommen soll:
□ EditorProps fuer alle Standardobjekte
□ Landschaft vergroessern/verkleinern
□ Bessere Speicheroptionen (z.B. gepackte Kopie speichern fuers Hochladen) und Speicherknopf in der Werkzeugleiste
□ Tests + Bugfixing
□ Am Ende ein Stream, in dem ein Szenario mit der Community gebaut wird!

Was vielleicht rein koennte:
:cloud: Einfache Dialoge und Sequenzen zum Zusammenklicken
:cloud: Name und Beschreibung aendern
:cloud: Mehr Hilfetexte zum Beispiel in der Statusleiste
:cloud: Eingabe lokalisierter Strings fuer Nachrichten, Titel, Beschreibung, etc.
:cloud: AutoSave z.B. alle 15 Minuten

Was nicht in die Konsole soll (das kann irgendwann z.B. Windmill uebernehmen):
✗ Scripteditor und Editor fuer die ganzen Scenario.txt-Eigenschaften
✗ Objekteditor
✗ Dynamische Landschaften
✗ Gruppendateien verwalten
✗ CCAN/Webintegration

Bugs:
:frowning: Vieports crashen bei Spielereliminierung
:frowning:

Wer selber compilet, kann es unter Windows schon ausprobieren (Branch qteditor).

Hat euch irgendeine Funktion schon immer gefehlt? Dann schreibt sie hier!

Endlich nicht immer wieder aufs Neue Fenster suchen und rumschieben. :happy:

>Hat euch irgendeine Funktion schon immer gefehlt? Dann schreibt sie hier!


- Einen Neustart-Knopf, der das aktuelle Szenario mit einem Klick neu lädt. Das Neuladen von Skripten funktioniert für Objekte ziemlich gut, aber beim Entwickeln von Szenarien muss man recht häufig neu starten.

- Die REPL wäre toller, wenn sie eingegebene Kommandos beim Schließen abspeichern und beim Start wieder laden würde (also so wie das eine Shell auch macht).

Hast du eigentlich auch erwogen, das Ding mit C4GUI zu bauen?

Nein o_O

Dann baut wieder keiner am Editor, weil man fuer jedes neue Control extra arbeiten muss…

Habe mal eine Stunde lang oder so versucht, den Branch unter Linux zu kompilieren, aber das hat noch nicht ganz hingehauen. Man muss dazu erstmal geschickt die Qt-Sachen von den GTK-Sachen entknoten. Vermutlich geht es einfacher, wenn die ganzen anderen Editor-Implementierungen entfernt wurden.

Benutzt du Qt für das komplette Fenster-Management und die Qt-OpenGL-Anbindung zum Rendern, bzw. siehst du das vor? Das würde die Sache wohl etwas erleichtern.

Qt erstellt die Fenster inklusive des Haupt-Fensters und auch der Viewport-Fenster. Fuer die Viewports gibt es dann aber das Windows (HWND)-Handle an C4Window um dort den OpenGL-Kontext zu erstellen.

Vermutlich ist es besser portabel, wenn ein QOpenGLWidget erstellt wird. Von mir aus kann das auch gerne so umgebaut werden. Luchs hatte sich auch schon dazu geaeussert.

Scrollbalken fuer Viewports sind auch noch Windows-Only, sollten dann aber recht einfach in Qt machbar sein.

Ich wuerde es btw gerne so lassen, dass die Engine auch ohne Qt compilet (dann halt ohne Editor). Das erlaubt dann eher einen Port auf Spielekonsolen.

Meine Idee war es, den SDL-Port anzupassen, der ja bisher keinen Editor hat und sich deshalb leichter verändern lässt. Das funktioniert auch schon fast (das Qt-UI funktioniert), aber ich bekomme einen Segfault im Grafiktreiber (NVIDIA), sobald ein Viewport gerendert wird.

Ich werde es vielleicht mal mit einem anderen Grafiktreiber versuchen, da derselbe Crash (SDL-Editor-Viewport ohne Qt) bei Günther nicht auftritt.

Update: Die Materialvorschau aus dem Tools-Dialog ist durch eine Pinselgroessenvorschau direkt im Viewport ersetzt. Im Gegensatz zur alten Vorschau hat sie auch den korrekten Zoom!



Fuer den Objektplatzierungsmodus gibt es ebenfalls eine Vorschau:



und sogar einen Klicksound beim Platzieren!

Cool. Gibt's das irgendwo zum Ausprobieren? Könnte es mit Intel versuchen.

Ich bin jetzt mal auf den Nouveau-Treiber umgestiegen, dort crasht es nicht, aber das Rendering funktioniert leider auch noch nicht so ganz :slight_smile:

Ich werde auf jeden Fall später mal was pushen.

Hier ist mein Code. (diff)

Hab das Rendering leider noch nicht hinbekommen - es gibt momentan nur einen schwarzen Viewport (der aber glaube ich ansonsten funktionsfähig ist ;)). Außerdem wird manchmal der Zoom-Wert auf NaN gesetzt, was dann beim Rendering später einen assert() auslöst. Vielleicht hast du noch eine Idee, was da schief läuft. Vermutlich muss man das alles ein bisschen anders machen, weil QOpenGLWidget es gerne hätte, dass alle OpenGL-Aufrufe innerhalb von paintGL() gemacht werden.

Zoom auf NaN klingt fuer mich so, als ob die Groesse des Viewports irgendwo 0 oder nicht initialisiert ist. Die Zoomlimits werden aus der Viewportgroesse berechnet.

Danke! Werd's mal ausprobieren.

> Vermutlich muss man das alles ein bisschen anders machen, weil QOpenGLWidget es gerne hätte, dass alle OpenGL-Aufrufe innerhalb von paintGL() gemacht werden.


Das ist natürlich doof, weil wir durchaus einige GL-Aufrufe haben die nicht im Render-Code sind, z.B. initialisieren von Texturen, Vertex buffers, etc…

Das dürfte kein Problem sein, weil man auch einen QOpenGLContext direkt anlegen kann, der dann aber nichts anzeigen kann. Das mache ich auch schon so für den Ladevorgang. Man kann außerdem von extern auf den Kontext eines QOpenGLWidget zugreifen, aber ich habe keine Möglichkeit gefunden, das gerenderte dann anzeigen zu lassen (es wird scheinbar generell nicht direkt ins Fenster gerendert, sondern in einen getrennten Puffer).

Hm, aber alle Draw-Calls in QOpenGLWidget::paintGL zu machen sollte dann ja aber eigentlich nicht so schwer sein? Das dürfte ja nur C4Viewport::Draw sein(?)

Hm, da kriege ich eirstmal eine Assertion in "StdStrBuf::Compare(const StdStrBuf&, size_t) const", beim Sortieren des C4ConsoleQtDefinitionListModel. Scheinbar ist die StdStrBuf::Compare-Funktion nicht dafür gemacht Strings mit unterschiedlicher Länge zu vergleichen!? Warum nochmal brauchen wir selbstgebaute Stringklassen? :frowning:

Wenn das gefixt ist kriege ich "openclonk: /home/armin/devel/openclonk/src/game/C4Viewport.cpp:539: void C4Viewport::AdjustPosition(bool): Assertion `Zoom>0' failed.". Das klingt nach deinen NaNs.

Ah. Ich hatte kurz vor dem Pushen nochmal ein Rebase auf Svens neuste Änderungen gemacht. Daher kommt wohl diese erste Assertion.

Die Zoom-Assertion trat bei mir nicht immer auf. Ich bin eigentlich auch der Meinung, dass ich die Viewportgröße korrekt setze. Ich gucke später nochmal, wo das NaN genau herkommt.

Edit: Hab das Zoom-Problem behoben und gepusht.

Ich hatte das eigentlich schonmal versucht, hat aber nicht zum Erfolg geführt. Ist also wohl noch irgendwas anderes fehlerhaft.

Edit: Hab mal was gepusht, sodass das so gemacht wird - ändert leider tatsächlich nichts.