[GUI] Graphische Benutzerschnittstelle

[exploid]

...

[Krishty]

… neben die Tüte gewürgt: Es gibt [ code = cpp ] [ / code ] (ohne Leerzeichen) für ganz genau solche Code-Beispiele ;)

Zum Code-Beispiel ist noch zu sagen, dass da die Positionen fehlen – mir fällt auf Anhieb nichts ein, was eine Breite und Höhe hat, aber keine Position.

Wenn du nicht hunderttausende Elemente erzeugst, fragmentiert eine verlinkte Liste nicht merklich. Ab Vista wird außerdem ein Low-Fragmentation-Heap genutzt, der auf genau solche Fälle zugeschnitten ist.

Grundsätzlich bin ich aber für eine Komposition aus Basiselementen, wie du sie vorschlägst.

Gruß, Ky

[Seraph]

Kurz mal angerissen wie ich es ungefaehr gemacht habe:

Basis-Klasse 'Control', welche auf das Parent verweist und eine Liste von Kindern enthaelt. Ich habe von 'Control' eine Klasse 'Screen' abgeleitet, welches sozusagen meine Root- oder Top-Klasse ist. Diese ist die einzige UI-Klasse welche direkt gezeichnet werden kann, alle anderen muessen ihr hinzugefuegt worden sein.

Sowohl fuers Rendering als auch fuer Mouse-Events gehe ich dann halt den Baum durch. Beim traversen der Maus-Abfrage wird das zuletzt gefundene (gueltige) Element im Screen 'gespeichert'. So kann ich beim naechsten Update() direkt da anfangen, was halt der beste Fall waere.

Obiges ist nicht 100%ig korrekt und stellt nur eine Art rudimentaere Erklaerung dar, das Prinzip sollte jedoch deutlich werden.

Und da Krishty schon fehlende Positionen (da fehlt wahrscheinlich noch 'ne Menge mehr :D) angesprochen hat. Ich wuerde Dir empfehlen eine Klasse 'Point' und 'Rectangle' zu erstellen und Rectangle fuer das Speichern der Position und Groesse zu benutzen. Du wirst wahrscheinlich auch irgendwann Rectangles fuer verschiedene Dinge nutzen wollen, z.B. absolute Koordinaten, relative zum Parent, evtl. noch spezielle fuers Rendern und irgendwann evtl. noch ein ClientRect.

Hier mal ein ca. 3 Monate alter Screenshot meiner GUI, natuerlich work in progress und programmer art. ;)

[exploid]

...

[dowhilefor]

Ein Guter Tip von mir, der eine Menge arbeit ersparen kann. Positionen sollte man gar nicht setzen können. :) Ich weiß manche fluchen darüber, aber wenn es anständig gemacht ist, hat man Layouter die sich um die letzte Positionierung kümmern. Positionen setzen sind immer schwierig wenn man unterschiedliche Auflösungen unterstützen will. Lieber solche Sachen Layouter übernehmen lassen. Und dann auch gleich Abstand nehmen von Größe, auch das ist aufgabe des Layouters.
Als referenz empfehle ich mal sich WPF anzugucken, WPF Als GUI für Spiele fänd ich ideal.

[Seraph]

Die WPF ist imho denkbar ungeeignet fuer Spiele. Viel zu viel Overhead. Flexibilitaet ist toll und da hat die WPF einiges zu bieten, aber das kommt auch zu einem Preis. Ich sag mal nur Event-Bubbling.

Layouter sind eine nette zusaetzliche Moeglichkeit, welche ich auch unterstuetze und die in bestimmten Bereichen durchaus Sinn machen und auch die Arbeit abnehmen koennen. Direkte Positionen nicht setzen zu koennen waere abhaengig vom Spiel fatal. Kannst Du Dir ein EVE Online oder auch ein WoW vorstellen, wo man die direkte Position nicht setzen kann? Ich nicht und ich vermute ein sehr grosser Teil der anderen Kunden auch nicht. Im uebrigen kann man auch in WPF haeufig die Position immer noch selbst setzen.

[Despotist]

Habe mir auch schon Gedanken gemacht wie man die GUI auflösungsunabhängig darstellt.
Dafür wäre es nötig die Positionen als Gleitkomma-Werte zwischen 0 und 1 zu speichern die dann einfach nach jedem Wechsel der Auflösung mit der aktuellen Kantenlänge multipliziert werden um die neue Position zu bekommen. Die Schriftgröße wird so gewählt dass der Text gerade so in das Feld reinpasst.
Was haltet ihr von so einem Ansatz? Das einzige Problem das ich sehe ist 16:9 und 4:3.

[Seraph]

Das war glaube mein erster Ansatz als ich damit angefangen habe. Afair hat er leider mind. zwei Nachteile, einer war fuer mich dann endgueltig entscheidend, es nicht weiter zu benutzen.

1. Du bekommst manchmal Probleme - insbesondere bei Texten - damit etwas optisch einwandfrei anzuzeigen, was daran liegt, dass die Position zwischen zwei Pixel liegt. Das Problem kann man natuerlich loesen.

2. Der fuer mich entscheidene Punkt. Ich lese meine GUI aus XML-Files ein und ich (Designer wohl erst recht :D) finde Pixel-Zahlen bedeutend aussagekraeftiger als Alpha-Werte, wo ich dann bei einigen Werten wohl doch einen Taschenrechner vorholen muss. Wenn man sich natuerlich die Muehe macht und einen entsprechenden Designer schreibt, koennte man den Ansatz evtl. dennoch nutzen. Aber imho ist es die Muehe einfach nicht wert.


Ich nutze halt Layouts und Layout-Mechanismen wie Anker und 'Docker'. Ebenso habe ich einen globalen Scale-Faktor drin. Schriftarten skaliere ich allerdings nicht, sondern benutze einfach verschiedene vorgenerierte Groessen, die abhaengig von der Aufloesung geladen werden muessen. Skalierte Texte waren imo nicht gut genug lesbar. Fuer wenig Text in der Welt kann man sowas evtl. machen, fuer einen Chat oder Tooltips eher nicht.

[Lord Delvin]

Habe mir auch schon Gedanken gemacht wie man die GUI auflösungsunabhängig darstellt.
Dafür wäre es nötig die Positionen als Gleitkomma-Werte zwischen 0 und 1 zu speichern die dann einfach nach jedem Wechsel der Auflösung mit der aktuellen Kantenlänge multipliziert werden um die neue Position zu bekommen. Die Schriftgröße wird so gewählt dass der Text gerade so in das Feld reinpasst.
Was haltet ihr von so einem Ansatz? Das einzige Problem das ich sehe ist 16:9 und 4:3.

Warum nimmst du nicht absolute Pixelwerte und mappst negative Werte auf Distanzen vom Entgegengesetzten Rand? Also so, dass du sagst ein Fenster befindet sich an Position (-10, 10) und ist 10x10 groß, also ist es in der unteren rechten ecke...oder in ner anderen ecke, jenachdem wo du dein Koordinatensystem so hinlegst. Damit solltest du eigentlich alle layoutprobleme behoben bekommen. Wenn das nicht reicht, dann brauchst du halt ne funktion, die dir die Aktuelle größe gibt, aber ehrlich gesagt finde ich diese Mitskalierenden GUIs eigentlich ziemlich hässlich, weil sie unnötig viel platzeinnehmen, wenn sich die Auflösung von 1280*1024 auf 1920*1200 erhöht. Und leider haste heute immernoch irgendwas dazwischen. Und wenn man laptopauflösungen mit reinnimmt, dann wirds ganz gruselig. Und du kannst mit dem Ansatz pixelgenau Grafiken für guielemente machen, die immer gut aussehen:)

[Krishty]

Noch was: DPI-Awareness (imo immer wichtiger, denn in fünf Jahren wird die Schrift endgültig unlesbar klein sein) ist damit schlecht möglich …

… im Grunde habt ihr dasselbe Problem wie alle Web- und Formdesigner auch.

[dowhilefor]

Die WPF ist imho denkbar ungeeignet fuer Spiele. Viel zu viel Overhead. Flexibilitaet ist toll und da hat die WPF einiges zu bieten, aber das kommt auch zu einem Preis. Ich sag mal nur Event-Bubbling.

Also ich hab jetzt einiges mit WPF gemacht und würde mir schon WPF als Ingame Gui Framework wünschen. Klar ist es aufwändiger als mal eben ne Textbox erzeugen und im Code alles zu machen. Aber die strikte Trennung zwischen Code und Gui/Design/Layout find ich perfekt.

Layouter sind eine nette zusaetzliche Moeglichkeit, welche ich auch unterstuetze und die in bestimmten Bereichen durchaus Sinn machen und auch die Arbeit abnehmen koennen. Direkte Positionen nicht setzen zu koennen waere abhaengig vom Spiel fatal. Kannst Du Dir ein EVE Online oder auch ein WoW vorstellen, wo man die direkte Position nicht setzen kann? Ich nicht und ich vermute ein sehr grosser Teil der anderen Kunden auch nicht. Im uebrigen kann man auch in WPF haeufig die Position immer noch selbst setzen.

Ich sehe nicht wo das bei den von dir genannten Spielen ein Problem wäre. Clevere Controls die ähnlich wie die Toolbar in WPF ihr Aussehen ändern, wenn ihnen der Platz ausgeht (WoW Skilleiste; Platz zu klein = kleine Gargoyle Figuren ausblenden). Klar das sich Fenster immer noch vom Benutzer verschieben lassen und klar ist auch das manchmal einfach ein Canvas für direkte Positionierung nötig ist, aber das meiste lässt sich eben über gute Layouter regeln.
Ich hab die Erfahrung gemacht das man mit einem zu einfachen GUI System einfach zuviel Zeit am Ende eines Spiels in die GUI stecken muss, gerade was Positionierung angeht. Vorallem in kleineren Spielen die ich bisher gemacht habe, lief es immer darauf hinnaus: Starten, gucken, Button sitzt etwas zu tief, beenden, Code ändern, neustarten wieder gucken. Man darf einfach nicht unterschätzen wieviel Zeit GUI fressen kann. Genauso wenig darf man vernachlässigen wie wichtig eine gut gemachte GUI ist.

Habe mir auch schon Gedanken gemacht wie man die GUI auflösungsunabhängig darstellt.
Dafür wäre es nötig die Positionen als Gleitkomma-Werte zwischen 0 und 1 zu speichern die dann einfach nach jedem Wechsel der Auflösung mit der aktuellen Kantenlänge multipliziert werden um die neue Position zu bekommen. Die Schriftgröße wird so gewählt dass der Text gerade so in das Feld reinpasst.
Was haltet ihr von so einem Ansatz? Das einzige Problem das ich sehe ist 16:9 und 4:3.

Hab ich auch mal probiert für ein XNA Game. Ich find das persönlich ein absoluten Graus. Du sitzt ständig mit Taschenrechner daneben um rauszufinden wo ein Control jetzt letztenendes liegt. Mit einem Editor würde das wieder Sinn machen, aber wenn du die Werte selber eintragen musst würde ich das lassen.

[Chromanoid]

Habe mir auch schon Gedanken gemacht wie man die GUI auflösungsunabhängig darstellt.
Dafür wäre es nötig die Positionen als Gleitkomma-Werte zwischen 0 und 1 zu speichern die dann einfach nach jedem Wechsel der Auflösung mit der aktuellen Kantenlänge multipliziert werden um die neue Position zu bekommen. Die Schriftgröße wird so gewählt dass der Text gerade so in das Feld reinpasst.
Was haltet ihr von so einem Ansatz? Das einzige Problem das ich sehe ist 16:9 und 4:3.

Was haltet ihr von LayoutManagern? Bei WPF gibt es doch auch welche... Bei Java funktioniert das eigentlich ziemlich gut. Man muss einen guten Layout-Designer dafür haben, aber dann kann man ohne Probleme auflösungsunabhängiges GUI entwerfen. Wenn man das ganze dynamisch haben will, muss man es eben noch dynamisch über Dateien ladbar machen... Im Grunde reicht ja ein TableLayoutManager, der ähnlich wie die HTML-Table funktioniert...

[Despotist]

Hab ich auch mal probiert für ein XNA Game. Ich find das persönlich ein absoluten Graus. Du sitzt ständig mit Taschenrechner daneben um rauszufinden wo ein Control jetzt letztenendes liegt. Mit einem Editor würde das wieder Sinn machen, aber wenn du die Werte selber eintragen musst würde ich das lassen.

Natürlich wäre das hardcoden der Positionen suboptimal und manuell mit Taschenrechner natürlich auch. Ich hätte es einfach so gedacht dass man das Layout in einer Auflösung erstellt (Editorähnlich oder wie auch immer) und dann wird das ganze in Gleitkommawerte umgerechnet und als xml exportiert. Das GUI-Element hält dann die Koordinaten einmal als float zwischen 0 und 1 und einmal als int mit dem Wert für die aktuelle Auflösung. Wenn die Auflösung geändert wird wird durch alle Elemente iteriert und jedes aufgefordert seine Position in der neuen Auflösung zu berechnen. Dabei wird ebenfalls die passende Schriftgröße gewählt (nicht skaliert) mit der der Text gerade so reinpasst. Ist natürlich problematisch bei veränderlichen Texten. Da müsste dann entschieden werden ob die abgeschnitten, gescrollt oder per Quickinfo gezeigt werden.
Ich weiß auch nicht ob es so wirklich gut aussehen würde aber bei gleichem Seitenverhältnis sollte es eigentlich klappen. Andersrum wenn man für jede mögliche/unterstütze Auflösung das ganze manuell macht artet es genauso in Arbeit aus vor allem dass es "gleich" aussieht. Da finde ich den automatischen Ansatz entspannter und wahrscheinlich ist er auch zeitsparender.

[zwergmulch]

@WPF als In-Game-GUI: Müsste imho mit etwas Aufwand (aber im Vergleich zum Selbermachen noch immer gering) gehen (siehe diesen Artikel).
Man nimmt ein Fenster, zeichnet in dieses und drumherum hat man seine GUI.
Den einzelnen Steuerelementen kann man dann noch Templates zuweisen damit die besser aussehen und voilà - Man hat eine GUI mit WPF. Ist aber nur so eine "abstrakte" Idee - ich garantiere für nichts. ;)

@Java/Layoutmanager: Layoutmanager finde ich auch ganz gut. In Java/Swing/AWT sind die ja für einzelne Container einstellbar, in WPF muss man seinen Container nach dem Layout wählen.
An WPF finde ich aber die Trennung von GUI-XML-Code und dem "richtigen" Code besser. Wer sein Layout schon mal mit dem GridBagLayout selbst geschrieben hat, weiß was ich meine... :D

[exploid]

...

[Seraph]

@WPF: Klar, wenn das Spiel ansonsten keine Ressourcen benoetigt, kann man auch die WPF benutzen. ;) (Und wie gesagt, die Idee ansich ist gut, auch die des MVVM/P, im Moment aber imho nicht praxistauglich.).

@WoW und EVE: Also so wie ich es kenne und auch selbst gespielt habe, war nichts mehr dort wo es vorher war und Layouter haetten dort klaeglich versagt, wenn ich nicht unsichtbare Controls, Margins, o.ae. benutzt haette, wobei ich dann aber eher fuer eine direkte Positionierung bin. Einige Layout-Techniken wie Docking, Anchoring sind natuerlich immer noch von Vorteil. Layouter in WoW sind allerdings eine gute Idee fuer Taschen oder mehrere Fenster nebeneinander. In EVE hingegen machen sie teils noch weniger Sinn, da es im Grunde genommen ja mehr oder weniger nur eine View auf eine DB ist und man die Fenster eh oefters mal durch die Gegend schiebt.

Ich straeube mich auch nur gegen deine Aussage: "Positionen sollte man gar nicht setzen können. :)"

[dowhilefor]

Layouter in WoW sind allerdings eine gute Idee fuer Taschen oder mehrere Fenster nebeneinander

Ich bin mir nicht ganz sicher ob wir dasselbe mit Layoutern meinen. Es geht mir darum bspw nicht hingehen zu müssen und Label und Textbox Pixel genau gegeneinander auszurichten. Das ist arbeit die ein Layouter direkt kann dazu noch DPI und Auflösungsunabhängig (wenns anständig implementiert ist). Eine WoW Inventar Tasche ist ein WrapPanel oder UniformGrid, die Skillleiste lässt sich ebenso machen.

@WPF: Klar, wenn das Spiel ansonsten keine Ressourcen benoetigt, kann man auch die WPF benutzen. (Und wie gesagt, die Idee ansich ist gut, auch die des MVVM/P, im Moment aber imho nicht praxistauglich.).

Naja WPF direkt in einem Spiel will ich nicht benutzen, dafür ist die Performance noch grausig. Aber das Konzept finde ich sehr gut und lässt sich imo auch gut in Spielen verwenden.

@WoW und EVE: Also so wie ich es kenne und auch selbst gespielt habe, war nichts mehr dort wo es vorher war und Layouter haetten dort klaeglich versagt

Margins wird man eigentlich immer haben, aber mir ist jetzt noch nichts untergekommen was wir nicht mit den WPF Layoutern hätten Regeln können, ohne irgendwelche Fummelleien.

Letztenendes endet das aber in Geschmacks und Philosophie fragen. :) Wenn man eines aus WPF lernen kann ist es das man Code von UI so weit wie möglich trennen sollte. Ich möchte nie wieder pixel im Code setzen müssen. Idealerweise sollten diese "GUI Dateien" auch zur laufzeitbar nachladbar sein, was eine Menge arbeit ersparen kann.

[Seraph]

Okay, Du bist wohl primaer vom Inhalt der Fenster ausgegangen, ich von den Fenstern selbst. Deshalb wohl der 'Konflikt'.

@Layouter in genannten Spielen: Ich habe einfach mal das erste passende Bild bei Google-Images genommen. Zu sehen ist eine wirre Anordnung von Fenstern. Da die Fenster sowohl von der Groesse als auch von der Anzahl her flexibel sind, halte ich Layouter hier (und insbesondere die Verweigerung einer direkten Positionsangabe) fuer ungeeignet.

@WPF: Mit dieser Aussage stimme ich ueberein.

@zwergmulch: Der Artikel zeigt aber nur, wie man auf ein WPF-Objekt zeichnet. Oder wolltest Du beispielsweise mit einem Panel, in welches gerendert wird, den Hintergrund ausfuellen und dann andere Controls einfach drueber packen? Geht zwar sicherlich, aber am optischen Erfolg zweifle ich hingegen jedoch ein wenig.

[zwergmulch]

So ungefähr dachte ich das mir (habe ich ja auch geschrieben - es geht sicher irgendwie, nur ob es so sinnvoll ist kann man bezweifeln).

[dowhilefor]

@Layouter in genannten Spielen: Ich habe einfach mal das erste passende Bild bei Google-Images genommen. Zu sehen ist eine wirre Anordnung von Fenstern. Da die Fenster sowohl von der Groesse als auch von der Anzahl her flexibel sind, halte ich Layouter hier (und insbesondere die Verweigerung einer direkten Positionsangabe) fuer ungeeignet.

Also da sind wir uns natürlich einig, wie vorher auch schon geschrieben müssen solche Fenster, wenn sie denn frei liegend sein sollen, bewegt und in der Größe verändert werden können. Aber gerade Eve online ist imo vom Inhalt der Fenster komplett in WPF nachzubauen ohne groß eigene Controls zu schreiben. :)

@exploid Du musst WPF natürlich nicht in aller Genauigkeit kennen und es sollte hier auch kein Exkurs Richtung WPF gemacht werden. Es ging nur darum zu zeigen wie WPF es macht und das es da durchaus Elemente und Design Entscheidungen gibt, die in einem Spiel Sinn machen können. Ich bin mittlerweile bspw ein großer Fan von Dependency Properties und damit zusammen hängende Attached Behaviors und wünsche mir sowas für eine Spiele GUI. :)
Layouter die das Positionieren von Elementen in einem Fenster(wenn dein Spiel sowas hat) übernehmen und die strikte Trennung von GUI Design und Code sind ein paar der Sachen die man für eine gute ingame GUI durchaus sich durch den Kopf gehen lassen kann.

Am Ende entscheidet aber nur Kosten/Nutzen :)

[Krishty]

Der WPF eilt ja echt ein Ruf voraus.

Ist das unter Windows 7 immernoch so grottig? Ich habe noch diese Tabelle im Hinterkopf, wenngleich ich sie auch nie richtig verstehen oder glauben konnte … oder geht es garnicht um diese Art von Ressourcen?

[Boogiwoogie]

Hi, nachdem so viel über WPF geredet wurde, dachte ich mal die erste Frage von exploid nochmal aufzutun:

Im Moment wird versucht eine GUI zu entwickeln. Hier meine bisherigen Gedanken:
Da nur rudimentäre Steuerelemente benötigt werden soll auf Callbacks etc. verzichtet werden.

Also ich bin ja recht neu hier im Forum und weiss nicht ob das schon besprochen wurde, aber so wie sich das
für mich anhört würdest du mit einer "immediate mode gui" (imgui) am besten fahren. Das ist eine ziemlich neue
Art (bzw. sehr alte - prä-objektorientiert) eine GUI zu programmieren und eignet sich vor allem für
Realtime Rendering. Man ist sogar auf eine gute Bildwiederholrate angewiesen, sonst verpasst man u.U. ein
paar Mausklicks ;)

Die Prüfung ob sich der Mauszeiger in dem Bereich des Steuerelements befindet soll nicht in jedem
Frame überprüft werden. Dazu soll eine Hierarchie entwickelt werden die diese Abfrage
beschleunigt.

Eine imgui prüft jeden Frame jedes Widget, ob der Mauszeiger drin ist. Hört sich schlimm an, ist es aber nicht.

Die Überlegung ist das jedes Steuerelement aus Steuerelementen konstruiert werden kann.
So ist zum Beispiel ein Listenfeld konstruierbar aus Fenstern, Textfelder und Textanzeigefeldern. Ebenso konstruierbar
wäre ein Kombinationsfeld.

Das ist eines der Philosophien von imguis: Es gibt eigentlich gar keine komplizierten Widgets wie bei einer normalen
GUI-Klassenbibliothek. Sie werden zusammengestellt aus einfachen Teilen. Ich kann hier nicht mal in ein paar Zeilen
erzählen wies genau läuft, aber hier ist der Grundgedanke: Am Anfang des Frames existiert die GUI gar nicht. Nichts davon.
Erst wenn nach einem Button (Slider, Checkbox, Textfeld, was auch immer) gefragt wird, ob er angeklickt wurde,
wird er auf den Bildschirm gemalt. Es werden also keine Objekte erstellt, sie müssen nicht wieder gelöscht werden, man
muss keine Callback-Funktionen registrieren oder irgendwelche Methoden, die auf mehrere Datein verteilt sind schreiben.
Die gesamte GUI-Logik kommt in eine Datei, und das schöne ist, dass sie genauso kompliziert wie du sie haben willst.
Ich hab mal versuchsweise eine programmiert und muss sagen dass ich ziemlich erstaunt war wie easy man mal eben
eine eigene GUI zaubern kann ;)
Hier sind ein paar Links
http://www.mollyrocket.com/forums/viewforum.php?f=10 Forum des "Erfinders" der imguis (Casey Muratori)
http://sol.gfxile.net/imgui/ Eine Seite wo gezeigt wird, wie man ein paar einfache Widgets basteln kann...
http://sol.gfxile.net/imgui/imgui.avi ...und wo man auch ein "Turorial-Video" von Casey downloaden kann.
Das Video hab ich mir angesehen, aber ehrlich gesagt nicht beim ersten Mal verstanden :D

Naja, vielleicht inspiriert es dich ja ein bisschen,
boogi

[Seraph]

@imgui: Ich habe nun die Tutorials ueberflogen, mir die 500 Zeilen Code vom letzten angesehen und die ersten 15min vom Video angesehen. Ich weiss gerade nicht ob ich lachen oder weinen soll. :|

Okay, mal zum positiven seiner Variante. Er hat Recht damit, dass einige States redundant gespeichert werden und sein Weg ein gaaaanz klein wenig performanter sein koennte. Er hat ebenso Recht damit, dass der Code normalerweise dezentralisiert ist. Warum das nun etwas schlechtes ist, verstehe ich hingegen noch nicht. Das waren die positiven Dinge die ich ihm abgewinnen konnte.

Wenn ich mir nun das File und die darin enthaltenen Funktionen ansehe, entdecke ich eine Menge Code-Redundanz. Etwas, dass mir das ach so boese OOP haette ersparen koennen. Und was soll das bitte bei einem komplexen GUI werden. Ende ich dann mit 10.000 oder mehr Zeilen Code und Hunderten mir nichtssagenden Identifiern? Und diese ach so komplizierten Widgets sind nicht wirklich komplizierter als seine Sachen, weil am Ende wurde nur die Position des Algorithmus' (z.B. Drag'n'Drop) verschoben.

Mehr will ich da gar nicht erst drauf eingehen. Tut mir leid, aber imho hat er die Jahrtausendwende verpasst.

[Boogiwoogie]

@imgui: Ich habe nun die Tutorials ueberflogen, mir die 500 Zeilen Code vom letzten angesehen und die ersten 15min vom Video angesehen. Ich weiss gerade nicht ob ich lachen oder weinen soll. :|

Ich schlage einfach mal lachen vor... :D

Okay, mal zum positiven seiner Variante. Er hat Recht damit, dass einige States redundant gespeichert werden und sein Weg ein gaaaanz klein wenig performanter sein koennte.

Naja performanter ist eine imgui glaube ich nicht. Also angenommen du willst eine Desktop-Anwendung schreiben, da ist eine normale GUI-Klassenbibliothek besser, weil sie nicht immer das ganze Fenster neu zeichnet. Eine imgui ist eigtl nur sinnvoll wenn man sowieso eine hohe Framerate hat, also bei Spielen oder zum Visualisieren/Modellieren und so.
Ein gutes Beispiel ist die GUI vom Unity3d Editor: http://forum.unity3d.com/viewtopic.php?t=18127
Eine weiter nennt sich "hybrid" und ist in D geschrieben: http://hybrid.team0xf.com/wiki/Main/Screenshots

Wenn ich mir nun das File und die darin enthaltenen Funktionen ansehe, entdecke ich eine Menge Code-Redundanz. Etwas, dass mir das ach so boese OOP haette ersparen koennen. Und was soll das bitte bei einem komplexen GUI werden. Ende ich dann mit 10.000 oder mehr Zeilen Code und Hunderten mir nichtssagenden Identifiern?

Nein, Code-Redundanz ist ja gerade was 'ne imgui attakiert. Ziel ist es halt, für ein "Widget" möglichst nur eine Zeile zu verbrauchen. Wenn das nicht geht, dann kommt die Behandlungsroutine gleich in den if-Block mit rein. Und die nichtssagenden Identifier, das sind halt die Daten, die dein Programm sowieso hat. Die müssen ja eh in den Quelltext eingebracht werden.

Mehr will ich da gar nicht erst drauf eingehen. Tut mir leid, aber imho hat er die Jahrtausendwende verpasst.

Ja, ist halt geschmackssache. Gibt 'ne Menge "imgui vs. gui class library"-Threads die mehr oder weniger ideologisch geführt werden. Sind aber ganz nett zu lesen, bin halt einer der auch immer mal wieder gerne "orge vs. irrlicht" liest hehe.
Also bei mir wars so dass ich erst ein paar Tage später geschnallt hab wie das überhaupt funktioniert mit den imguis. ;)
boogi

[Seraph]

Ich habe das Prinzip einer imgui schon durchaus verstanden. ;) Was ich mit performanter meinte war lediglich, dass man sich die Objekte sparen kann. Je nachdem wie man es aufzieht, kann es durchaus effizienter werden, aber heutzutage ist das so marginal, dass es eh vernachlaessigbar ist.

Nein, Code-Redundanz ist ja gerade was 'ne imgui attakiert. Ziel ist es halt, für ein "Widget" möglichst nur eine Zeile zu verbrauchen. Wenn das nicht geht, dann kommt die Behandlungsroutine gleich in den if-Block mit rein.

Wenn dem so sein sollte, dann sind seine Beispiele aber sehr schlecht geloest. ;) Vergleich einfach mal den Code in den Funktionen button(), slider() und textfield(). Faellt Dir etwas auf? Genau, vieles davon ist Code, den ich, sofern ich Klassen benutzen wuerde, nur einmal schreiben wuerde. Ich wuerde es ja hier reinkopieren, wenn es nicht soviel waere...

Und die nichtssagenden Identifier, das sind halt die Daten, die dein Programm sowieso hat. Die müssen ja eh in den Quelltext eingebracht werden.

Also ich benutze entweder Objekte oder eindeutig identifizierbare Identifier. Letztere machen sich auch super toll in Scripten und Beschreibungssprachen wie XML. Moegen zwar langsamer als Integer sein, aber da kann man ein wenig optimieren und mit dem geringen Geschwindigkeitsverlust, der in seltenen Faellen zu tragen kommt, kann ich leben.

@Unity3D: Naja, das Scripten des GUIs ist bei Unity3D eher ein funktionaler Ansatz, was durchaus okay ist. Ich koennte mir allerdings vorstellen, dass es intern anders aussieht. Muss allerdings nicht so sein.

@hybrid: Der Ansatz sieht auf jeden Fall interessanter aus, auch wenn ich ihre 'disadvantage'-Liste fuer RMGUIs so nicht mehr bestaetigen kann:

• The GUI pretty much takes over all execution
• It's hard to exchange the widgets in-place while the GUI is running - it's all optimized towards the GUI being static and data changing from time to time.
• RMGUI editors usually produce code, so the app has to be recompiled to try even the simplest of changes.
• When not using a WYSIWYG editor, the programmer has to create tons of code for initialization, callbacks and destruction

1. Ja, stimmt, aber warum ist das schlecht? Wenn ich etwas anders haben moechte, klinke ich mich in das passende Event ein.
2. Wus? Nicht wirklich, oder? :) Spielt mal mit der WPF rum.
3. Ich sag nur Blend, normalerweise null Code, zumindest alles was nicht die App-Daten beruehrt.
4. Wus? Selbst ich mit meiner eigenen GUI lese fast alles aus XMLs ein. Und wenn ich mir die WPF ansehe, leichter geht es kaum.


Ich moechte uebrigens auch nicht sagen, dass IMGUIs keine Daseinsberechtigung haben, nur halte ich sie heutzutage nicht mehr unbedingt fuer den richtigen Ansatz um GUI-Frameworks zu entwickeln.

[Boogiwoogie]

Naja der exploid hat halt den Thread aufgemacht um fragen wie man 'ne einfache GUI hinkriegt, und da wollte ich ihm die imgui-Sache nicht vorenthalten ;)