"eye candy" GUI - wie?

[Gast]

Hallo,

ich habe an die erfahrenden Programmierer hier eine Frage. Ich komm mit dem AWT bzw. Swing Klassen in Java ganz gut klar, allerdings benutze ich bisher immer nur Standard Elemente (radio buttons, textfields etc.).

Wie geht man am besten vor, wenn man optisch ansprechende GUIs programmieren will, sagen wir wie bei Spielen das Start Menü.

Ganz grundsätzlich, wie geht man dabei vor? Sind das einfach Bitmaps mit den die Standardelemente 'geskinnt' werden?

[Noebbie]

Wenns um Swing geht ist das Stichwort "Look and Feel" für dich eventuell relevant.

Such mal nach "Jide" oder so.

[RattuS]

Aufpolierte Controls kannst du überall kaufen, es gibt natürlich auch kostenlose, aber dort ist die Auswahl natürlich etwas geringer. Ansonsten liegt es natürlich auf der Hand selbst das Zeichnen zu übernehmen und den ein oder anderen Effekt hinzuzufügen. Aber denk immer an Usability und User Experience: Anwender, die intensiv mit deiner Anwendung arbeiten, brauchen keine Schatteneffekte oder Farbverläufe, sondern ein sinnvoll aufgebautes Interface. :up:

[Ihm]

Sehe ich ähnlich wie RattuS.
Ich fand es persönlich sehr einfach mit Eclipse und dem in der RCP enthaltenen JFace. Vieles ist aber sicherlich auch schon mit dem SWT ohne viel Erweiterung möglich.

Man möge mich zwar steinigen, aber ich bin immer noch der Meinung, dass Java vom Performance/Aufwand-Verhältnis her nicht die "günstigste" Sprache für aufwendige GUIs ist. :weg:

[Coda]

Ist das eine Java spezifische Frage oder nicht?

[del_4901]

Bei Spielen programmiert man sich was Eigenes, oder wenn man Geld hat kauft man Scaleform, was sehr an Flash angelehnt ist.

[Gast]

Vielen Dank für die Antworten bisher.

Ist das eine Java spezifische Frage oder nicht?

Nicht direkt, ich kenn mich mit Java nur am besten aus. Ausser Standard GUIs (also eingabemasken etc) habe ich bisher allerdings noch nie was gemacht, bin aber sehr interessiert dran. Mir fehl einfach etwas die Vorstellung wie man dabei generell vorgeht wenn man sowas entwickeln möchte. Für Standard GUIs habe ich halt gelernt wie man swing und awt benutzt, bei individuelleren "eye candy" GUIs habe ich aber keine Ahnung, "bastelt" man sich da seine "eigene" SWING Klassen zusammen? Oder geht man ganz anders vor? über eine paint Methode oder sowas? Ihr merkt ich habe wirklich keine Vorstellung. :)

Von dem was ich mit eye candy GUI meine geht Scaleform schon ganz in die richtige Richtung btw.

[Coda]

Ich wollte auch auf Scaleform raus, deshalb fragte ich nach Java ;)

[SaschaW]

Wenn man was richtig schönes will, bastelt man am besten selbst was. Für mein aktuelles Spiel hab ich mir in OpenGL eine ziemlich umfangreiche GUI geschrieben, die leicht an Delphis VCL angelehnt ist, ein Windows-ähnliches Nachrichtenhandling anbietet (aber vereinfacht) und neben grundlegenden GUI-Elementen (Buttons, Listboxen, Panels, Memos) auch erweiterte Elemente anbietet (Skinned Control, Adanced Image mit Spiegelung etc.), schliesslich soll die UI in einem Spiel ja auch wie eine Spiel-UI wirken, und nicht wie eine die aus Word o.ä. kommen könnte.

Da die GUI auf OpenGL basiert kann man natürlich auch alle Vorteile dieser API nutzen, sprich automatische Sortierung dank Tiefenpuffer, 3D-Elemente auf 2D, Alphatest, Transparenz, und v.a. halt die Hardwarebeschleunigung, sprich man kann extrem viele Elemente sehr schnell rendern. Ist zwar relativ aufwendig (die GUI-Unit selbst hat ~8000 Zeilen, aber da stecken Jahre an Arbeit drin, und viel spart man sich halt durch Vererbung vom Grund-GUI-Objekt und einiges steckt noch in weitere Units für z.B. den Texturenmanager, das VFS, Mathe, etc., aber lohnt sich definitiv, da es viel zur Atmosphäre im Spiel beiträgt, zumal die UI auch noch animiert ist.

Im Spiel sieht dass dann so aus :
http://www.saschawillems.de/misc/pjw_p2_gui0.jpg

http://www.saschawillems.de/misc/pjw_p2_gui1.jpg

Dazu kommt dann natürlich noch ein Editor um die GUI zu bearbeiten, den müsste man dann auch selbst erstellen. Das kann man aber ja quasi parallel machen, und dann auch diesen Editor zum Prototypisieren neuer Elemente nutzen. Speichern tu ich meine GUIs übrigens in XML, so kann man leicht erweitern bzw. anpassen wenn man z.B. einem alten GUI-Element neue Attribute verpassen will.

http://www.saschawillems.de/misc/pjw_p2_guiedit.jpg


Und da man die UI im Normalfall auch portable macht kann man diese ja auch in anderen Projekten nutzen, sprich man macht sich die Arbeit "nur" einmal.

[RattuS]

Mir fehl einfach etwas die Vorstellung wie man dabei generell vorgeht wenn man sowas entwickeln möchte. Für Standard GUIs habe ich halt gelernt wie man swing und awt benutzt, bei individuelleren "eye candy" GUIs habe ich aber keine Ahnung, "bastelt" man sich da seine "eigene" SWING Klassen zusammen? Oder geht man ganz anders vor? über eine paint Methode oder sowas? Ihr merkt ich habe wirklich keine Vorstellung. :)
Beim "Do-It-Yourself" gibt es im Prinzip zwei Möglichkeiten: von bereits bestehenden Controls erben und den/die Paint-Event/s überschreiben/erweitern oder komplett eigene Controls schreiben. Letztere sind natürlich aufwendiger (du musst das Zeichnen vollständig selbst übernehmen und eigene Events implementieren), aber dafür genau auf deine Bedürfnisse anpassbar.



http://www.saschawillems.de/misc/pjw_p2_gui0.jpg
http://www.saschawillems.de/misc/pjw_p2_gui1.jpg
http://www.saschawillems.de/misc/pjw_p2_guiedit.jpg

Sieht übrigens toll aus, Sascha. :up:

[RMC]

Bei Spielen programmiert man sich was Eigenes, oder wenn man Geld hat kauft man Scaleform, was sehr an Flash angelehnt ist.

Scaleform ist nicht nur angelehnt, es basiert auf Flash ;)

[Gast]

SaschaW, genau dass was du machst meine ich, danke für Deine Ausführung!

Ist vielleicht eine etwas blöde Frage, aber gibt es ein standard Buch/Tipp oder sowas für dieses Thema? Ich würde wirklich gerne was in der Richtung lernen, weiß nur überhaupt nicht wo ich Anfangen soll... ich würde das gerne möglichst zeit-effektiv lernen, vielleicht hat da ja jemand ein Tipp.

Wie habt ihr das gelernt?

Freut mich wirklich das ich hier ein paar Antworten finde, Foren sind was tolles. :)

[SaschaW]

In Sachen Programmierung, 3D, etc. bin ich eher Autodidakt, also Bühcer o.ä. hab ich keine gelesen, da kann ich dir also leider nicht weiterhelfen.

Allerdings hab ich vor etwas längerer Zeit mal ein Tutorial zum Thema 2D und OpenGL verfasst, und auch wenn ich es heute teiweise anders machen würde (Shader und so halt) ist evtl. ein guter Startpunkt : http://wiki.delphigl.com/index.php/Tutorial_2D

Überhaupt hat unser (Delphi) OpenGL-Wiki sehr viele gute Infos und Tutorials zum Thema OpenGL. Und Da OpenGL ja an sich sprachunabhängig ist und sich die meisten Hochsprachen syntatkisch ähneln sollte es kein Problem sein auch als Java-Nutzer oder C'ler Infos daraus zu extrahieren, zumal wir in der Community und im Wiki auch genug Leute haben die da teilweise slber C++ / Jave nutzen.

[Gast]

Allerdings hab ich vor etwas längerer Zeit mal ein Tutorial zum Thema 2D und OpenGL verfasst, und auch wenn ich es heute teiweise anders machen würde (Shader und so halt) ist evtl. ein guter Startpunkt : http://wiki.delphigl.com/index.php/Tutorial_2D

Das Tutorial stammt von dir? Vielen Dank! Es hat mir damals den Anreiz gegeben, mit grafischer Programmierung anzufangen. Bin zwar danach schnell zu C++ un fertigen Engines gewechselt, aber dieses Tutorial blieb in Erinnerung :-)

[Mr.Freemind]

In Sachen Programmierung, 3D, etc. bin ich eher Autodidakt, also Bühcer o.ä. hab ich keine gelesen, da kann ich dir also leider nicht weiterhelfen.

Allerdings hab ich vor etwas längerer Zeit mal ein Tutorial zum Thema 2D und OpenGL verfasst, und auch wenn ich es heute teiweise anders machen würde (Shader und so halt) ist evtl. ein guter Startpunkt : http://wiki.delphigl.com/index.php/Tutorial_2D

Überhaupt hat unser (Delphi) OpenGL-Wiki sehr viele gute Infos und Tutorials zum Thema OpenGL. Und Da OpenGL ja an sich sprachunabhängig ist und sich die meisten Hochsprachen syntatkisch ähneln sollte es kein Problem sein auch als Java-Nutzer oder C'ler Infos daraus zu extrahieren, zumal wir in der Community und im Wiki auch genug Leute haben die da teilweise slber C++ / Jave nutzen.


Das Tutorial ist von dir? Respekt! Hat mir damals sehr geholfen Graphische Datenverarbeitung im Studium zu bestehen! Danke nochmals dafür! :umassa:

[SaschaW]

Freut mich zu hören, positives (und konstruktives) Feedback ist immer gut für die Motivation.

Dabei fällt mir allerdings ein dass ich das Tutorial (und meine anderen auch) evtl. mal um einen OpenGL 3.0-Zusatz erweitern könnte, da wird ja vieles anders gemacht als unter 2.0, und so mancher Neueinsteiger wäre besser beraten direkt damit anzufangen. Mal schaun wann ich dazu Zeit hab.

[Gast]

ändert sich zu opengl 4.1 noch mehr? ich wollte mich nämlich schon länger in opengl einarbeiten, finde aber nie unterlagen (bücher, webtuts) zur version 4 und ich will mich nicht mit einer veralteten materie quälen

[SaschaW]

Nicht sonderlich. Der größte Unterschied besteht halt beim Wechseln von OpenGL 1.x/2.x auf OpenGL 3.0 mit einem vorwärtskompatiblem Renderkontext, da man dort nicht mehr auf die alten Funktionen zurückgreifen kann. Mit OpenGL 3.1 fällt dann halt auch der abwärtskompatible Kontext weg.

An sich eine gute Idee um die API endlich mal zu entrümpeln, wer allerdings Projekte oder Spiele entwickelt die bei einer möglichst großen Zielgruppe laufen sollen bleibt vorerst besser bei OpenGL 2.x. In meinem aktuellen Spiel hab ich so ja schon zwei Renderpfade drin, einmal für Karten die Shader können (OpenGL 2.x) und einmal für Karten die das nicht können (OpenGL 1.x), und jetzt noch nen dritten Renderpfade der OpenGL 3.x nutzt wäre extrem viel Arbeit, zumal da ja dann der immediate Mode (glVertex*) komplett wegfällt und ich dann z.B. auch meine komplette OpenGL-GUI anpassen müsste.

[whtjimbo]

@SaschaW

Was würdest Du vorschlagen beim Rendern von Textbereichen? "Flexibler" Ansatz mit Quad per Zeichen ist schön bei kurzen bzw. selten verwendeten Texten, aber durch die hohe Anzahl von draw calls nicht unbedingt performant. Überlange Buffer mit glDrawElements zeichnen, wobei Anzahl der Elemente dynamisch festgelegt wird, ist eine weitere Möglichkeit bei statischen Texten, jedoch etwas schlecht wegen VBO/Array update bei dynamischen Texten. Was wäre Dein Ansatz?

[Grey]

Wenn man was richtig schönes will, bastelt man am besten selbst was. Für mein aktuelles Spiel hab ich mir in OpenGL eine ziemlich umfangreiche GUI geschrieben, die leicht an Delphis VCL angelehnt ist, ein Windows-ähnliches Nachrichtenhandling anbietet (aber vereinfacht) und neben grundlegenden GUI-Elementen (Buttons, Listboxen, Panels, Memos) auch erweiterte Elemente anbietet (Skinned Control, Adanced Image mit Spiegelung etc.), schliesslich soll die UI in einem Spiel ja auch wie eine Spiel-UI wirken, und nicht wie eine die aus Word o.ä. kommen könnte.

Da die GUI auf OpenGL basiert kann man natürlich auch alle Vorteile dieser API nutzen, sprich automatische Sortierung dank Tiefenpuffer, 3D-Elemente auf 2D, Alphatest, Transparenz, und v.a. halt die Hardwarebeschleunigung, sprich man kann extrem viele Elemente sehr schnell rendern. Ist zwar relativ aufwendig (die GUI-Unit selbst hat ~8000 Zeilen, aber da stecken Jahre an Arbeit drin, und viel spart man sich halt durch Vererbung vom Grund-GUI-Objekt und einiges steckt noch in weitere Units für z.B. den Texturenmanager, das VFS, Mathe, etc., aber lohnt sich definitiv, da es viel zur Atmosphäre im Spiel beiträgt, zumal die UI auch noch animiert ist.

Im Spiel sieht dass dann so aus :
http://www.saschawillems.de/misc/pjw_p2_gui0.jpg

http://www.saschawillems.de/misc/pjw_p2_gui1.jpg

Dazu kommt dann natürlich noch ein Editor um die GUI zu bearbeiten, den müsste man dann auch selbst erstellen. Das kann man aber ja quasi parallel machen, und dann auch diesen Editor zum Prototypisieren neuer Elemente nutzen. Speichern tu ich meine GUIs übrigens in XML, so kann man leicht erweitern bzw. anpassen wenn man z.B. einem alten GUI-Element neue Attribute verpassen will.

http://www.saschawillems.de/misc/pjw_p2_guiedit.jpg


Und da man die UI im Normalfall auch portable macht kann man diese ja auch in anderen Projekten nutzen, sprich man macht sich die Arbeit "nur" einmal.

OT aber finde ich schick. Hab gerade mal dein Explosion-Tool geladen, mal sehen was sich damit alles so anstellen lässt =) So muss 3DCenter sein.

[SaschaW]

@SaschaW

Was würdest Du vorschlagen beim Rendern von Textbereichen? "Flexibler" Ansatz mit Quad per Zeichen ist schön bei kurzen bzw. selten verwendeten Texten, aber durch die hohe Anzahl von draw calls nicht unbedingt performant. Überlange Buffer mit glDrawElements zeichnen, wobei Anzahl der Elemente dynamisch festgelegt wird, ist eine weitere Möglichkeit bei statischen Texten, jedoch etwas schlecht wegen VBO/Array update bei dynamischen Texten. Was wäre Dein Ansatz?

Ich rendere ganz normale Texturenfonts, bei denen die Buchstaben in aufeinanderfolgenden Displaylisten (im Bezug auf die IDs) liegen, so kann man dann komplette Strings mit einem einzigen glCallLists (und dem Text als PChar, der dann ja direkt die Listen-IDs beinhaltet) rendern. Viel schneller geht es kaum, zumal ich ja ein rundenbasiertes Strategiespiel entwickle. Da bin ich mit ~100 fps auf meinem recht "alten" Rechner in 1920x1080 mit 4xAA doch mehr als zufrieden :wink:

Klar gibts sicherlich Methoden um Texte noch performanter zu rendern, z.B. in dem diese in Texturen rendert, so eine Lib hat einer unserere Communitymember (nicht hier, sondern in der Delphi OpenGL Community) erstellt, aber hier gibts dann halt andere Probleme wie VRAM-Verbrauch, Texturaktualisierung (gut, FBOs bieten sich hier natürlich an), etc. Aber für meine Zwecke reicht diese recht simple und doch performante Methode.

[whtjimbo]

Danke Dir!