Eigenes GUI

[starcow]

Abend zusammen :-)

Nachdem ich mich etwas in die Windows API eingearbeitet habe, hat sich bei mir die Frage aufgedrängt, wie aufwändig es wohl wäre, eine eigene (rudimentäre) GUI zu programmieren und sich über die Windows API lediglich das Fenster mit einem entsprechenden Screenbuffer zu holen.
Gedacht habe ich dabei an eher rudimentäre Funktionen (was auch immer das heissen mag): Einfache Buttons, Textboxen, Checkboxen und Radio-Buttons. Vielleicht noch Scrolleisten?

Mit einer eigenen GUI bliebe man ja weitgehend plattformunabhängig - und Spiele machen dies ja ohnehin eigentlich fast ausnahmslos alle so. Wieso also dieses Konzept nicht auch bei dem einen oder anderen "Fenster-Tool" verwenden?
Mich würden eure Erfahrungen dazu interessieren. Hab ihr schon mal sowas in der Richtung gemacht? Ist es vielleicht aufwändiger als man anfangs vermuten würde?
Wo seht ihr Vor- und Nachteile einer solchen "hangestrickten" GUI-Lösung, verglichen mit der Gestaltung per Windows API oder Frameworks wie "Qt", "GTK" oder "Dear ImGUI", etc.?

Gruss, starcow

[TomasRiker]

Ich habe sowas schonmal für eines meiner Spiele gemacht. Am Ende kam ein ziemlich cooles GUI-System dabei heraus, das man hier bestaunen kann:



Wie du siehst, habe ich es ziemlich weit getrieben, inklusive mehrzeiliger Eingabefelder, mit Markieren, Kopieren, Einfügen etc.

Quellcode (C++) gibt's auch, falls er dich interessiert: https://github.com/TomasRiker/blocks-5

Es ist schon eine Menge Arbeit, aber macht auch irgendwie ziemlich viel Spaß (mir jedenfalls).

Wenn du das als "Übung" ansiehst, dann klar, warum nicht! Wenn es dir aber in erster Linie um einen produktiven Einsatz geht, dann wäre es meiner Meinung nach Zeitverschwendung, da es schon viele (gute) plattformunabhängige GUI-Libraries gibt.

[Krishty]

Da stimme ich Thomas zu – wenn du lernen möchtest, ist das ein wahnsinnig spannendes Feld. Schließlich läuft in der GUI alles zusammen: Eingaben, Grafik, Sound, Layouting, Textverarbeitung, Copy-Paste, Lokalisierung/Internationalisierung, Accessibility. Außerdem musst du alles zwingend so programmieren, dass es wiederverwendbar und modular ist, sonst stehst du sehr schnell im Regen.

Neben der Plattformunabhängigkeit ist ein weiterer Vorteil einer eigenen GUI, dass du VR abdeckst.

Wenn du hingegen einfach mal ein Spiel fertigkriegen möchtest, ist das das Schlimmste, was du anfangen kannst. Es ist ein Haufen Code, dessen Wartung selten ein Ende nimmt.

Mich würden eure Erfahrungen dazu interessieren. Hab ihr schon mal sowas in der Richtung gemacht? Ist es vielleicht aufwändiger als man anfangs vermuten würde?

Typesetting ist übel. Also wenn du einfach nur Text in ein Textfeld ausgeben möchtest, dann kriegst du das auf jedem Betriebssystem irgendwie hin. Wenn du klickbare Links, unterschiedliche Schriftarten, oder fett/kursiv haben möchtest, ufert das enorm schnell aus – jetzt schreibst du deine eigene Text-Engine. Die muss heutzutage natürlich auch mit Unicode, right-to-left-Steuerzeichen, usw. funktionieren. Natürlich muss es dynamisch sein, falls jemand das Fenster vergrößert. Willst du dann Animationen haben? Den Teil habe ich bisher noch vor mir hergeschoben. Smooth Scrolling war schon schlimm genug.

[Lord Delvin]

Mich würden eure Erfahrungen dazu interessieren. Hab ihr schon mal sowas in der Richtung gemacht? Ist es vielleicht aufwändiger als man anfangs vermuten würde?

Typesetting ist übel. Also wenn du einfach nur Text in ein Textfeld ausgeben möchtest, dann kriegst du das auf jedem Betriebssystem irgendwie hin. Wenn du klickbare Links, unterschiedliche Schriftarten, oder fett/kursiv haben möchtest, ufert das enorm schnell aus – jetzt schreibst du deine eigene Text-Engine. Die muss heutzutage natürlich auch mit Unicode, right-to-left-Steuerzeichen, usw. funktionieren. Natürlich muss es dynamisch sein, falls jemand das Fenster vergrößert. Willst du dann Animationen haben? Den Teil habe ich bisher noch vor mir hergeschoben. Smooth Scrolling war schon schlimm genug.

Das wäre auch meine Warnung gewesen. Wenn man sich spiele mal genau anschaut, dann sind sehr viele UIs einfach nur buttons mit fixem content, die sich vielleicht noch ein bisschen verändern, wenn man sie anklickt oder mit der maus drüber fährt. Wenn die dabei ihre größe verändern ist das picking schon fast immer nicht richtig. Picking scheint mir fast immer über 2D AABBs zu laufen, selbst wenn die UI-Elemente deutlich anders aussehen.

[Schrompf]

Ne eigene GUI kann echt Spaß machen und ich finde, es ist auch ne prima Übung in Objektorientierung bzw. deren Grenzen. Aber ich stimme den anderen zu: es ist enorm viel Arbeit, und wenn Du es in nem echten Spiel verwendest, nimmt die Pflege kaum ein Ende. Und die ganze Geschichte rund um die Lokalisierung - Rechts-Nach-Links-Text (Arabisch) oder Oben-Nach-Unten (Chinesisch u.A.), der ganze Unicode-Zeichenterror, Datum- Währung, Zahlenformate, Pluralformen z.B. im Russischen - bringen nochmal zusätzliche Würze ins Thema. Bei Splatter isses damals schon stumpf daran gescheitert, überhaupt nen Font zu finden, der einen nennenswerten Anteil der auf der Welt verwendeten Schriftzeichen enthält. Mittel- und Osteuropa war bei mir das Ende der Fahnenstange.

Spannendes Thema, finde ich. Aber wenn Dir das zuviel ist - ImGUI wird viel gelobt auch in Spielen. QT, GTK und so sind eher für alt aussehende GUI-Anwendungen geeignet, da aber gegenüber der direkten WinAPI meiner Meinung nach zu bevorzugen. Aber dazu hat Krishty sicher ne andere Ansicht :-)

[joeydee]

Hab ihr schon mal sowas in der Richtung gemacht?

Ja, meine ganzen Experimente, Tools, ZFX-Action-Beiträge etc. nutzen seit Jahren ein eigenes GUI, ich verwende praktisch nichts anderes.

Gedacht habe ich dabei an eher rudimentäre Funktionen

Jupp, meins ist ziemlich abgespeckt, immediate, plus eine kleine Layout-Engine für schnell gebastelte responsive Layouts in wenigen Code-Zeilen (die definiert lediglich eine Liste von Feldern (Rechtecken) mit custom Namen- und Typeigenschaft, ist also an sich unabhängig vom technischen Teil des GUI).
War nicht so schwer (immediate eben) und ist ziemlich schlank und wartungsfreundlich, kann halt auch nicht alles, aber für Games reicht es meist. Zu den genannten Elementen fand ich für meine Zwecke u.a. noch Slider, Statusbalken und Optionsgruppen (edit: ok, Radiobuttons sind genau das) wichtig.

Wieso also dieses Konzept nicht auch bei dem einen oder anderen "Fenster-Tool" verwenden?

Für überschaubare Tools mache ich auch genau das. Allerdings bei einer dichtgepackten Fensteranwendung wie z.B. Blender würde mein Framework schnell an seine Grenzen kommen, und es würden noch viele Elemente fehlen. Von der angesprochenen Lokalisierung mal ganz zu schweigen.

Paar Beispiele aus meinem Fundus:
download/file.php?id=5920&mode=view
download/file.php?id=5208&mode=view
https://www.phoximages.de/uploads/2021/ ... bgijpa.jpg

Ich glaube, ich war ursprünglich durch diesen Artikel auf den Immediate-Zug aufgesprungen und finde es immer noch bestechend einfach und praktisch für die genannten Zwecke.

[Jonathan]

Ich hab für den Landvogt eine GUI geschrieben. Aber eher so aus versehen. In der allerersten Version gab es nur Sprites und Text auf dem Bildschirm, alles in absoluten Pixelkoordinaten gelayoutet. Dann hab ich nach und nach Features dazugebaut, z.B. automatisches Layouting und zusätzliche Elementtypen und irgendwann Unterfenster. Und dann war es schon so ausgeufert dass ich es nicht mehr austauschen wollte: Erstens wegen dem Aufwand, zweitens weil ich meinen Code nicht in den Schredder schmeißen wollte.

Die Entwicklung war halt immer sehr lokal gedacht (dieses kleine Feature einbauen geht schneller als alles auszutauschen), und eine gewisse Zeit lang war das sinnvoll, weil ich explizit schnelle Ergebnisse sehen wollte und eine veröffentlichbare Version wollte. Und das hat ja auch geklappt. Aber ehrlich gesagt wäre die GUI im jetzigen Spiel gewiss besser, wenn ich sie nicht selbst gemacht hätte. Ich denke mir halt immer "Ein Dialog mit der Maus verschiebbar machen oder ein Gameplay-Feature einbauen?" (weil ich halt nur Zeit fürs eines davon habe) und dann gewinnen in der Regel die Gameplay-Features.

Die Sache an fertigen Toolkits ist: Gerade Spiele sollen ja keine standard-GUI haben. Da muss man schon eine Menge anpassen. Eine Windows-Anwendung mit Windows-Standardfenster ist absolut kein Problem, aber jetzt überlegt mal wie ein Diablo aussähe wenn die Lebensenergie eine schöne Progressbar und nicht die ikonischen Glasflaschen wären. Und wenn sowas dann noch schick animiert sein soll braucht es halt schon ein gutes Toolkit, das entsprechend anpassbar ist. Ein ImGUI ist z.b. super leicht und schnell zu benutzen, sieht aber halt einfach blöd aus. Für Tools und Demos ideal, aber mach bitte niemals ein Spiel damit! Ok, vermutlich hat irgendein Typ es mal geschafft selbst ImGUI so lange anzupassen bis es gut aussah, aber dann verstehen wir auch, was die richtige Frage ist: Es ist egal, wie einfach man "eine" Gui mit einem Toolkit machen kann, man muss sich fragen wie aufwändig es ist die GUI die man für sein Spiel haben will damit zu machen. Wenn man sehr viele eigene WidgetTypen hat fährt man vermutlich mit was eigenem besser, weil eigener Code immer leichter anzupassen ist als fremder. Letztendlich ist die Antwort auf die Frage aber vermutlich, dass man das im Voraus gar nicht seriös abschätzen kann, man kann nur rückblickend sagen ob es eine gute oder schlechte Wahl war....

[starcow]

Wirklich sehr cool, was ich da von euch sehe (und lese)! Vielen Dank für die Einblicke, das ist wirklich beeindruckend!
Freut mich zu hören, dass was Eigenes gut machbar sein soll - sofern man sich auf das Wesentliche beschränkt. Eine Übung in der Richtung (und allenfalls später ein "konkreter" Einsatz) finde ich schon sehr reizvoll. Ich kann mir aber auch gut vorstellen, wie schnell man sich in sowas verlieren kann (vom Hundertsten ins Tausendste gerät). Danke für die Warnung an der Stelle.

Neben der Plattformunabhängigkeit ist ein weiterer Vorteil einer eigenen GUI, dass du VR abdeckst.

Läuft dein Flugsimulator(?) denn eigentlich auch in VR, resp. hast du dein GUI aus diesem Grund "VR-tauglich" entworfen?

Bezüglich Hardwarebeschleunigung: Spricht eigentlich was dagegen, für's Zeichnen der GUI-Elemente auf OpenGL oder DirectX zurückzugreifen? Ich meine selbst dann, wenn sich das Programm auf 2DGrafik beschränkt? Die Performance dürfte ja damit erheblich viel besser sein - und man wäre für den Fall bereits gewappnet, sein GUI später mit 3DGrafik zusammen zurendern.
Oder ist das mit Kanonen auf Spatzen geschossen?

[Jonathan]

Bezüglich Hardwarebeschleunigung: Spricht eigentlich was dagegen, für's Zeichnen der GUI-Elemente auf OpenGL oder DirectX zurückzugreifen? Ich meine selbst dann, wenn sich das Programm auf 2DGrafik beschränkt? Die Performance dürfte ja damit erheblich viel besser sein - und man wäre für den Fall bereits gewappnet, sein GUI später mit 3DGrafik zusammen zurendern.
Oder ist das mit Kanonen auf Spatzen geschossen?

Halte ich generell für eine gute Idee. Die Frage ist ggf. noch was das für den Aufwand bedeutet. Bei mir war eh alles OpenGL, da war es das einfachste es auch für die GUI zu benutzen. Ob man extra für die GUI nach OGL wechseln will, obwohl der Rest etwas anderes benutzt ist eine andere Frage. Natürlich kann man auch overengineeren und flexible Render-Backends implementieren, so dass man die GUI auf verschiedene Arten rendern kann. Overengineeren deshalb, weil es sehr fraglich ist, ob du das privat jemals brauchen wirst - und es ist halt ne Menge mehr Arbeit...

Bezüglich Geschwindigkeit: Wenn du es falsch machst, ist die GUI auch in OpenGL langsam. Die Frage ist, was das macht. In einem simplen Spiel hast du vlt. eh nur eine handvoll HUD Elemente, da ist es total egal wie schnell die rendern.

Generell ist es sehr gut, wenn du vorher weißt, was du brauchst. Man kann alles einbauen, aber dann wird man halt nicht fertig. Wenn man sich stark spezialisieren kann, ist man dagegen vlt. nach nem Wochenende schon fertig.

[Krishty]

Neben der Plattformunabhängigkeit ist ein weiterer Vorteil einer eigenen GUI, dass du VR abdeckst.

Läuft dein Flugsimulator(?) denn eigentlich auch in VR, resp. hast du dein GUI aus diesem Grund "VR-tauglich" entworfen?

Nein; meine GUI rendert nicht selber sondern basiert auf Win32/GDI. Ich bereue das aus zwei Gründen: 1) Ich kann damit kein VR oder in-game-Bedienung; 2) ich habe keine Kontrolle über die Bildwiederholrate. Die nächste Iteration dürfte auf Vulkan o.ä. fußen.

Bezüglich Hardwarebeschleunigung: Spricht eigentlich was dagegen, für's Zeichnen der GUI-Elemente auf OpenGL oder DirectX zurückzugreifen? Ich meine selbst dann, wenn sich das Programm auf 2DGrafik beschränkt? Die Performance dürfte ja damit erheblich viel besser sein - und man wäre für den Fall bereits gewappnet, sein GUI später mit 3DGrafik zusammen zurendern.
Oder ist das mit Kanonen auf Spatzen geschossen?

Ist sinnvoll; hinter den Kulissen basieren viele GUI-Frameworks auf einer 3D-API. Nicht zuletzt baut der Desktop Window Manager von Windows ja ebenfalls auf DirectX und realisiert damit solche Dinge wie Blur hinter den Titelleisten.

Ich zögere da vor allem wegen a) Working Set (als ich das letzte Mal geschaut habe, verbrauchte das Starten von Direct3D 9 satte 120 MiB Prozessspeicher) und b) Latenz zum Initialisieren (es kann “kalt” schonmal eine Sekunde dauern, bis Vulkan/D3D gestartet sind – bis dahin hast du schlimmstenfalls keine GUI).

[Krishty]

Halte ich generell für eine gute Idee. Die Frage ist ggf. noch was das für den Aufwand bedeutet. Bei mir war eh alles OpenGL, da war es das einfachste es auch für die GUI zu benutzen. Ob man extra für die GUI nach OGL wechseln will, obwohl der Rest etwas anderes benutzt ist eine andere Frage. Natürlich kann man auch overengineeren und flexible Render-Backends implementieren, so dass man die GUI auf verschiedene Arten rendern kann. Overengineeren deshalb, weil es sehr fraglich ist, ob du das privat jemals brauchen wirst - und es ist halt ne Menge mehr Arbeit...

Und dann kommt z. B. DirectWrite, das eine bestimmte Art von D3D Device erfordert und dann sowieso ausfällt :(

[Specialist]

Kleine Anmerkung am Rande. Was ich häufig insb. in GUIs von Spielen sehe ist, dass die sich auf ein paar sehr einfache Widgets beschränken. Klar kann man RadioButtons, Checkboxes, Dropdownboxen, Slider bauen und das sieht auch schick aus und hat alles seine eigenen Anwendungsfälle, aber man kann alle diese Fälle auch einfach mit Dropdownboxen abfangen. Natürlich ist es einfacher eine Checkbox anzuklicken, als erst die Dropdownbox zu öffnen und dann "ja" oder "nein" zu wählen. Aber sich bei der Entwicklung absichtlich zu beschränken würde die Sache erstmal einfacher umsetzbar machen. Es kommt halt drauf an was du willst :)

[Krishty]

Klar kann man RadioButtons, Checkboxes, Dropdownboxen, Slider bauen und das sieht auch schick aus und hat alles seine eigenen Anwendungsfälle, aber man kann alle diese Fälle auch einfach mit Dropdownboxen abfangen. Natürlich ist es einfacher eine Checkbox anzuklicken, als erst die Dropdownbox zu öffnen und dann "ja" oder "nein" zu wählen. Aber sich bei der Entwicklung absichtlich zu beschränken würde die Sache erstmal einfacher umsetzbar machen.

Das finde ich lustig, weil ich Checkboxes weitaus einfacher implementierbar fand als Dropdownboxes. Bei letzteren musst du zumindest Z Order implementieren (aufgeklappte Auswahlliste muss andere Controls überdecken); Fokus bedenken (Fokusverlust schließt die Auswahlliste); Scrolling für Child Windows implementieren; eine Verbindung zum Hauptfenster aufbauen (damit eine Auswahlliste am unteren Rand nach oben öffnet und oben umgekehrt, um den sichtbaren Bildschirmbereich nicht zu verlassen; Implikationen für Infrastruktur nicht unterschätzen weil Dialoge ja geschachtelt sein können!); überlange Strings handhaben, usw.

Eine Checkbox hingegen ist in Win32 schlicht als ein Button mit zusätzlichem Bool implementiert. Sie hat immer die selbe Größe, interessiert sich nicht für Kinder oder Eltern, und zeichnet höchstens mal leicht anders.

[Jonathan]

Ich hab in der Landvogt GUI quasi nur Buttons. In Age of Empires z.B. gibt es zwar im Hauptmenü viele verschiedene Widgettypen, aber sobald man im Spiel drin ist gibt es auch da (obwohl es ja schon komplex ist) eigentlich nur Buttons. Vielleicht weil man die so schön schnell benutzen kann.
Ich glaube das einzige zusätzliche Widget das ich habe sind Progress-Bars die Füllstände anzeigen. Alles andere könnte man benutzen, muss man aber nicht unbedingt und dann muss man es auch nicht implementieren.

Was ich leider gar nicht drin habe, ist irgendeine Art von Fokus. Buttons kann man einfach immer anklicken, solange sie denn sichtbar sind. Das hat mich erst wieder eingeholt als ich in Harald Hoppelhase gerne eine Tastatursteuerung fürs Hauptmenü haben wollte, damit die Maus komplett optional ist.Die ist da jetzt ein extrem hässlicher Hack (die Maus wird bewegt und ein Mausklick simuliert) der nur im Hauptmenü funktioniert, aber naja, das ging schnell und mehr brauchte ich erstmal nicht.

[Schrompf]

Man kommt mit Buttons, Textfeldern, vielleicht noch Checkboxen schon recht weit. DropDowns hab ich als CycleButton implementiert. Und mit nem einfachen Fokus-System - ich hab nur Enter/Leave-Events und einen einzelnen Focused-Pointer - kann man schon ne Menge machen. Ich füttere die aktuellen Richtungs-Events (Default: WASD und Cursor) in die GUI und werde das auch noch mit dem Gamepad-Stick machen, und dann guck ich einfach vom aktuell fokussierten Element aus in die Richtung und fokussiere das nächste Widget in der Richtung. Macht nen ganz erträglichen GUI-Bedienfluss selbst mit nem Controller.

[smurfer]

Ich kann mich nur anschließen, auch ich finde es eine interessante Aufgabe, die auch je nach Erfahrung viel zum Lernen beiträgt. Ja, manchmal wird es später unübersichtlich, aber gerade wenn es sich mehr um ein Hobbyprojekt handelt, muss auch nicht gleich die letzte Eventualität mit Sprachen, UTF, usw. angegangen werden.

[Zudomon]

Für mich stellt sich die Frage, ob bei einem Browsergame eine eigene GUI überhaupt noch Sinn machen würde.
Zwar verwende ich bei mir ja WebGL, wodurch die GUI Elemente entsprechend schnell rendern würde. Aber mit HTML/CSS hat man ja alles mögliche an Funktionalität direkt an der Hand und sicher auch noch optimierter, als man es selbst hinbekommen kann.
Selbst Spezialeffeke wie Schatten, Glow, Blur und Animationen bekommt man mit CSS geliefert.