spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Unterstützen bzw. die Linux-Seite pflegen würde ich auch.

Bin seit 2 jahren bei MyGUI dabei und kann es sehr empfehlen;
+ sehr fleissige Progger
+ guter Support im Ogre3dAddonForum
+ Widget orientiert
+ flexibles Layout, objektorientiert via xml
+ sehr schnell
+ Delegates für GUI Feedback
+ alle Widgets die man sich wünschen kann; auch integrierter Flashplayer und WebBrowser
+ OS, mit LGPL/MIT-Lizenz
+ gute Tools zur GUI-Erstellung

empfehle die immer letzte SVN-Version zu ziehen, da die Packages meist veraltet sind.

Das Rad schon wieder neu zu erfinden, halte ich für idiotisch, vorallem da es GUIs wie Sand am Meer gibt. Aber wenn man Zeit hat :lol:

Gruss
Markus

Jetzt, da MyGUI endlich von Ogre weggekommen ist und man tatsächlich eigene Renderer anklemmen kann, ist es tatsächlich einen zweiten Blick wert. Die Renderer-Anbindung scheint aber tief im Code eingegraben zu sein, so dass ich die Zeit, den Scheiß dort rauszuholen, dann doch lieber in anderen Code investiere. Animationen sind wohl auch noch nicht vorgesehen.

Mein aktueller Gedanke wäre, die GUI-Elemente nur den Zustand und die Logik ausführen zu lassen und die Anzeige via Double Dispatch an eine Render-Klasse auszulagern. Damit hat man zumindest beliebige Freiheiten, wie es aussehen soll und welche Technologie benutzt wird. Die GUI soll sich auch nur von abstrakten Eingabeereignissen ernähren, sie soll explizit KEINE InputManager oder sowas mitbringen. Das alles schön in eine Klasse verpackt und die Singletons von MyGUI vermieden - das könnte eine kleine Lib werden, die tatsächlich so einfach von Projekt zu Projekt übertragbar wäre.

Alles per Skript... nuja, ich kann die Beweggründe nachvollziehen. Schnelle Iterationen sind das A und O der Software-Entwicklung. Allerdings muss man sich dann ja auch permanent neue Funktionen anmelden, um sie im Skript benutzen zu können, und je nach Skriptsprache schlimmstenfalls auch noch Proxy-Funktionen schreiben. Gefällt mir nicht, kann aber jeder gern für sich entscheiden.

na da mach ich doch glatt noch ein bissl mehr Werbung
wegen anis, oder meinst du noch bessere/andere? http://www.youtube.com/user/themynameka#p/a/u/0/A37iIil3T68

Gruss
Markus

Naja. Die Kommunikation liefe nur über die 4 genannten Schnittstellen (rendern lassen, eingehende events,ausgehende events, anfragen von der GUI). Natürlich müsste man die Anfragen der GUI dann in der Programmiersprach der Wahl entsprechend weiterverarbeiten. Dazu müsste man aber nicht die Anbindung erneut kompilieren, sondern nur die entsprechende "exponierte" Funktion in der gewählten Programmiersprache erweitern. Weißt was ich meine?

Zitat von »qwertzui11«

Das Rad schon wieder neu zu erfinden, halte ich für idiotisch, vorallem da es GUIs wie Sand am Meer gibt. Aber wenn man Zeit hat :lol:

Gruss
Markus

Es geht auch nicht immer darum das Rad neu zu erfinden. Man möchte das Rad noch runder, reibungsärmer, leichter und stabiler machen. Also optimieren. Und dafür machts manchmal doch Sinn nochmal von unten anzufangen.

Die GUI flexibel zu halten finde ich enorm wichtig, sprich, dass es zur Laufzeit angepasst werden kann. Und Plattform unabhängig sollte es auch sein.

Awesomium soll sehr gut sein. Bei Overgrowth wird es eingesetzt (und der eine Screenshot unten auf der Seite scheint auch von Overgrowth zu sein).

Das Problem bei Awesomium dürfte wohl für viele sein, dass die Source-Code Lizenz ein bisschen extrem teuer ist . Ansonsten scheint es echt dufte zu sein. GUIs mit HTML/CSS/JS zu entwerfen ist eine super Idee. Werd mir das mal bei Gelegenheit anschauen

Was mich am meisten stört sind die unflexiblen Gui-Layoutdateien. Ich habe mich extrem an die WPF-Layoutings gewöhnt, die sehr flexible Gestaltungen ermöglichen. Das wäre das Key-Feature, deine Library zu verwenden. Nichts nervt bei den ganzen GUI-Libs mehr als diese bescheuerte Pixelschubserei.... Es spricht ja nichts dagegen, aus Performancegründen zu sagen, dass GUI-Gruppen static sind. D.h. diese Gruppen zwar dynamisch mit Layoutern gestaltet, aber nach der erstem Berechnung die Koordinaten gespeichert und danach gerendert werden.