GUI - einige Fragen

[Seraph]

Irgendwie weiss ich nun selbst nich mal, ob ich das richtige Forum erwischt habe. *g*

Wie auch immer, ich habe einige Fragen zu GUIs und einige davon sind auch recht simpel und ebenso wahrscheinlich simpel zu beantworten. Bei diesen moechte ich nur sichergehen, dass ich keine bessere Moeglichkeit aussen vor gelassen habe. Andere Fragen hingegen sind (zumindest fuer mich) etwas schwieriger zu beantworten, wobei ich auch hier hoffe, Antworten aus der Community zu erhalten. Vielleicht sollte ich noch erwaehnen, dass dieses nur die ersten Fragen sind und wahrscheinlich noch weitere folgen werden. Nur ist es gerade spaet.

Also folgendes, nehmen wir einfach mal an wir haben ein Spiel mit einem einheitlichen Oberflaechendesign, sprich mehrere "Fenster" haben den gleichen Rahmen. Dazu kommt, dass man die Groesse des Fensters veraendern kann. Das Problem welches sich nun durch die Groessenaenderung ergibt ist, dass wenn man fuer diesen Rahmen und den Hintergrund nur ein Quad nutzen wuerde, die dargestellte Textur verzerrt werden wuerde. Die naheliegendste Loesung waere also fuer die Raender und die Ecken eigene Polygone zu benutzen. Dieses erhoeht natuerlich den Renderaufwand. Gibt es vielleicht eine bessere Loesung?

Meine zweite Frage bezieht sich auf das "neurendern". Sprich macht es Sinn die GUI in eine grosse Textur zu rendern und nur Teile von dieser zu aktualisieren und anschliessend diese Textur ueber das Spiel zu rendern oder ist es eher unsinnig und man sollte einfach direkt alles rendern was benoetigt wird? Oder direkt in den Backbuffer und nur das was geaendert wurde? Dazu stellt sich mir auch gleich noch die Frage, welches der beste Weg waere nur Teile des Rendertargets neuzuzeichnen?

Und hat jemand irgendeine Idee wie das bei World of Warcraft genau funktioniert? Ich finde den minimalen Performanceverlust schon beeindruckend, selbst wenn da noch soviele Aenderungen, Texte, etc. gezeichnet werden.

[DSG]

Hallo

Zu der ersten Frage: Dein Ansatz mit den Ecken und Kanten ist richtig und es wird auch in den meisten Gui-Oberflächen so gemacht. Über die Performance musst du dir dabei keine Sorgen machen. Ein Fenster hat in der Regel 4 Ecken und 4 Kanten, die Ecken werden normal gerendert und bei den Kanten muss die Textur in U- bzw. V-Richtung wiederholt werden. Natürlich müssen die Grafiken zusammenpassen damit das Fenster gut aussieht.

Somit brauchst du 8 Quads pro Fenster. In einem GUI, speziell bei Games, hat man sicher nie mehr als 5-10 Fenster gleichzeitig offen (natürlich je nach Art des des Games). Das GUI kannst du so mit modernen API’s wie OpenGL und DX problemlos jeden Frame neu zeichnen, dies wird die Performance kaum beeinflussen.

Somit wäre auch die zweite Frage beantwortet. Ich würde dir nicht den Kopf darüber zerbrechen, wie du GUI Teile in Texturen cachen könntest. Einfach alles Sichtbare in der richtigen Reihenfolge zeichnen. Moderne Games wie Wow und Co. Machen dies auch nicht anders.

Wenn dein GUI komplexer wird, macht es Sinn das GUI in einer logischen Struktur abzubilden. Am besten eignet sich eine Baustruktur, so kannst du ganze GUI Elemente Gruppieren und dden Visibility-Check auf der Gruppe ausführen, statt auf jeder GUI Komponente. Swing, GWT & Co. Machen das genau so.

[dowhilefor]

Somit brauchst du 8 Quads pro Fenster.

Ich hätte ja gesagt 9 ;) 4 für die Ecken, 4 für die Ränder und 1 für den Eigentlichen Hintergrund, quasi der Client bereich.

[Seraph]

Hey, danke fuer die Antwort. :)

Gut, also brauche ich 8 respektive 9 Quads fuer ein Fenster.

Das GUI welches ich entwickelt habe ist schon ziemlich komplex und zumindest nach aussen hin an .net angelehnt. Urspruenglich fuer OpenGL geschrieben, konvertiere ich es gerade nach XNA.

Aufgrund der logischen Struktur, welche Du erwaehnst, kam ueberhaupt der Gedanke, dass ich im Grunde genommen nur bestimmte Teile neu rendern muss und da ich genau weiss welche, waere es halt auch theoretisch zumindest kein Problem. Dummerweise bin ich kein wirklicher Grafikentwickler und somit fehlt mir in dieser Hinsicht das Wissen.

Aber hier mal ein alter Screenshot (bestimmt schon ueber ein Jahr alt):

ein paar Controls innerhalb eines Fensters

Ein weiteres "Problem" waeren evtl. noch laengere Texte innerhalb von scrollbaren Fenstern. Das Problem dabei ist, dass ich immer den dargestellten Text berechnet habe, aber was ist, wenn ich nur die Haelfte einer Zeile sehen moechte? Rendere ich dann den Rahmen drueber und was ist, wenn ich keinen Rahmen habe? Ich hoffe man versteht das Problem. Man kann sich da z.B. Questtexte in Spielen vorstellen oder auch wie hier (ist auch schoen ueber ein Jahr alt) einen Ingame-Script-Editor, bei welchem man uebrigens auch das Problem mit dem gestretchten Rahmen gut erkennen kann:

ein Ingame-Editor zum erstellen von Skripten

Nachtrag: Nico hat ja auch schon festgestellt, dass man im Grunde genommen 9 Quads benoetigt. :)

[B.G.Michi]

hab noch kein gui, aber eventuell könnte man da mit dem z-buffer arbeiten, sozusagen den text wirklich hinter den ramen rendern
wenn du keinen ramen hast renderst hald nen unsichtbares "clientrect" in den depthbuffer, oder so ähnlich

[dowhilefor]

Scissor Rect wäre eine Möglichkeit ist aber relativ performance lastig oder du renderst den Text in eine Textur und hast damit automatisch Clipping.

[Seraph]

Scissor Rect wäre eine Möglichkeit ist aber relativ performance lastig oder du renderst den Text in eine Textur und hast damit automatisch Clipping.

Was heisst performancelastig? Ein Vorteil durch die Textur waere dann ja, dass ich den Text nur neuzeichen muss, wenn er sich aendert oder verschoben wird.

Ich würde dir nicht den Kopf darüber zerbrechen, wie du GUI Teile in Texturen cachen könntest. Einfach alles Sichtbare in der richtigen Reihenfolge zeichnen. Moderne Games wie Wow und Co. Machen dies auch nicht anders.

Ich bin da ein wenig skeptisch, allerdings wuesste ich auch nicht wie sie es machen, da es doch recht viele dynamische Teile enthaelt. Aber wenn man sich die zig Grafiken und Texte ansieht, die teilweise auf dem Bildschirm dargestellt werden koennen. Ich kann mir irgendwie nicht vorstellen, dass diese wirklich nur einfach so gerendert werden.

[DSG]

Ich kann mir irgendwie nicht vorstellen, dass diese wirklich nur einfach so gerendert werden.

Es gibt natürlich verschiedene Ansätze wie man eine GUI Zeichnen kann. Nach meiner Erfahrung werden die Sichtbaren GUI Teile jeden Frame neu gerendert. Ich hatte diesbezüglich auch noch die Performanceprobleme, dies lag immer an der 3D Engine ;-)

Mein Tipp ist ein einfacher GUI Renderer zu implementieren. Wenn dieser gut läuft und das Spiel allgemein spielbar ist, gibt es auch keinen Grund das GUI anzupassen. Doch falls das GUI komplexer wird und die FPS desswegen in die Knie geht, dann wäre eine GUI Optimierung sicher denkbar, ich glaube aber kaum das es soweit kommen wird.

[donelik]

Hallo!

Zwar keine echte Hilfe aber ein Hinweis:

http://www.cegui.org.uk/wiki/index.php/Main_Page

bei der CEGUI ist wirklich alles von außen konfigurierbar.

- Imagesets
- XML Layouts
- schemes
- looknfeels

vg
donelik