Hi,

ich hasse mich mittlerweile dafür das ich das Flipbook mit Delphi entwickelt habe... und zwar einfach und allein aus dem grund der Platformunabhängigkeit..

Jetzt möchte ich gern das Flipbook nach C++ portieren, was zwar einen ziemlichen aufwand bedeutet, aber dennoch relativ problemlos klappen sollte, bis auf die UI... gut, das MainForm ist komplett in OpenGL geschrieben = das würde 1 zu 1 so gehen, nur alle unter fenster benutzen halt die VCL..

Ich bin im moment daran eine komplett OpenGL basierte UI zu schreiben, was auch wunderbar klappt, nur frage ich mich wie sinnvoll es ist... für spiele, klar.. aber für normale programme..?

Daher ein paar fragen dazu:

1) Hat es irgendwelche negativen aspekte die ui komplett über OpenGL zu machen in sachen geschwindigkeit etc? (Es kann ja sein das 5 fenster gleichzeitig offen sind = viele context wechsel.. auch wenn natürlich immer nur dann gezeichnet wird, wenn es notwendig ist)

2) Mein hauptproblem sind die text felder.. jedes system hat ja z.B. eigene funktionen in seinen textfeldern.. z.B. allein das contextmenü mit seinen verschiedenen einträgen.. mein eigenes edit feld kann zwar auch Copy/Paste etc, aber halt ka.. es ist dann einfach anders vom handling her als die normalen System-EditFelder.

Gibt es alternativ dazu evtl irgendeine tolle möglichkeit individuelle UIs (= mit eigenem design) platform unabhängig zu machen? Irgendwelche libs oder so?

Und als letzte frage.. eine andere alternative wäre noch C#, aber wie schaut es da mittlerweile mit OpenGL aus, und ist das wirklich so gut platformunabhängig wie C++? Auch vom speed her etc?

Aya~

Wieso stellst du nicht auf SDL um? Wenn schon alles fertig ist, würde ich den Krempel nicht nochmal neu schreiben wollen. Mit SDL bist du plattformunabhängig.

Wenn du's komplett neu schreiben willst, würde ich Java empfehlen. Wobei das meine persönliche Meinung ist. Für mich gäbe es keine Begründung in meiner Freizeit ein Programm mit C++ zu schreiben. Der innere Hass und Zorn auf die SPrache würde mir jeden Spass an der Arbeit nehmen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

mit SDL bin ich durch delphi aber doch immernoch an Windows gebunden... meine freepascal erfahrungen waren da jetzt auch nicht soo berauschend leider.

Wäre denn der umstieg auf SDL "einfach"?

SDL unterstützt bisher nur ein Fenster, das dürfte bei dir dann zu Problemen führen (es sei denn, du lädst die SDL.dll mehrfach dynamisch... Ist aber die Frage, ob das so gut ist).

FreePascal: Wann hast du's ausprobiert? Vorallem Lazarus hat sich mit den letzten beiden Versionen stark verbessert, du solltest nochmal reinschauen. FreePascal bietet dir ja auch die Möglichkeit, VCL-artig plattformunabhängige UIs zu bauen. Du kannst ihm dann halt sagen, was für ein Widgetset er verwenden soll (win32 für Windows beispielsweise und dann QT für Linux oder je nach dem, wie du's magst).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also ich habe SDL noch nicht gemacht, aber soweit ich weiß, ist das plattformunabhängig. Läuft also nicht nur unter Windows.




Was Performacne angeht: kA, eigene GUI hab ich mit OGL noch nicht gemacht.

Was deine Frage zu Libs angeht: wxWidgets ist ähnlich MFC, OpenSource und für mehrere Plattformen erhältlich. Es hat auch den Vorteil, dass es auf native Steuerlemente in den BS aufsetzt.
Dann fällt mir noch QT ein. Ansonsten schau dir mal das an: http://www.kharchi.eu/wiki/doku.php?id=cpp:gui:libs

Ach ja, und Java würde ich wiederrum abraten *fg*. C++ ist schon eine sehr gute Wahl

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

@Palleon: Ja stimmt C++ ist eine sehr gute Wahl. Aber Pascal-Menschen tun sich mit C++ eben schwer.

Was die Performance einer OGL-GUI angeht: sie ist so performant, wie es in in OGL auf dem jeweiligen Prozessor mit der jeweiligen Grafikkarte eben geht, nicht mehr, aber auch nicht weniger.

Aber was Lazarus betrifft, werde ich mit der Zeit immer vorsichtiger. Vor kurzem hat sich herausgestellt, dass tief in Lazarus proprietäre Strukturen in ein anderes Betriebssystem transportiert wurden. Könnte bei einem kommerziellen Programm rechtliche Folgen nach sich ziehen.
Traude

Qt ist eine tolle Sache, wenn du damit leben kannst, dass du dann quasi c++ mit Erweiterungen schreibst (Qt beinhaltet noch eine art Compiler, der die ganzen Klassen einmal mit Metadaten versieht) und dass du entweder OpenSource sein musst oder eine recht hohe Lizenzgebühr zahlst.

Ach ja , hab noch etwas vergessen: mit einer OpenGL GUI kriegst Du ein durchsichtiges Fenster über dem Desktop nur sehr mühsam und langsam hin. Sonst habe ich bisher noch keine Einschränkungen bemerkt.

Kontextwechsel: meine Fenster teilen sich einen Kontext.

Hehe, woher kommt mir die ganze Thematik nur so bekannt vor *grübel* .
xD Ich hatte mit Karmarama genau die gleiche Problemstellung, mit ausnahme von vcl unterbau, denn der war bei mir schon cross, dank eigenes Fenstersystem.

Ob du wirklich auf C++ umsteigen solltest, sei erstmal dahingestellt aber zum Thema cross und Objektpascal erstmal folgendes.
Du kannst dein Code beibehalten, müssen ledeglich 1-2 stellen angepasst werden, wenn du mit FPC compilierst.
Mit dem VCL Unterbau ist es Aufwändiger, da musst du ja XLib und GDI in eigene Fensterklassen verpacken.
siehe TKar_WindowClass(abstrakte basisklasse)
TKar_GDIWindow(GDI Implementierung)
TKar_XWindow(XLib Implementierung)
Wrappt auf TKar_Window
Wenn man OpenGL zum zeichnen nimmt, dann merkt man von der umstellung so ziemlich 0.
Schlimm wird es nur, wenn man Bibliotheken von Windows verwendet und externe Bibliotheken, die nicht unter anderen Platformen verfügbar sind.
OpenGL zum zeichnen der GUI ist sehr zu empfehlen, da dein Programm eh auf OpenGL arbeitet, kannst du mit einer OpenGL basierten GUI viel CPU Zeit einsparen(für hintergrundberechnung verwenden) und der Grafikkarte macht das wenig aus.
Zum zeichnen der Schrift kann ich nur empfehlen freetype zu nehmen, da die OS spezifischen Schrift API ziemlich unterschiedlich sind und quasi nicht das gleiche Bild abliefern(selbst nach eigenen justierungen).
Freetype ist platformunabhänig, qualitativ das beste was gibt, frei nutzbar und XLib verwendet es unter der eigenen API versteckt.

Hier lag der Grund, wieso ich dann letztendlich auf C++ umgestiegen bin, das ständige Leid mit veralteten Headern oder teilweise gibt es garkeine.

C# kannst gleich streichen, nur weil es einen c# compiler/interpreter für linux gibt, ist es ned c# sondern eine eigene implementierung des c# gedankens.
Kompatibel ist die Sache mit MS C# auch ned (nur einseitig).

Wenn du wirklich auf C++ umsteigen willst, dann wird es beim Port nicht nur codeportierung geben, sondern auch Zeitaufwändige neuprogrammierung.
Ich wollte auch nur mein Code portieren aber C++ bietet möglichkeiten und umgekehrt, die dann andere Lösungsansätze viel schmackhafter machen und so wird der Code "kurzerhand" noch angepasst.
Nun hab ich auch zugriff auf viel mehr Bibliotheken und so hat sich da auch einiges geändert.
Statt einer Komplexen OpenGL UI benutze ich nun wxWidget und für das Game selber ein einfaches GUI.

Wo wir dann auch bei Cross Bibliotheken wären.
Ich kann in diesem Fall nur wxWidget empfehlen.
GTK ist prozedural, veraltet und schwer zu handhaben.
QT ist für kleine/große hobbyprojekte gut aber muss immer kostenlos bleiben, da sonnst ziemlich deftige Lizenzgebühren zu zahlen sind. Sonnst ist es eine potente Lösung.
wxWidget ist aktuell der Stern am Himmel der UI's, es ist aktuell das umfangreicheste(enthält ports für viele sprachen,scriptsprachen, hat unmengen an Komponenten(seit neusten Borland's VCL)), leicht zu benutzende(komplett Objekt Orientiert und erinnert an VCL mit OnEvents) und völlig freie(egal ob komerz oder nicht, man muss nie Code rausgeben und kann tun was man damit will) Bibliothek.
Leider ist es auch nicht klein ^^, da soviel zeug dabei ist hat mein wxWidget Ordner 1.3GB größe(code für alle Platformen,600MB an selber compilierten obj files für unicode und unicode debug, sowie noch 200mb an datenbankdatein von visual studio und ein paar compilierten samples).
Mangelwahre sind hier nur gute IDE aber wxFormBuilder finde ich sehr potent, da es neben xrc files auch cpp/h files generiert.
Ausserdem kann man Plugins verwenden und es bietet eine CustomWidget Komponenente, mit der man nicht bekannte Widgets mit in den Builder verwenden kann.

Ich selber nutzte wxWidget erst seit wenigen Tagen/Wochen und bin völlig von begeistert.
Man kann wirklich sehr leicht eigene Sachen integrieren und ist ziemlich flexibel.
Drauf gestossen bin ich auch nur, weil ein Kumpel wxWidget in der Firma verwendet, für die Game Engine Tools.
Epic Games nutzt wxWidget z.B. für den neuen Unreal Editor 4, in Unreal Engine 3.
Wenn ich meiner Quelle trauen kann, dann wird es auch für den Unterbau von UE3 verwendet.
Was ja wohl sehr für die Codequalität von wxWidget spricht.

Ich hatte bereits an Tag 3 mit wxWidget, mein Fenster mit Buttons und ersten Dialog, sowie OpenGL Context und ein interface zu meiner Engine. Hab auch eine Blender like Kamerasteuerung eingebaut.
WorldEditor04.jpg

edit:
Auch wenn der wxWidget Ordner so groß ist, meine release version von dem Editor ist mit allen drum und dran(karmarama,glew,lua,wxWidget) 1,6MB groß und debug 3,2MB.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich denke mir fallen da noch ein paar weniger positive Aspekte zu einer OpenGL GUI ein.

1) Das Zeichnen der GUI ist sicher schnell aber wie siehts mit dem Rest aus? Wenn recht aufwändige Dinge in der Mitte gezeichnet werden und auf einem Button eine Animation stattfinden soll, dann muss normal das gesammte Bild neu gezeichnet werden. Im Gegensatz zu klassischen GUIs wird also nicht nur der eine Button neu gezeichnet sondern alles. Und das kann je nach Komplexibilität/Hardware und FPS der Animation ziemlich schnell ans Eingemachte gehen.

2) Was man auch nicht zuvergessen sollte ist, dass OpenGL (auch 2D OpenGL) trotzdem noch 3D ist und entsprechende Hardware benötigt. Wohingegen zum Beispiel die Windows GDI durch einen extra 2D Beschleuniger beschleunigt wird. Das setzt so entsprechend höhere Anforderngen an die Hardware. Für meine Karte habe ich unter Linux zum Beispiel keinen richtigen Treiber daher wird nur 2D Beschleunigt und 3D läuft in Mesa. Für deine Anwendung jetzt nicht so tragisch, da du sowieso höhere Anforderungen hast. Aber das sollte man nicht vergessen.

SDL: Würde ich für reine Anwendungen absolut nicht empfehlen! Denn 1) kann es nur ein Fenster aktuell und 2) wird bei Größenveränderungen des Fensters der Kontext weggeschmissen und das ist absolutes K.O. Kriterium für Anwendungen.

Hi,

also das ich das ganze nach C++ portiere ist mehr oder weniger beschlossene sache.. hab gestern schon angefangen, wird zwar ein riesen haufen arbeit, aber ich hoffe es lohnt sich ..

Von den ganzen UI libs kommt für mich denke ich wenn nur wxWidgets in frage.. aber wirklich entschieden habe ich mich nochnicht.

Bei meiner OpenGL UI hätte ich die gewissheit das es überall funktioniert und gleich aussieht etc.. und ich wüsste sicher das ich jedes steuerelement hinbekomme.. der große nachteil in meinen augen ist, wie lossy auch schon meinte das wenn man im Flipbook ein video anschaut und dann in nem anderen fenster über die buttons fährt mit der maus, das die graka ja unter umständen mit dem video überlastet ist..

Dazu auch nochmal eine technische frage:
Sagen wir ich habe 3 fenster, wie sollte man da die verwaltung vom OpenGL machen?
Wenn sie sich alle einen context teilen, bedeutet das ja das bei jedem zeichnen ALLE fenster neu gezeichnet werden müßen, oder?

Ich würde gern aber jedes fenster nur dann zeichnen wenn es nötig wird.. aber das würde halt u.U. viele context wechsel bedeuten, oder?


Zu wxWidgets: Wie schaut es denn da aus mit selbst designten komponenten? ich will halt z.B. das buttons, edits etc nen eigenes design haben, und das muß auf jedem system gleich aussehen... geht das relativ problemlos?

Aya~

I would like to bring xaml into the picture for the user interface that is silverlight on ms, but on linux it is moonlight together with mono.net so c# would be the programming language. The language c# is the same on microsoft as on mono.net (linux) e.g. is just run an webservice written in delphi on a linux server with mono.net. Only you cannot use microsoft ui as that only exists on windows. But with xaml you get the same features as you opengl bases gui, but with the features of the windows ui.
The best thing of xaml is that the ui is completely seperated from code!

have a look at: http://www.mono-project.com/MoonlightShots and http://www.mono-project.com/Moonlight oh it also should work with cpp.

_________________
http://3das.noeska.com - create adventure games without programming

Lossy eX schrieb:

Aber Lossy, Du bist doch so ein alter Hase, Du solltest das doch besser wissen. Wenn Du einen Button auf einer GUI drückst, dann gibt es keinen Grund, warum das ganze Fenster neu gezeichnet werden sollte, der Button sitzt ja nicht mitten auf der zeichnung drauf, das wäre in der VCL ja auch nicht so. Ich mache das auch nicht; der Button ändert ja seine Position nicht, nur weil er gedrückt wurde. Ich bin sogar einmal dazu übergegangen den ViewPort gar nicht mehr zu löschen. Da bin ich aber zu weit gegangen, das ging nur auf meinem eigenen PC gut, auf dem von Lord Horazont waren diagonale Strich zu sehen. Vielleicht ist das ein Nachteil: auf jedem PC wird bei OpenGl eine andere Software/Hardware aktiv, aber das kennen wir ja schon. Ich hatte eine längere Unterhaltung mit Lord Horazont darüber, er nannte das "Painting On Demand", ich kannte den Ausdruck nicht.

Lossy eX schrieb:

Ich glaube mich erinnern zu können, dass der Kontext nur bei neu setzen des Videomodus verloren geht, aber ich könnte mich auch irren.

Aya schrieb:

Es gibt Steuerelemente, die auf MausMove reagieren: der ScrollBar-Balken, alle "hovering" Controls. Buttons gehören standardmäßig nicht dazu. Außerdem: wenn Du Deine GUI selbst im Griff hast, kannst Du auch dafür sorgen, dass so etwas nicht passiert. Man kann z.B. den hovering Controls das Hovering abgewöhnen.

Aya schrieb:

Definitiv NEIN oder auch: das hängt ganz davon ab, wie Du das softwaremäßig aufgezogen hast. Ich nehme nur die Fenster von Windows, die werden von Windows natürlich auch verwaltet aber alle Widgets zeichne ich selber. Daraus folgt: wenn ein Fenster verdeckt ist und dann mit Mausklick nach vorne gerufen wird, schickt mir Windows eine Paint-Botschaft für dieses bestimmte Fenster, hier haben wir wahrscheinlich einen Unterschied. In so einem Fall zeichne ich das ganze Fenster neu, aber Windows kann, weil es weiß, welche Teile des Fensters verdeckt waren, wahrscheinlich bloß den Teil neu zeichnen, der jetzt wieder zu sehen ist. Alle anderen Fenster der Anwendung kriegen KEINE Paint-Botschaft und werden auch nicht neu gezeichnet, weil sie voneinander unabhängig sind: sie haben verschiedenen Fenster-Handles und Botschaften richten sich eben an ein bestimmtes Fenster.

Was und wie oft in meinem Fenster gezeichnet wird bestimme immer noch ich, punktum.

Context-Wechsel:
Bei mir ist es nur ein Context aktivieren weil sich die Fenster den Context teilen, der geht offenbar schneller, weil mir eigentlich keine Zeitverzögerung auffällt, wenn ich ein anderes Fenstern anklicke.
Traude

Also wer kein Scissor verwendet, der wird auch mit vollen gui redraws bestraft.
OpenGL GUI macht auch nur auf das ClientRect ein Scissor und damit wird auch nur der Buttonbereich aktualisiert.

wxWidget und mehere Contexte:
wxWidget bietet bereits eine OpenGL Context Klasse, davon leitest du einfach eine SubClass ab und im Kontruktor wird dann shared Context verwendet. Dafür gibt es im Forum und im Wiki Beispiele.
Es gibt noch ein paar Samples im SDK,Wiki und Forum zum erstellen eigener Widgets mit eigenen Aussehen.
Man hat bei wxWidget wie bei VCL ein Objekt zum zeichnen und kann also ein schon existierenden Button ableiten und dann die Zeichenfunktion überladen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Versteh ich ehrlich gesagt nicht. Ich kann meinen Button neu zeichnen, ohne die ganze GUI neu zu zeichnen. Scissor verwende ich nur für den Button-Text, nicht für den Button selbst, denn für den hat sich ja die Position nicht geändert.