API, MFC und so weiter
-
huch??? schrieb:
tja, rüdi. hast wohl deine meinung geändert.
Das kann in 4 Jahren durchaus passieren
. Ich bin ja kein Dogmatiker (zumindest nur teilweise ;)).
-
rüdiger schrieb:
Der Vorteil das man sich nicht um die Details - die man ohnehin noch nicht versteht - kümmern muss oder Code von anderen Anfängern von dubiosen Webseiten und aus Foren kopiert, überwiegt mögliche Probleme. Ich kenne weder Ogre noch Irrlicht. Aber ich halte es für einen besseren Weg etwas fertiges zu nehmen, als sich erst einmal müselig durch OpenGL oder Direct3D zu quälen und die Fehler noch mal machen zu müssen, mit Problemen konfrontiert zu werden, die man noch gar nicht verstehen kann etc. Am Anfang ist es ohnehin erst einmal wichtig, einen Erfolg zu haben und nicht von den Details aufgefressen zu werden. Wenn man dann genug Erfahrung gesammelt hat, kann man immer noch auf die unteren Ebenen steigen. Aber dann ist man in der Lage, die Schwierigkeiten und Probleme besser verstehen zu können.
Eigentlich ist die normale Lernmethode immer anders rum. Man lernt immer erst die Grundlagen und benutzt dann Hilfsmittel. Oder hat man dir in der Schule erst nen Taschenrechner in die Hand gedrückt, damit du schnell nen Erfolg hast und irgendwann später mal das Rechnen beigebracht?
-
rüdiger schrieb:
huch??? schrieb:
tja, rüdi. hast wohl deine meinung geändert.
Das kann in 4 Jahren durchaus passieren
.kein problem, das ist normal. damals fand ich auch noch C++ gut
-
wowuwu schrieb:
Eigentlich ist die normale Lernmethode immer anders rum. Man lernt immer erst die Grundlagen und benutzt dann Hilfsmittel.
Es gibt nicht die "normale Lernmethode". Ob Top-Bottom oder Bottom-Top sinnvoll ist, hängt stark von dem Bereich ab. zB lernt man idr erst klassische Mechanik, Elektrotechnik mit idealen Bauelementen oder Chemie in der Schule ohne Teilchenphysik zu lernen. Später geht man dann auf die Details runter.
Und natürlich könnte er erst die Mathematik und Informatik lernen, um sich einen Renderer zu schreiben und ein Dateisystem, um zu verstehen was hinter dem öffnen und lesen von Dateien steckt etc. Aber ich sag mal mit der Methode wird er nie zu seinem Ziel kommen, ein Spiel zu schreiben.
-
rüdiger schrieb:
Es gibt nicht die "normale Lernmethode". Ob Top-Bottom oder Bottom-Top sinnvoll ist, hängt stark von dem Bereich ab. zB lernt man idr erst klassische Mechanik, Elektrotechnik mit idealen Bauelementen oder Chemie in der Schule ohne Teilchenphysik zu lernen. Später geht man dann auf die Details runter.
Und natürlich könnte er erst die Mathematik und Informatik lernen, um sich einen Renderer zu schreiben und ein Dateisystem, um zu verstehen was hinter dem öffnen und lesen von Dateien steckt etc. Aber ich sag mal mit der Methode wird er nie zu seinem Ziel kommen, ein Spiel zu schreiben.
Grundlagen lernen bedeutet nicht jedes winzigste Detail eines komplexen Systems zu kennen und immer alles bis zur "Quantenphysik-Weltformel" runter brechen zu können. In der Elektrotechnik fängt man auch mit Kabeln, Schalter, Glühbirne, Widerstand usw. an und kommt dann irgendwann zum IC. Wer ein 3D Spiel programmieren will, der sollte erst mal wissen was Vertices, Texturen usw. sind und wie man die bewegt und was da passiert. Wenn man das verstanden hat, kann man eine Engine für seine Bedürfnisse aussuchen und die verwenden. Man muss deswegen nicht vorher eine programmieren. Wenn man nur ein Spiel zusammenklicken will und nicht wirklich programmieren lernen will, dann kann man auch so nen Gamemaker nehmen.
-
Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.
-
rüdiger schrieb:
Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.
Ja, aber das Verständnis einer GameEngine fällt tausend mal leichter, wenn man das schon weiss. Einem Anfänger in der Spieleprogrammierung würde ich eher alle Nehe-Tutorials empfehlen, als eine fertige Engine. Da bekommt man Schritt für Schritt die Grundlagen und vor allem die Begriffe beigebracht.
rya.
-
Scorcher24 schrieb:
rüdiger schrieb:
Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.
Ja, aber das Verständnis einer GameEngine fällt tausend mal leichter, wenn man das schon weiss. Einem Anfänger in der Spieleprogrammierung würde ich eher alle Nehe-Tutorials empfehlen, als eine fertige Engine. Da bekommt man Schritt für Schritt die Grundlagen und vor allem die Begriffe beigebracht.
rya.Ich sehe jetzt den Unterschied nicht. Um wirklich zu begreifen was Vertices und Texturen sind, sollte er wohl eher einen Renderer selbst schreiben.
-
rüdiger schrieb:
Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.
Ja, und?
-
wowuwu schrieb:
rüdiger schrieb:
Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.
Ja, und?
Du meintest, er soll wissen was das ist.
-
Ruediger hat Recht, oder anders gefragt: wo beginnt denn die "Spieleprogrammierung"?
Fertige Engines wie Ogre3D oder Irrlicht schaffen eine hoehere Abstraktionsebene, was einem erlaubt auf Detailwissen zu verzichten und sich auf die "Spieleprogrammierung" zu konzentrieren, statt auf die Grafikprogrammierung. Bei Spieleprogrammierung denkt man nicht an Grafikobjekte, sondern an Spielobjekte.
-
rüdiger schrieb:
wowuwu schrieb:
rüdiger schrieb:
Was Vertices und Texturen sind, muss er ja auch bei einer fertigen 3D Engine wissen.
Ja, und?
Du meintest, er soll wissen was das ist.
Ich hab mehr gesagt als das. Musst schon den Zusammenhang betrachten und nicht nur ein paar Wörter raussuchen.
Apollon schrieb:
Ruediger hat Recht, oder anders gefragt: wo beginnt denn die "Spieleprogrammierung"?
Fertige Engines wie Ogre3D oder Irrlicht schaffen eine hoehere Abstraktionsebene, was einem erlaubt auf Detailwissen zu verzichten und sich auf die "Spieleprogrammierung" zu konzentrieren, statt auf die Grafikprogrammierung. Bei Spieleprogrammierung denkt man nicht an Grafikobjekte, sondern an Spielobjekte.
Grundlagen != Detailwissen. Ich weiß nicht wieso ihr das immer vermischt.
-
danke erstmal für die vielen Antworten
ich hab jetzt erstmal das API Buch beiseite geschoben und eins für die MFC rausgesucht.Was Vertics, Texturen und so sind, weiß ich und ne Umgebung würde ich hinkriegen.
@Scorcher24: danke, ich werd dir gleich ne e-mail schicken, oder per icq...
Wenn MFC veraltet ist, wie rüdiger meint, was ist denn dann aktuell?
-
wxWidgets als Bsp oder GTK. Ich empfehle aber wxWidgets, ist imho attraktiver und komplett in C++.
http://wxwidgets.org
rya.
-
kann ich in den wxWidgets auch auf API funktionen zugreifen, wie bei den MFC?
-
API? API ist ein allgemeiner Ausdruck. Welche API meinst du?
Ich würde dir eher FLTK empfehlen, da es klein und kompakt ist. Die API ist ein bisschen OpenGL ähnlich und verfügt über gute OpenGL Integration.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Andere GUIs - Qt, GTK+, wxWidgets verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
ich mein die WinAPI
-
seux schrieb:
ich mein die WinAPI
Natürlich würde das gehen, ist aber nicht notwendig. wxWidgets ist XPlatform, das bedeutet, deine Progs kompilieren sowohl unter Windows als auch unter Linux oder Mac etc. wenn du jetzt direkt die WinAPI verwendest, geht das nicht mehr.
Vor allem isses aber wie gesagt nicht nötig. Alles was mit der WinAPI an Fenstern/Controls etc geht, geht auch mit wxWidgets und vieles mehr.
rya.
-
seux! Denke doch mal nach: nur weil du eine zweit oder dritte Library benutzt, fliegt doch die erste Library nicht raus. Warum sollte also die Win32-Library nicht mehr funktionieren, wenn du wxWidgets benutzt?
Scorcher24! Er kann trotzdem Win32-APIs aufrufen, ist ja seine Entscheidung, wofür er wxWidgets missbraucht. Da er auch MFC benutzt hätte, ist ihm platformunabhängigkeit ziemlich wurscht. Und das ist legitim.