MFC-Dialoge

[CBot]

Ich hab http://www.sfml-dev.org/tutorials/2.1/window-opengl.php mal angelesen. Allerdings sind mir da ein paar Sachen noch nicht klar. Bisher sieht mir SFML noch nach einem eher duennen Wrapper aus, die OpenGL-Funktionen, die aufgerufen werden, kommen mir recht bekannt vor. Womoeglich kommt die wahre Staerke beim Zeichnen zum tragen.

@trommlbomml: Falls Du schon etwas Vorzeigbares haettest, waere ich sehr interessiert, da mal einen Blick drauf zu werfen.

[trommlbomml2]

Das Einbinden von SFML funktioniert prima, habe ich auch schon gebaut. Spannder ist tatsächlich die Integration BotE. Ich muss wissen, welche Views gerade aktiv sind und für diese eine Extra Methode aufrufen um zu rendern. Problem dabei ist, dass man so ohne weiteres gar nicht in MainFrm oder HwndSplitter herausbekommt, welche CView-Instanzen gerade dargestellt werden. Man bekommt nur CRunTimeClass-Instanzen, mit denen kann ich nicht viel anfangen.

Ansonsten ist die idee wie folgt:

Jeder View, der mit SFML rendert ist ein CView, der von CCustomRenderView erbt.
MainForm definiert einen Timer, der 30 mal die Sekunde triggert. Dann werden für alle aktiven CView-Instanzen eine extra Methode CCustomRenderView::OnCustomRender() aufgerufen. Dort kann man dann in dem jeweiligen View einfach zeichnen, wozu man lust hat.

Problem dabei ist, dass alle Views denke ich von dieser Basisklasse erben sollten, sonst muss ich jeden aktiven View versuchen zu casten, und das ist doch doof und nicht wirklich schön. Wenn ein View nicht SFML rendert, dann wird einfach eine leere Methode aufgerufen.

Also wenn mir jemand bei den wer ist der aktive View Problem Unterstützung leisten kann, wäre das klasse!

Zusätzlich ist noch das Problem, dass SFML seine Bilder selber verwalten muss, somit teilweise Ressourcen doppelt geladen werden (Bilder). Das ist ein tradeoff, der aber denke vertretbar ist.

EDIT: Was du suchst CBot ist der Konstruktur RenderWindow(Windowhandle handle). Er erlaubt auch das Wrstellen von RenderWindows auf Basis eines beliebigen Window-Handle, also irgendein Control innerhalb eines Fensters. Und ein CView ist ein CHwnd und somit kann man sich per GetSafeHwnd() das Window-handle holen und den ganzen View nativ mit SFML pepinseln!

[rainer]

leider etwas querschießend, aber nachdem ich gerade mit Paul darüber sprach, hatte er noch folgende Idee:

rotierende Planeten (bzw. was es sonst noch gäbe): Wenn wir CPU-Probleme kriegen, könnte man es auch so machen, dass im kleinen Fenster links unten jeweils der eine Planet rotiert, wenn die Maus in der Bottomview drüberfährt.

Dass mit dem kleinen Fenster ist nur eine Idee, kann man vll. auch im Tooltip oder wo auch immer unterbringen

[rainer]

noch was: VinculumOne aka Flocke aka Hannes wrote in the new BotF2-forum (for this you'll need an proboard account) http://star-trek-supremacy.proboards.co ... 2/quote/10

(vll. hilfreich für uns, aber da kennt Ihr Euch besser aus....Flocke http://forum.birth-of-the-empires.de/me ... ofile&u=18 wird sich wohl nicht für BotE gewinnen lassen, er programmiert wohl an seinem BotF-original herum http://www.armadafleetcommand.com/onscr ... d93#p37920 ) ...was nicht heißt, dass wir ihn nicht aufnehmen würden

I read up on it a bit more myself. Found that some guys copied MFC over from a VS Professional Demo install and got it work with Express, however this would not be covered by license ofc. MS clearly only continues to include and support MFC with their commercial VS releases. There is no seperate download other than some pretty old ones.
MFC is becoming deprecated by MS, as far I can see they only keep supporting it for big companies that still rely on MFC. Wouldn't be surprised when in some years it's dropped completely in favor of C# WPF development. Heck they already dropped Windows Forms for C++ in the project templates. Ofc you still can upgrade from old projects and copy over the library if missing but when possible I'd rather recommend to avoid it. Both for Windows Forms and MFC.

When you want to develop gui applications in C++, either use C# for the gui part and only do the backend part in C++, move over to C# completely or use one of the many non-MS gui libraries like Qt or wxWidgets. With them you might also consider to use a different IDE than MS VS. Qt comes with it's own Qt Creator IDE anyway and wxWidgets is better to use with Code::Blocks cause with wxSmith it has a gui designer for wxWidgets but I didn't see one for VS.
Further Qt and wxWidgets are great for cross platform development. Used both myself before.

I'm kinda disappointed that MS doesn't support better ui development with C++ as it's my favorite language still, but well for the ui C# performance drop isn't too bad so I can understand they want to enforce using it instead. Would be great if only WPF would be a little more complete.

[Nobody6]

Was auch immer Ihr tut, bitte wechselt NIE auf etwas wechselt was ".net" erfordert. Ich habe/kenne gleich mehrere Computer auf denen sich .net nicht installieren lässt und/oder es zwar installiert ist, aber von keinem Programm erkannt wird.

Wenn eine solche große Änderung ansteht hoffe ich, dass auf etwas Plattformübergreifendes gewechselt wird - sei das nun gnu C oder eventuell auch Java. Mein persönlicher Favorit wäre freilich FreePascal, aber das ist eine andere Geschichte.

[trommlbomml2]

Da mittlerweile Firmen auf C# und .NET im Plattformunabhängigen bereich setzen, wie bspw. Xamarin, glaube ich das persönlich nicht mehr so. Vor allem der sehr übersichtliche Sprachkonfort mit C# ist da eine gute Wahl.

Unabhängig davon ist es natürlich trotzdem nicht ohne, .NET auf mehreren Plattformen gleich gut laufen zu lassen, aber das hat man wohl bei jeder Crossover-Plattform - so zumindest meine Erfahrung.
Da das gesamte Spiel schon C++ ist sollte es das auch bleiben. Das Portieren ist bei der Menge an Code, den keiner so richtig kennt, einfach zu Riskant, so sehr ich .NET auch favorisiere.

[Dennis0078]

huhu seit ihr noch dran?