spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Die Idee feier ich.
.., aber wenn du C++ nutzt warum dann das SAFE_DELETE-Makro, wenn's doch auch ein Template tut (und zwar besser/korrekter)?

Zitat von »IaSfC«

Verbesserungsvorschläge sind gerne willkommen

Was mir als erstes ins Auge gesprungen ist, sind die IncludeGuards. Diese stehen zwar drin, machen aber nicht das wofür sie da sind.
Ich persönlich mag keine Init-Methoden, deshalb empfehle ich immer den Konstruktor zu nutzen deshalb ist er da.
Im Konstruktor von CGame wir m_bRunning schon mit true Initialisiert, vom Logischen ablauf nicht Korrekt da diese Variable erst nach aufruf von run() true sein sollte.

CGame.cpp

Das prüfen von result == 0 könnte man sich sparen, da es an dieser Stelle immer 0 ist (ebenfalls m_bRunning da auch immer true, siehe oben).

Ansonsten seid ihr ca. 5 Jahre zu späte , damals hätte ich es gute gebrauchen können, um mal den Aufbau von Spielen nachvollziehen zu können.
Für Neulinge aber mit Sicherheit eine gute Sache.

Gruß Koschi

Zitat von »IaSfC«

	C-/C++-Quelltext
1 2	m_pEvent = new SDL_Event(); if( m_pEvent == nullptr )

Wieso sollte das fehschlagen? Und wieso sollte es nullptr zurückliefer? Wenn new fehlschlägt, wirft es eine Exception. Der IF-Block wird jedenfalls nie betreten werden. Zusätzlich wäre bei Heap-Elementen auch unique_ptr zu empfehlen. Wir leben schließlich in 2015 Wozu allerdings das Event überhaupt auf dem Heap liegen sollte... mir fällt da kein Grund für ein.

Zitat von »IaSfC«

// Main wird hier als nicht definiert deklariertt
#undef main

Was zur Hölle ist denn das? Das habe ich ja noch nie gesehen! Das ist äußerst bedenklich. Mal davon abgesehen, dass deklariert nur mit einem t geschrieben wird.

Zitat von »IaSfC«

result = game.Initialize();
...
game.Finalize();

Um Gottes Willen! Genau dafür sind Konstruktor und Destruktor da! Solche init-deinit-Methoden gehören verboten, auf den Müll geworfen und vergessen. Das ist super schlechter Stil, der etwas produziert, was eigentlich in C++ wunderbar funktioniert, wenn man es richtig macht!

Zitat von »IaSfC«

#ifndef __ENIGNE_H__

Von Elementen, die mit zwei Unterstrichen beginnen, sollte man die Finger lassen. Diese Art der Deklaration ist für Compiler-spezifische Dinge vorgesehen.

Wie Koschi auch schon sagte, sind außerdem die Include-Guards alle bösartig falsch.

Zitat von »[Anonymer Benutzer]Soft«

Ab damit auf GitHub

Nein, bitte nicht! So ein schlechtes Beispiel sollte nicht auch noch auf github liegen, da liegt schon viel zu viel schlechter Code.

Versteht mich bitte nicht falsch, ein Tutorial ist eine schöne Sache. Es sollte aber nicht von Neulingen geschrieben werden, sondern von jemandem, der Ahnung hat. Zudem passiert in dem Code ja gar nichts, außer dass die SDL hoch und runter gefahren wird. Das findet man doch sicherlich in den SDL-Samples (http://www.sdltutorials.com/tutorials) ebenfalls und das auf eine korrekte Art und Weise. Es ist gefährlich für andere Neulinge, wenn so schlechtes Halbwissen verbreitet wird!

Zitat von »BlueCobold«

Zitat von »IaSfC«

// Main wird hier als nicht definiert deklariertt
#undef main

Was zur Hölle ist denn das? Das habe ich ja noch nie gesehen! Das ist äußerst bedenklich. Mal davon abgesehen, dass deklariert nur mit einem t geschrieben wird.

Die SDL bringt eine hauseigene main mit (SDL_main) welche als Makro "main" deklariert wird. Wenn du nun deine eigene main Funktion hast, musst du deren Makro undefen oder SDL_SetMainReady benutzen.

Und das macht man in einem Header? Zudem klingt die Verwendung der Main-Lib wohl wesentlich sinnvoller.

Kann man auch. Ich persönlich undefe meistens.

Ich halte das für sehr bedenkliche Praxis.

Zitat von »IaSfC«

es steht ganz oben das dies kein Tutorial ist, sondern ein Framework.

Das macht es ehrlich gesagt sogar noch schlimmer, wenn jemand so schlechten Code direkt verwenden soll.

Zitat von »IaSfC«

Hast du dir mal auf SDL-Samples (http://www.sdltutorials.com/tutorials) das Basic Tutorial angesehen?? Auch hier wird eine eigene Initialize() verwendet. (...) Soviel zum thema sowas gehört auf den müll, das machen Konstruktor und Destruktor.

Nur weil es jemand anders macht, macht es das nicht besser. Solche Sachen gehören in den Konstruktor oder Destruktor.

Zitat von »IaSfC«

kommt davon wenn man schreibt und nicht Copy Pastet.

Aha, also eine indirekte Behauptung, dass andere ihr Zeug nur deshalb richtig schreiben, weil sie Copy+Paste verwenden? Sorry, aber das meinst Du hoffentlich nicht ernst. Das sind drei Zeilen winziger Code und so offensichtlich unlogisch, dass ich nicht nachvollziehen kann, wieso man das von Hand schreibt und es nicht merkt.

Die übrigen Mängel bleiben übrigens bisher auch noch bestehen... Heap statt Stack, Raw-Pointer statt Smart-Pointer.