Console Mode (aka Editor) Remake

By Sven2

Date 19.03.2016 18:53 Edited 20.06.2016 07:46 Upvotes 9

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:
☁ Einfache Dialoge und Sequenzen zum Zusammenklicken
☁ Name und Beschreibung aendern
☁ Mehr Hilfetexte zum Beispiel in der Statusleiste
☁ Eingabe lokalisierter Strings fuer Nachrichten, Titel, Beschreibung, etc.
☁ 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:
:( Vieports crashen bei Spielereliminierung
:( ...

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

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

By Armin

Date 19.03.2016 19:08

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

By Luchs

Date 19.03.2016 19:41

>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).

By Clonk-Karl (More than 50 posts.)

Date 19.03.2016 20:06

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

By Sven2

Date 19.03.2016 20:44

Nein o_O

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

By Clonk-Karl (More than 50 posts.)

Date 19.03.2016 23:00

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.

By Sven2

Date 19.03.2016 23:45

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.

By Sven2

Date 19.03.2016 23:46

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.

By Luchs

Date 20.03.2016 12:13

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.

By Clonk-Karl (More than 50 posts.)

Date 20.03.2016 18:56

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

By Luchs

Date 20.03.2016 18:59

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

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

By Luchs

Date 20.03.2016 21:42

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.

By Sven2

Date 20.03.2016 22:22

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.

By Clonk-Karl (More than 50 posts.)

Date 21.03.2016 05:59

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...

By Luchs

Date 21.03.2016 10:25

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).

By Clonk-Karl (More than 50 posts.)

Date 22.03.2016 05:43

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(?)

By Luchs

Date 22.03.2016 09:47 Edited 22.03.2016 16:53

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.

By Clonk-Karl (More than 50 posts.)

Date 25.03.2016 22:11

Ich denke, das Problem ist, dass QOpenGLWidget seinen eigenen OpenGL-Kontext erzeugt, und der nicht mit dem von uns in CStdGLCtxQt erzeugten Kontext shared. D.h. all die Texturen, Buffer u.s.w. die wir erzeugt haben sind in paintGL nicht vorhanden. Bei mir führt das auch zu einem Absturz in C4TexRef::Lock, weil die Texturgröße nicht mit der Textur übereinstimmt, die in dem anderen OpenGL-Kontext die gleiche Nummer hat.

By Luchs

Date 25.03.2016 22:14 Edited 25.03.2016 22:18

Hm, dann funktioniert wohl die ShareOpenGLContexts-Option nicht richtig. Wird vielleicht der Kontext in CStdGLCtxQt erzeugt, bevor die Option gesetzt wird?

Diesen Absturz hatte ich bisher noch nicht, aber das wäre eine mögliche Erklärung, warum der NVIDIA-Treiber einen Segfault produziert.

By Clonk-Karl (More than 50 posts.)

Date 25.03.2016 22:24

Ich habe eine Lösung gefunden mit der der CStdGLCtxQt-Kontext mit dem QOpenGLWidget context shared (siehe PR auf github). Vielleicht funktioniert "ShareOpenGLContexts" nur zwischen QOpenGLWidgets aber nicht zwischen QOpenGLWidgets und QOpenGLContexts?

Jetzt habe ich immerhin keinen Crash mehr, aber das Rendering funktioniert trotzdem noch nicht. Ich denke das liegt daran, dass VAOs nicht zwischen Kontexten geshared werden, und wir für den QOpenGLWidget-Context keine VAOs erzeugen. Ich schaue mal weiter...

By Luchs

Date 25.03.2016 22:37

>Vielleicht funktioniert "ShareOpenGLContexts" nur zwischen QOpenGLWidgets aber nicht zwischen QOpenGLWidgets und QOpenGLContexts?

Jetzt wo ich die Dokumentation nochmal lese, scheint das wohl tatsächlich der Fall zu sein. Wobei die von "classes like QOpenGLWidget" redet und dabei nicht ganz klar ist, dass QOpenGLContext da nicht mit eingeschlossen ist.

Damit ist tatsächlich auch der Crash im NVIDIA-Treiber gelöst, ich bekomme aber ebenfalls kein Bild.

By Clonk-Karl (More than 50 posts.)

Date 26.03.2016 00:58 Edited 26.03.2016 01:08

Wenn ich unter "Window->New Viewport" einen neuen globalen Viewport erstelle bekomme ich ein Standbild. Wir müssen wahrscheinlich noch bei jedem Spiel-Frame ein redraw des OpenGL-Widgets auslösen.

Nur ein neuer Spieler-Viewport bleibt grau. Vielleicht ist es etwas mit dem FoW.

Edit: Jap, FoW war's. Fixed!

By Clonk-Karl (More than 50 posts.)

Date 22.03.2016 05:56

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? :(

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.

By Luchs

Date 22.03.2016 09:42 Edited 22.03.2016 16:53

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.

By Sven2

Date 27.03.2016 05:53 Edited 27.03.2016 05:56

Okay, funktioniert auch unter Windows mit -opengl dynamic und den DLLs in platforms/! Allerdings wird wohl nicht oft genug gerendert; der Viewport lagt ziemlich.

Und die Scrollbalken vom Viewport sind weg.

By Luchs

Date 27.03.2016 10:16

Ich hatte bei mir den Eindruck, dass nur die Maus etwas lahmt und die anderen Animationen flüssig gerendert werden. Schau ich mir aber nochmal an.

Scrollbalken stehen ebenso auf der Todoliste, aber das dürfte mit Qt ja kein Problem sein.

By Clonkonaut (More than 200 posts.)

Date 27.03.2016 22:59

> Allerdings wird wohl nicht oft genug gerendert; der Viewport lagt ziemlich.

Isilkor hatte irgendwann mal eingebaut, dass bei nicht fokussiertem Fenster nur 5fps laufen. Vielleicht liegt es daran?

By Luchs

Date 28.03.2016 22:38

Scrollbalken sind jetzt wieder drin.

Den Viewport-Lag habe ich mir auch angesehen. Es liegt auf jeden Fall nicht am Rendering, Animationen laufen ja ganz flüssig. Scheinbar werden aber die Mausevents nicht oft genug abgefragt. Wenn ich in C4ConsoleQtViewportView::mouseMoveEvent ein Log mit dem aktuellen FrameCounter hinzufüge und die Maus bewege, dann bekomme ich zwar einen Haufen Events, aber nur in Gruppen alle 2-3 Frames. Dadurch hüpft der Mauszeiger ziemlich.

By Sven2

Date 28.03.2016 22:51

Vielleicht muessen wir die Qt-Eventausfuehrung irgendwie direkter an den Main Loop koppeln. Ich weiss nicht genau, wie oft Console.Execute aufgerufen wird.

By Luchs

Date 16.06.2016 10:03

Das habe ich vor ein paar Tagen gepusht. Wenn der Qt-Editor läuft, wird die Clonk Main Loop über einen QTimer aufgerufen und nicht mehr umgekehrt. Dadurch ist der Lag weg, außerdem scheint es gegen ein paar Crashes mit dem Menü oben zu helfen. Allerdings braucht es jetzt mehr CPU-Zeit, weil die Clonk-Timer aktiv gepollt werden. Das könnte man wohl noch optimieren.

By Sven2

Date 29.03.2016 05:58

Viewport-Lag unter Windows behoben: Habe den Qt-internen VSync abgeschaltet. Das ist auch kein Problem, da Qt intern ohnehin double-buffering verwendet.

By Luchs

Date 29.03.2016 15:49

Ah, gut. Ist bei dir der Mauszeiger jetzt flüssig oder siehst du auch diese Sprünge?

By Sven2

Date 29.03.2016 16:11

Mauszeiger war eigentlich immer fluessig.

By Pyrit

Date 29.03.2016 22:40

Was mir noch eingefallen ist:
Es ist oft schwer, im Editor Objekte zu verschieben, die nur 1 Pixel groß sind (Helferobjekte, Wasserfälle, ...). Könnte man zum Verschieben vielleicht eine Taste auf der Tastatur drücken, um ausgewählte Objekte zu verschieben? :)
Und idealerweise vielleicht sogar noch Tasten zum Rotieren und Skalieren!

By jok

Date 08.08.2016 14:28 Upvotes 2