Spieleprogrammierung... Noob's Fragen...

[crazychicken]

stefan scherfgen

der typ heisst übrigens david

nun zum Buch:
am Anfang kommt jede Menge Mathematikscheiss, den man (bzw. ich :p)
nicht kapiert - wenn man allerdings die ersten 100 Seiten
hinter sich hat, wird einem alles ein bisschen klarer.

ps:
das wichtigste, was man sonst noch so braucht, ist jede Menge Zeit...
(Ich hänge zum Beispiel seit min 2 Monaten in den Datenstreams von DirectX fest).

mfg,
crazychicken

[zocker001]

Reicht einem für das Mathematik-Kapitel die 10. Klasse einer Realschule oder braucht man dafür das Gymnasium oder noch etwas höheres???

mfg
->zocker001<-

[otze]

wenn du sinus/cosinus/tangens /arsin/arccos/arctan kannst, dann wird die sache laufen...sonst wirds schwer.

[Sgt. Nukem]

Naja, ich würd' eher sagen Matrizen & Vektoren sind wichtig.

Ersteres kannten 80% der FH-Studienanfänger bei uns noch nichtmal...

Dort lernt man das aber auch alles in 2 Vorlesungen. ZACK!

[otze]

die beiden sachen werden ja erklärt. Sinus und Konsorten werden aber vorrausgesetzt...

[Sgt. Nukem]

Achso... es geht speziell um das Buch.

KK

[zocker001]

*schluck* Dann kann ich's ja gleich vergessen...

[Gleiter]

zocker001 schrieb:

*schluck* Dann kann ich's ja gleich vergessen...

Feigling. Steh auf und lerne es.

[SirLant]

Trigonmetrie ist doch sowas von einfach, das kann jeder der den Satz des Pythagoras verstanden hat

Und das bischen Matrizen- und Vektorrechnung kann man auch nicht mit dem in der
Schule vergleichen, da man hier auf ner viel einfacheren Ebene rechnet.

[WirrWar2850]

Das ist kein Problem, die Mathematik (sinus/cosinus/matrizen/vectoren/etc.) hab ich auch verstanden, obwohl ich erst in der 9. Klasse (wieder... sitzengeblieben wegen FRANZÖSISCH!) bin. Um die Mathematik geht es eigentlich auch nicht, aber in dem Buch "Spieleproggen mit DX9 und C++ in 21 Tagen" wird eben alles zusammengehängt und wie ich diese Rechnungen am PC realisiere hat er auch nicht wirklich erklärt, er hat nur die Funktionen dazu in einer extra C++ Datei geschrieben, welche man dann in das Projekt einbindet, also ist es unmöglich den selbst geschriebenen Quellcode vom Anfang bis zum Ende beizubehalten .

Außerdem bomardiert er den Leser sehr schnell mit aufwendigen Rechnungen (Kollisionserkennung) und wirklich verständlich werden die auch nicht erklärt...

Das größte Problem dabei ist aber immer noch, dass das fertige Spiel einen Joystick BENÖTIGT! Wenn das nicht so wäre, hätte ich vielleicht auch nach dem Kapitel Direct Input noch was verstanden...

MfG WirrWar2850.

[SirLant]

Ja das 21Tage Buch hat sehr viel Mathe in sich, da musst du wohl durch und bei Problemen einfach hier Fragen oder bei google suchen.

[zocker001]

Gleiter:
Ich würde ja so gern mal versuchen eine eigenes Spiel zu programmieren. Aber wenn otze schreibt:

otze schrieb:

wenn du sinus/cosinus/tangens /arsin/arccos/arctan kannst, dann wird die sache laufen...sonst wirds schwer.

und ich nicht weiß, was "tangens" oder "arsins" sind (komische Namen ), wird das doch nie etwas werden. Auserdem lern ich gerade C++ und bin ziemlich, ziemlich weit unten. Ich kann ja nicht mal eigene Klassen schreiben oder so was. Dafür hatte ich noch keine Zeit.

Bis jetzt hab ich mich immer an diese Leveleditoren gewagt und dort mal versucht, einen eigenen Level zu gestalten. Der Tomb Raider-Editor war für mich echt klasse. Hier hab ich gelernt, wie viel Aufwand in so einem Spiel der Neuzeit dahintersteckt. Allerdings war es auch ziemlich schwer, aber hich hab mich durch das Handbuch gequält. Am Ende hab ich es geschafft, einen eigenen Level zu basteln (leider etwas öde), aber mit diesen Kameras hat man tolle Dinge anstellen können. Zu diesem Zeitpunkt habe ich gesagt: "Ich will auch mal mein eigenes Spiel programmieren!!!" Ich war mir bewusst, was da alles auf mich zukommen würde, aber ich habe die Herausforderung angenommen......

Jetzt wollt ich fragen:
Soll ich das Buch von Stefan Scherfgen doch zulegen und gleichzeitig C++ lernen??? Wär das sinnvoll oder beiß ich mir da ins eigene Fleisch???

MfG,
euer (Spiele)zocker001

[SirLant]

Lern erst einmal sauberes C++, denn diese Spieleprogrammierbücher mit C++ sind wirklich das letzte,
das ist alles, aber kein sauberes C++.

[otze]

zum thema arcsin/arccos/arctan:
arcsin(sin(30))=30
arccos(cos(30))=30
arctan(tan(30))=30

sind also genau die umkehrung davon.

[zocker001]

otze:
Hä...was ist denn das
Ich blick da nicht mehr durch!!!

Ich kenn zwar "sin()" und "cos()" und so und ich weiß, dass man dafür <cmath> includieren muss, aber das da oben versteh ich überhaupt nicht.

SirLant:

SirLant schrieb:

Lern erst einmal sauberes C++, denn diese Spieleprogrammierbücher mit C++ sind wirklich das letzte,
das ist alles, aber kein sauberes C++.

Warum sind denn Spieleprogrammier-Bücher so schlecht???
Kannst du mir das vieleicht erklären.

Viel Spaß noch im Forum...
(Spiele)zocker001

[otze]

spieleprogrammier bücher sind schlecht, da sie ein C+ sind, dh eine mischung aus C und C++,und somit schlechter Stil, der code ist nicht zum abschreiben, falls man nicht wert darauflegt, von echten profis ausgelacht zu werden

nochmal zum sinus kram

ihr habt doch sicherlich mal den sinus durchgenommen oder?
wenn mand en sinus eines winkels von 30° ausrechnen will, so schreibt man sin(30), also jetzt nicht im computer programm, sodnern im matheheft.
so, nun existiert auch noch eine umkehrfunktion vom sinus, die den vom sinus ausgerechneten wert wieder umkehren kann.
dh: sin(90)=1
arcsin(1)=90
kurzschreibweise: arcsin(sin(90))=90
hoffe, nun ist es etwas klarer.

[Trienco]

otze schrieb:

spieleprogrammier bücher sind schlecht, da sie ein C+ sind, dh eine mischung aus C und C++,und somit schlechter Stil, der code ist nicht zum abschreiben, falls man nicht wert darauflegt, von echten profis ausgelacht zu werden

carmack scheint das beispiel schlechthin für furchtbaren code zu sein, ausgelacht hat ihn noch keiner. spieleprogrammierer haben da halt eine "etwas" andere mentalität als anwendungsprogrammierer und sagen sich "ich benutz oo soweit, wie es mir in den kram paßt und der rest kann mir gepflegt gestohlen bleiben". wer darauf besteht, daß das verwenden von klassen sofortigen zwang zur folge hat nur noch c++ zu verwenden und sich deswegen lieber an der formatierten ausgabe mit cout einen abbricht statt printf zu verwenden, der wird in dem beruf sicher nicht glücklich *fg*

davon abgesehen, wer legt fest, was c ist und was c++? was in c vorhanden war, wurde in c++ nicht komplett neu implementiert. sind zeiger plötzlich tabu und man sollte nur noch die c++ referenzen benutzen? funktionszeiger ignorieren und lieber ableiten bis zum erbrechen?

wenn dann noch code dazukommt, der einfach nur als beispiel einen bestimmten punkt deutlich macht, dann schenkt man sich eben vieles.

in einem opengl buch, das teilweise c++ benutzt sind immer noch malloc und free angesagt. schlimm? nicht wirklich, genau genommen erspart man sich damit sogar gleich peinliche fehler, wenn man schlampt und delete statt delete[] aufruft (speicherleck) oder umgekehrt (ziemlich sicherer crash). ändert aber nichts daran, daß man new und delete trotzdem noch für klassen braucht (sonst kann man sich konstruktor und destruktor auch halb schenken). und puristen wird halt gerne schlecht, wenn sie in ihrem geliebten sauberen c++ plötzlich ein malloc sehen. mir persönlich schnurz, ich benutze, was mir in dem moment sinnvoller scheint. genau wegen der freiheit benutze ich ja c++ und mache einen großen bogen um java ,-)

[otze]

nich schonwieder diese diskussion

Erstmal Vorweg: bis zur Entwicklung von Doom3 hat Jon Carmack nur C programmiert, und da der sourcecode von Doom3 nicht offen liegt, kann sich keiner von uns eine Meinung über seinen C++ stil bilden, um den es hier ja geht.

Eine Sprache ist mehr als nur eine ansammlung von Sprachmitteln, die man beliebig kombinieren kann. Hinter einer Sprache steckt eine Philosophie, ein Pardigma.

"ich benutz oo soweit, wie es mir in den kram paßt und der rest kann mir gepflegt gestohlen bleiben"

OO ist ein solches Pardigma, aber C++ bietet soviel mehr, dass man auch sogut wie jede andere Programmiertechnik benutzen oder zumindest nachstellen kann, und Deshalb ist C++ eine multiparadigm language. Klassen sind in C++ nicht mehr als eine weitere lösungsmöglichkeit für ein Designproblem, ein Werkzeug, mehr nicht.
Dh wer Krampfhaft versucht, in C++ reines OO zu betreiben hat eh die Sprache verfehlt,dazu ist C++ bei weitem nicht konsequent genug.
Dein kommentar über cout und printf lass ich mal aussen vor, jedem hier wird wohl klar sein, dass printf unglaublich fehleranfällig ist-im gegensatz zu cout.

Der Unterschied zwischen C und C++ sind die Sprachmittel. zwar ist in C++ 99% von dem enthalten, was C bietet, aber die neuen Sprachmittel verändern den Stil ungemein. Dh man hat nicht nur von der Syntax der beiden sprachen große unterschiede, sondern auch in der Philosophie. C++ ist unglaublich komplex, deshalb ist es auch schwer diese Sprache wirklich zu lernen(und einen standardkonformen compiler dazu zu finden ;)). Die komplexität kommt von der Flut an neuen Designmöglichkeiten. Ich könnte auf die schnelle mal 5-6 möglichkeiten nennen, ein Objekt mit einem Anderen zu verknüpfen,und jede dieser möglichkeiten kann man irgendwo gebrauchen, weil es immer ein Designproblem gibt, welches genau das braucht.
Was ich mit "C+" bezeichne ist die verwendung der neuen Sprachmittel von C++ um die programmierweise von C zu unterstützen. C+ ist C mit Klassen,dh der versuch alten C Code in gruppen zusammenzufassen,im endeffekt also eine vergewaltigung beider sprachen. Und was ist nun so schlimm daran? Ein Beispiel: im Scherfgen Buch wird ein Texturmanager Programmiert. Kern des ganzen soll eine linked list sein-die er natürlich von Hand implementiert. An der Stelle hab ich mir gedacht "typischer fall von one-liner std::list<...>..."
im weiteren Codeverlauf kamen dazu noch typische C++ Sprachelemente, und am ende hatte man Code in dem sich C Schafe und C++ Kühe fröhlich auf der selben weide tummelten, will sagen: der Code war garnichts,er war nicht gut lesbar, da der Stil nicht konsistent war(wobei ich glaube, dass wenn er sich nicht mit dem interface von den texturen und ihre verwendung hätte rumplagen müssen, ein halbwegs lesbarer C code hätte rauskommen können). Die teile funktionierten zwar zusammen, aber lesar war was anderes :D.

[Sgt. Nukem]

otze schrieb:

aber C++ bietet soviel mehr, dass man auch sogut wie jede andere Programmiertechnik benutzen oder zumindest nachstellen kann, und Deshalb ist C++ eine multiparadigm language.

Um genau zu sein OOP und Prozedurale P...

[otze]

Sgt. Nukem schrieb:

otze schrieb:

aber C++ bietet soviel mehr, dass man auch sogut wie jede andere Programmiertechnik benutzen oder zumindest nachstellen kann, und Deshalb ist C++ eine multiparadigm language.

Um genau zu sein OOP und Prozedurale P...

mehr-.-