Editor Gui Talk [split aus dem screenshot thread]

this-*gt*that

@Vertexwahn: Welches GUI Toolkit benutzt du? Cool, studierst du jetzt auch an der TUM? Schon Vorlesungen vom Prof. Westermann besucht?

Vertexwahn

zur Technik:
Programmiersprache: C++
Enticklungsumgebung: Anfangs Visual Studio 2008 Pro, jetzt Micrsoft Visual Studio 2010 Ultimate
Third Party Libs: Boost 1.43.0, Cg 2.2, CML 1.0.2, GLEW 1.5.5, OGLES 1.0.0, QT 4.7 (hab mit 4.5 angefangen), VLD 2.0a, hier und da ein wenig WinAPI und GDI+, OpenGL 2.1

Hab alle Vorlesungen, die der CG Lehrstuhl anbietet besucht - aber ich will hier nicht zu Off Topic werden

this-*gt*that

Vertexwahn schrieb:

zur Technik:
Programmiersprache: C++
Enticklungsumgebung: Anfangs Visual Studio 2008 Pro, jetzt Micrsoft Visual Studio 2010 Ultimate
Third Party Libs: Boost 1.43.0, Cg 2.2, CML 1.0.2, GLEW 1.5.5, OGLES 1.0.0, QT 4.7 (hab mit 4.5 angefangen), VLD 2.0a, hier und da ein wenig WinAPI und GDI+, OpenGL 2.1

Sieht klasse aus dein Editor. Werd auch bald anfangen einen zu schreiben und bin noch immer am überlegen, welches Toolkit ich nehme. Ich tendiere eigentlich stark zu einem .NET Toolkit (WPF oder evtl. WinForms) - die sind einfach ein Traum zum designen. Allerdings würde ich als Sprache C# benutzen und müsste dann Tonnen von C++/CLI Wrapper um die C++ Klassen meiner nativen D3D Render-Engine schreiben;(
Drum glaube ich fast, dass ich auch QT nehmen werde. Das sollte ja problemlos mit D3D11 zusammenarbeiten, oder?

Vertexwahn schrieb:

Hab alle Vorlesungen, die der CG Lehrstuhl anbietet besucht - aber ich will hier nicht zu Off Topic werden

Hehe, dito.

Jochen S.

this->that schrieb:

Allerdings würde ich als Sprache C# benutzen und müsste dann Tonnen von C++/CLI Wrapper um die C++ Klassen meiner nativen D3D Render-Engine schreiben;(

Und wenn du einfach eine Klasse für Gui basierend auf D3D schreibst? Ich hab mal eine für meine Engine geschrieben. (Die Gui in meinem Editor basiert auf der Klasse). Ist jetzt nicht allzuviel Aufwand. Meine Gui-Klasse hat nur etwa 3000 Zeilen Quelltext. Und man hat da eien hohe Flexibilität.

MfG, Jochen

this-*gt*that

Jochen S. schrieb:

this->that schrieb:

Allerdings würde ich als Sprache C# benutzen und müsste dann Tonnen von C++/CLI Wrapper um die C++ Klassen meiner nativen D3D Render-Engine schreiben;(

Und wenn du einfach eine Klasse für Gui basierend auf D3D schreibst? Ich hab mal eine für meine Engine geschrieben. (Die Gui in meinem Editor basiert auf der Klasse). Ist jetzt nicht allzuviel Aufwand. Meine Gui-Klasse hat nur etwa 3000 Zeilen Quelltext. Und man hat da eien hohe Flexibilität.

MfG, Jochen

Ich weiß ehrlich gesagt nicht, was du damit meinst. Was meinst du mit "eine Klasse für Gui basierend auf D3D"?
Mein jetziger Editor basiert auf WinForms, Sprache C++/CLI. Ich habe mich damals für C++/CLI entschieden, weil ich dann einfach Managed Code und meine native D3D Lib mixen und mit /clr zu einem Managed Binary kompilieren konnte.
Das gefällt mir aber nicht mehr und selbst MS empfiehlt, C++/CLI nur noch als Interop Sprache zu benutzen. Drum will ich auf jeden Fall meinen Editor komplett neu schreiben (entweder mit C# und Winforms oder WPF oder eben QT)

Jochen S.

Ich meinte damit, dass du den Editor auch ganz ohne Forms oder sonstigem schreiben könntest. Mein Modelleditor verwendet lediglich die WinApi, DirectX und eben meine Engine, die auch eine Klasse für grafische Oberflächen besitzt. Die Oberfläche wird dann gleich aus Dreiecken zusammengesetzt und mit DrawPrimitive gezeichnet. Ist zwar ein wenig aufwendig, so eine Klasse zu schreiben, aber dafür ist man dann sehr flexibel.

this-*gt*that

Jochen S. schrieb:

Ich meinte damit, dass du den Editor auch ganz ohne Forms oder sonstigem schreiben könntest. Mein Modelleditor verwendet lediglich die WinApi, DirectX und eben meine Engine, die auch eine Klasse für grafische Oberflächen besitzt. Die Oberfläche wird dann gleich aus Dreiecken zusammengesetzt und mit DrawPrimitive gezeichnet. Ist zwar ein wenig aufwendig, so eine Klasse zu schreiben, aber dafür ist man dann sehr flexibel.

Ja, dachte mir schon fast, dass du das meinst.
Aber ne, das is keine Option für mich. Erstens Mal ist das ne Schweine Arbeit, bis sowas wirklich gut läuft. Das ist ja nicht nur "eine Klasse" (außer man macht eine 20000 Zeilen Gottklasse ;), sondern ein ganzes System, bestehend aus Controls, Events, Paintlogik, Resizing...
Nene, ich will das Rad nicht neu erfinden, zumal es mittlerweile ja wirklich gute Gui Toolkits gibt (WPF is ein ziemlicher Hammer). Außerdem soll meine Anwendung schon eine echte Windows-Anwendung sein mit den gewohnten Controls.

rapso

ich beneide euch editor schreiber, ich hasse gui coden und finde nicht so wirklich eine gute. Alle schwaermen von WinForms, aber als ich das letzte mal einen editor mit c# schrieb hatte der editor mehr speicher verbraucht (obwohl nur gui anzeige und event handling per tcp/ip zu der "richtigen" app stattfand), als die ganze engine wenn sie ein level geladen hatte. (die startzeiten waren auch laenger als von der engine wenn sie dazu ein level lud.

ich habe mir auch, wie "Jochen S" schrieb 'mal eben' ein gui kit geschrieben, an sich bin ich recht zufrieden, weil es komplett abstrahiert laeuft. es gibt zwar eine grobe hierarchy bei der objekte miteinander verbunden sind, das war es aber schon mit hardcoden, der rest laeuft ueber events die rein string basiert sind, darin kann ich also sogar lua scripts verschicken wenn ich will.

das problem ist, es ist viel arbeitszeit das zu erweitern, im besonderen um es useferfriendly und custumized zu machen, und da ich keinen editor fuer die gui habe, ist vieles handgeschriebene xmls, was nun wirklich alles andere als userfriendly ist.

was mir bisher noch ganz ok gefiel war wxwidgets, aber laut den gui gurus hier im forum ist das schon outdated. ich glaube ich werde als naechstes auch mal Qt probieren.

[edit: mal gesplitet damit der andere thread nicht vom screenshot zum tratsch thread verkommt ]

this-*gt*that

Hab mich gestern noch per Messenger mit Vertexwahn unterhalten und vermutlich entwickeln wir jetzt beide parallel unsere Editoren mit Qt und können uns dann immer wieder mal gegenseitig helfen.
In 6+ Monaten gibts dann vllt sogar die ersten Screenshots;P

GUI coden find ich eigentlich ganz angenehm und eine willkommene Abwechslung zum komplexen 3D-Grafik-Mathe gehaxx0r. Is schön entspannend und man muss nicht viel nachdenken (im Grunde wie Webdesign). Hauptberuflich möcht ich sowas auch net machen, aber zwischendurch find ichs angenehm.

Ich war mit WinForms extrem zufrieden. Der GUI Designer ist klasse und Performance Probleme hatte ich auch nie. Klar braucht .NET Runtime einiges an Speicher, aber auf heutigen PCs nicht mehr wirklich ein Problem. Der ständig steigende Speicherbedarf bei dir könnte auch an einer suboptimalen Renderloop liegen. Hab da auch einige Zeit googeln müssen, bis ich eine gute hatte. Wenn man nicht aufpasst, allokiert .NET in jedem "Schleifendurchlauf" Speicher.

Ich habe mir so ziemlich alle großen GUI Toolkits angeschaut und mein Kurzfazit ist:

WinForms: Klasse, man kommt sehr schnell voran. Angenehmer Code.
WPF: Genial, extrem mächtig. Aber man braucht schon fast einen Grafiker, um was wirklich beeindruckendes zu schaffen.
MFC: Alt, hässlich.
wxWidgets: Alt, hässlich, MFC-Stil.
QT: Sehr angenehme API, gut dokumentiert. Das schönste native GUI Toolkit, das ich gefunden hab.
Motif: Alt, hässlich.
GTKmm: Ganz ok.

rapso

hab bis ich zur arbeit musste auch noch ein partiel alternativen angeschaut (hatte backups gemacht und das verlangt nur ab und zu nen klick oder dateiverschieben).

-CeGUI angesehen, an sich schaut das nett aus, wohl ausreichend fuer spiele (hat auch styles die man laden kann), allerdings wohl nicht maechtig genug umalles machen zu koennen (also eher lightweight im vergleich was ein leveleditor machen muss).
-WinForms angesehen (mit c++ /clr), an sich auch ganz gut, erinnert mich ein wenig an den borland builder.
-Qt hatte ich mir schon vorher angesehen, da gefaellt mir das feste binden von signal->slot nicht, wenn ich schon signals verwende, dann nutze ich lose bindungen. (also ein signal wird verschickt und die empfaenger filtern sich schon raus was noetig ist). hab zuviele projekte mit libsig gesehen die debugging horror waren, vielleicht bin ich deswegen biased.
-WTL, hmm,an sich nett, aber code based gui basteln ist auf dauer eing raus (jedenfalls waren die ganzen ergoogleten tutorials so).
-MFC mal wieder angesehen, ich muss sagen, es wirkt wie WinForms von der integration in VS her, so richtig was stoerendes daran hab ich nicht gefunden (aber ich mag ja auch wxWidgets).

kann mir jemand sagen (vielleicht an beispielen, vielleicht sogar auf gfx editoren) was so schlecht an MFC/wxWidgets ist. Ich code alle 10jahre mal nen editor und da opfer ich nur die aller aller noetigste zeit fuer die gui.

meine traum gui lib wuerde wohl komplett entkoppelt von der eigentlichen app laufen, nur auf signals/events warten und diese zurueckliefern, eine event-queue als schnittstelle und das wars.

GuiSingleton=GUI::Init("guiAusEinemExternenEditor.xml");

//somewhere in main loop
while(pEvent=EvenQueue.Pop())
{
if(!GuiSingleton->Process(pEvent) && 
   !EngineSingleton->Process(pEvent))
   Console.Warning("Missed event:",pEvent->AsString());
}   
.
.
.
EngineSingleton->Render();
EngineSingleton->BltOnTop(GuiSingleton->Render());

this-*gt*that

rapso schrieb:

kann mir jemand sagen (vielleicht an beispielen, vielleicht sogar auf gfx editoren) was so schlecht an MFC/wxWidgets ist.

Keine Ahnung wieso es andere mies finden, aber MIR gefallen die nicht weil es nicht modernes C++ ist, sondern eher C mit hässlichen Makros. Wenn ich damit entwickel, komme ich mir vor wie im Jahr 1990. Wieso mich also damit rumplagen, wenn es schönere Alternativen gibt.

rapso

Naja, das macht alles visual studio im hintergrund, da sollte sich niemand mit plagen imho. oder muss man da noch was von hand machen? (wie gesagt, ich schreib selten gui, deswegen die vielleicht dummen fragen).

this-*gt*that

Hm, hab grad mal wieder den Code geöffnet (seit über einem Jahr^^) und wie es aussieht mach ich auch nix besonderes. Im Großen und Ganzen erzeug ich nur eine Instanz meiner Fensterklasse und starte dann die Anwendung mit Application::Run(form).
Dann häng ich im Ctor meiner Fensterklasse einen Eventhandler an das OnIdle Event der Application:

Application::Idle += gcnew EventHandler(this, &EditorForm::OnIdle);

...
void OnIdle(Object^ sender, EventArgs^ e) {
   MSG msg;		
   while(!PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
      processFrame(); 
}

processFrame() ruft dann mein update() und render() auf.
Hab die Anwendung vor gut 2 Jahren unter Vista geschrieben und jetzt zum 1. Mal seit langem versucht das Ding wieder zu starten (benutze mittlerweile Win 7) - gibt leider eine Exception
Drum kann ich dir im Moment leider net sagen, ob bei meiner Anwendung auch permanent der allokierte Speicher steigt.

Da ich jetzt wohl eh auf QT umsteig und alles neuschreib, werd ich vermutlich auch garnet mehr versuchen meinen WinForms Editor zu fixen. (Nervig isses irgendwie schon, dass es nicht mehr geht, nur weil ich von Vista auf Win7 gewechselt hab...)

rapso

vielleicht mal das compatibility flag setzen, oder bist du vielleicht von 32bit auf 64bit gegangen?

Jochen S.

Naja, mein Editor war auch so ein Projekt, das ich "mal eben so" angefangen habe, ich hatte gerade mein letztes Spiel fertig und da dachte ich, ich mache mal was anderes. Dass ich jetzt die Gui-Komponente meiner Engine für die Oberfläche benutzt hab, liegt daran, dass ich die sowiso schon für meine Spiele geschrieben habe. (Bei den Spielen kann man nicht so eingach auf windows forms zurückgreifen, oder?)
Ich hab mich auch mit den ganzen Gui-Bibliotheken zu wenig befasst, ich wusste nicht, wie ich in dem Fenster Direct3D-Grafik mit Hardwarebeschleunigung integrieren sollte. Aber die Gui-Klasse ist eigentlich ausreichend für meine Zwecke. An der Klasse ist auch eineiges an gemurkse, z.B. kann man ein Button in eine Proces-Bar umwandeln, wenn man möchte. Mit den Nachrichten hab ich das so gelöst, dass man einer Instanz einen zeiger auf eine Funktion übergeben wird, die Aufgerufen wird, wenn etwas mit dem Element passiert ist.

MfG, Jochen

rapso

winforms wohl nicht, aber WPF soll d3d fuers rendern nutzen.

wie werdet ihr die editor-gui erstellen? per code oder mittels tools? (also die qt jungs hauptsaechlich).

this-*gt*that

Jochen S. schrieb:

(Bei den Spielen kann man nicht so eingach auf windows forms zurückgreifen, oder?)

Nein, das geht nicht.

rapso schrieb:

winforms wohl nicht, aber WPF soll d3d fuers rendern nutzen.

Japp, allerdings wohl nur D3D9, damit es auch noch auf WindowsXP läuft. D3D10/11 zu integrieren soll bissi schwieriger sein.
Was man mit WPF machen kann, ist schon ziemlich cool: http://www.youtube.com/watch?v=MTfM5pmUrnU&feature=related
Das meiste ist zwar Spielerei, aber allein DASS es geht ist interessant.

Jochen S. schrieb:

wie werdet ihr die editor-gui erstellen? per code oder mittels tools? (also die qt jungs hauptsaechlich).

Bei QT gibts ja einen Designer. Wenn der gut ist, werd ich den benutzen. Is mir auf jeden Fall lieber als die ganzen Controlwerte (Positions, Widths, Heights, Margins etc.) im Code reinzuhacken und alle 5 Minuten zu kompilieren um zu schauen obs gut aussieht.
Im Idealfall design ich die GUI im GUI Designer und programmiere den größten Teil der Logik sowie Engine Interop und Engine selber in VS 2010.

Vertexwahn

wie werdet ihr die editor-gui erstellen? per code oder mittels tools?

Ich hab so viel wie geht mit dem QT Designer erstellt. Meine persönliche Philosophie: Alles was möglich ist im Designer machen - wenn möglich keine Zeile Programmcode tippen.