JLI Spieleprogrammierung

[51m0n]

Hi
Hab mich auf die Frage hin wie man ein Menü erstellt ohne eine Resource Datei schreiben zu müssen dazu entschlossen dieses kleine Tutorial zu schreiben.


Warum überhaupt?
Also es gibt sicher Leute die das ganze lieber mit einer Resource-Datei machen, ich allerdings gehöre nicht dazu, denn ich habe wie viele andere vielleicht auch die Express Version von Visual C++, die keinen Resource Editor besitzt. Außerdem ist so ein Menü, dass erst zur Laufzeit erzeugt wird wesentlich flexibler.


Wie funktioniert das?
Ganz einfach als erstes brauchen wir ein Fenster (Wenn ihr nicht wisst wie ihr eins erstellt, solltet ihr euch erstmal ein anderes Tutorial durchlesen).
Dann erstellen wir erstmal das Hauptmenu. Das ist sozusagen, dass Menü, welches alle anderen beinhaltet. Dies erstellen wir ganz einfach so:

[David]

Ganz nett, ja. Aber ich frage mich egtl warum man nicht Tools die es sowiso gibt (z.B. Visual Studio Menü Designer) verwenden sollte und auf die Resourcefiles zurückgreift statt das ganze hart zu coden. Das macht erstens den Code unschön und ist mehr Arbeit.

Was mir persönlich nicht gefällt, aber weniger mit dem Tutorial zu tun hat, ist dieses krankhafte versuchen vom Auflösen sämmtlicher Definitionen die es zulassen. Wieso zur Hölle machst du das?

[GreveN]

Ich glaube Patrick hat irgendwann mal behauptet, dass das "besser" wäre. Allerdings haben diese Typedefs etc. schon ihre Daseinsberechtigung, schon allein der Portabilität wegen, damit du dir keinen Kopf machen musst, wie groß nun eben gerade ein einfaches Integer auf der jeweiligen Plattform ist, neue Features in die Lib integriert werden können - die Funktionen und Datentypen betreffen - ohne das du Code neu schreiben musst usw.

[David]

Weshalb man sie nicht auflösen sollte hast du ja eben schon gesagt. Und was Patrick für besser hält muss es nicht zwangsläufig sein. Was mir auffällt ist dieses Patrickversuchte Verhalten von vielen Anfängern... Die machen oft Dinge die sie nichtmal belegen können und wenn man fragt heists nach einigen seltsamen Erklärungsversuchen: "Keine Ahnung, hab mich halt dran gewöhnt"... Das ist traurig!

[51m0n]

Hallo

Ich will einfach auf den ersten Blick sehen, dass der Typ mit dem ich arbeite ein Zeiger ist. Hier bei der WinAPI ist das nich ganz so wichtig aber wenn ich z.B. mit Direct3D mache dann finde ich es besser mir IDirect3D9* zu arbeiten als mit LPDIRECT3D9. Besonders wenn dann sowas kommt wie LPDIRECT3D9*. Das habe ich schon von Anfang an gemacht, bevor ich Patrik je gesehen hab. Auch habe ich nie mit DWORD usw gearbeitet, weil ich es unsinnig fand solche "Umschreibungen" zu benutzen. TCHAR hab ich allerdings wiederum benutz, weil man dann am code nichts ändern muss wenn man ihn von ANSI nach Unicode transferieren will. Dass ich das jetzt bei (fast) allen anderen Typen auch mache ist will:
1. Ich find es iwie schöner z.B. __stdcall anstatt WINAPI zu schreiben
2. Ich wollte alles einheitlich haben
3. Ja ich gebe zu das Patrick mich auch beeinflusst hat

Aber ich hab dann irgendwann auch eingesehn, dass dieses auflösen oftmals Quatsch ist und habe es inzwichen schon stark eingeschrängt.

(Den Quellcode hab ich aus nem anderen (älteren) Projekt genommen und hab das mit dem HMENU__* nur angepasst, ganz so extrem ist das heute bei mir nicht mehr )
_________________
Teigwaren
heißen Teigwaren,
weil sie früher einmal Teig waren

[Jonathan_Klein]

Ich finde, du slltest Punkt 2 nocheinmal genauer erklären, statt auf das MSDN zu verweisen. Weil, sonst hätte es gereicht "Schau mal nach CreateMenu, AppendMenu und SetMenu zu verweisen, man hätte sich das auch mit den Infos zusammen fuddeln können.
Natürlich muss nicht alles detailliert beschrieben sein, aber die groben Grundlagen, die du im Beispiel ja auch verwendet hast, sollten schon geklärt werden.

Achja: Wenn da schon LPDIRECT3D9 steht, und man weiß, dass dieses LP für long Pointer (dürfte IMHO ein Überbleibsel aus 16 bit Zeiten sein) steht, dann brauche ich persönlich wirklich kein IDirect3D9* um zu erkennen, dass das ein Zeiger ist. Aber jeder wie er meint^^
_________________
https://jonathank.de/games/

[Dragon]

zu 1.
Das ist ja mal eine richtig geile Ausrede. Problem ist aber, dass du deinen Quellcode so nur mit VIsual Studio C++ compiliern kannst. Die ganzen __-Sachen sind nicht standardisiert und sollten eigentlich nicht genommen werden. Typedefs sind da um das Programmieren zu erleichtern, um den Programmiererschreibarbeit abzunehmen und kompatibilität zwischen Compilern zu gewährleisten. Das man auf die LP-Dinger verzichten kann, sehe ich vollkommen ein. Mach ich selber ja auch.

zu 2.
Das ist ja überhaupt nicht einheitlich. Pfui! Warum machst du nicht all deine Funktionen mit __, dann hast du sie wirklich einheitlich. (Ei, ich übertreibe langsam .....)

zu 3.
Es gibt aber sonst nur wenig Leute die sowas machen. Es sieht schon irgendwie krank aus.
_________________
Nur wenn man ein Ziel sieht, kann man es auch treffen.
___________
Mein Leben, Freunde und die Spieleentwicklung

[51m0n]

[DirectXer]

um jetzt auch nochmal meinen senf dazu geben zu müsse :

ich unterstütze simon in der hinsich: ich finde es generell auch schöner die internen bezeichungen zu nehmen (ausnahmen natürlich u.a. TCHAR), da ich dann immer direkt sehe, zu welchen c++-Typ die Variablen gehören. Dazu gehört, dass ich lieber unsigned long als ULONG, DWORD etc. schreibe, damit ich net jedesmal nachschauen muss, wofür das entsprechende typedef jetzt wieder steht. Auch die ganzen defines mit LPDIRECT3D usw. lasse ich lieber weg, damit ich wie gesagt bei IDirect3D* direkt sehe, dass es ein Pointer für das D3D-interface ist. Nebenbei ist auch bewiesen, dass Wörter die nur aus Großbuchstaben bestehen für das menschliche Auge schwieriger zu syntaktisieren sind als gemischte und haupts. klein geschriebene. Von diesen ganzen minimalen Vorlieben, die jeder Programmierer für sich hat, abgesehen, achte ich aber auf eines ganz besonders: Die C++-Casts zu benutzen(und das mit der WinAPI zu verbinden), vor allem in solchen Fällen wie es auch simon schon gemacht hat:

[David]

Es geht nicht nur um den tollen visuellen Eindruck wenn du Typendefinitionen auflöst sondern um die daraus resultierende unportabilität. Die ganzen Typendefinitionen und Defines/Macros stellen eine gewisse Kapselung da. D.h. Microsoft (in dem Fall) nimmt sich u.U. heraus den Typ einer Definition zu ändern und sei es nur der Grund das ein Typ z.B. immer 32 Bit gewährleisten soll.
Wenn du deinen Code dann auf entsprechenden Platformen kompilieren willst siehst du ziemlich alt aus und hast viel Arbeit den ganzen Mist anzupassen.

Darum sollte man die Typendefinitionen eben nicht auflösen und die Vorgaben verwenden. Du erstellst ja auch nicht für jede Klasse eine Equivalente deren ganzen Membervariablen öffentlich sind. Nur weil du's toller findest. Durch auflösen der Typendefinitionen untergräbst du diese teilweise Kapselung die sich Microsoft als Puffer für interne Änderungen geschaffen hat. Und zwar nicht für sich sondern für den Programmierer der die APIs verwendet, um ihm Arbeit zu sparen.

Wegen der C++ Casts:
Das tun gewisse C++ Casts auch, bitweise reinterpretieren. Allerdings werden noch einige Sicherheitsfaktoren berücksichtigt und evtl Exceptions geworfen. Dafür sind C++ Casts teilweise viel langsamer als C Casts.
Ich denke aber nicht das C Casts ungeeignet für C++ Code sind sondern das Casts im allgemeinen ungeeignet für C++ Code sind und darum die Verwendung selbiger möglichst minimiert werden sollte.

grüße

[Jonathan_Klein]

Ein Vorteil an C++ Casts ist ja, das die viel länger und umständlicher sind. So wird man daran erinnert, wie böse es ist, die zu benutzen.
_________________
https://jonathank.de/games/

[David]

[GreveN]

Der Spruch war jawohl mal geil... ;) Danke Jona, du hast meinen Tag erheitert...

Steckt sogar irgendwie soviel Wahrheit drin... ;)

Tut mir Leid dieses OT-Postings wegen, aber das musste raus... ;)