spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wieso etwas erweitern wenn man selbst Träume verwirklichen kann?

Naja jedem das seine.

Das ist mein enum:


- Patrick, der nicht umbedingt ein Buch braucht um einen Traum zu verwirklichen, denn google reicht

Jaja, Patrick, der der selber ein Buch schreibt Schöne Grüsse an den Meista :huhu: David natürlich auch :huhu:

mfg afogel

Zitat von »"Patrick"«

buch_schreiben = 2

Was soll das denn für ein Buch werden?

afogel
Thx, leider kann ich diese Woche net schreiben (Codingfeindliche Freundin ;D) aber geht voran wenn ich wieder daheim bin *ggg*

kaid
Themen die behandelt werden (grob aufgelistet)
Kapitel 1
- Warum C++
- Wie ein Compiler Funktioniert und seine Diener (PräCompiler)
- Grundlagen von C++ (Variablen, Funktionen, Operationen)
- Klassen
- Listen
- Namespaces
- Exceptions
- Templates
- die STL
- Der PräCompiler
usw.

Kapitel 2
- Grundlagen der Windowsprogrammierung
- UNICODE
- Kapselung einer Win32-API Anwendung
- GDI Gekapselt
usw.

Kapitel 3:
- Grundaufbau eines Spieles
- Planung eines Spieles
- ein Logsystem und Debughilfen
- diverse Hilfsfunktionen
- Mousemanger, Keyboardmanager, Joystickmanager, Soundmanager (alles ohne DX und zusatzlibs, nur WinAPI)

Kapitel 4:
- 3D mathematik grundlagen
- Mathehilfsstrukuren wie z.B. matrix, vector, plane usw.
- Mathehilfsfunktionen selbstgemacht auf templatebasis z.B. abs, max, min, pow, uvm.

Kapitel 5:
- Was OpenGL ist
- Warum OpenGL
- Gegenüberstellung OpenGL vs. Direct3D (Nicht DirectX!)
- Ablauf von OpenGL
- initialisierung von OpenGL (gekapselt)
- Herunterfahren von OpenGL
- Primitiven auf dem Monitor)

Kapitel 6:
- Texturen und Materialien
- ein Texturmanager (laden von TGA und BMP ohne Hilfsfunktionen von Windows oder libs)
- Rendern von Texturen
- Bau eines kleinen 2D Arcardespieles (Bin momentan an dem Punkt wo ich überlege: PacMan oder SideScroller)

Kapitel 7:
- Lichtobjekte
- Weiterführung von der 3D Mathematik (Kamera usw.)
- usw.

Kapitel 8:
- Bau eines 3D Spieles (SpaceSim oder Outdoor mit Highmap und Octree, je nachdem)
- Special Effects (Billboards und primitvie animationen)

usw.

Es wird strickt nach OOP gehandelt, auch in den Spielen z.B. das Factory Plattern.

Jeder Manager wird von einem Interface abgeleitet und in einen globalen Manager für Manager gestopft, dadurch bleibt die Engine in sachen Manager problemlos erweiterbar.

Die Engine wird zwar in die exe hinein compiliert (also keine DLL) aber benutzt einen eigenen Namespace und wird möglichst portabel gehandhabt (falls man auf ein anderes OS umsetzen will).

also das ist nur ein grober Überblick

- Patrick

p.s.: Fertig wird es sehr warscheinlich mitte nächsten Jahres, muss erstmal nen guten Verlag finden

Also ein rein OO Buch von einem deutschen "Autor" würde ich begrüßen. Weil meiner Ansicht nach gibt es im Moment auf dem deutschen Buchmarkt fast nur "Müll". Um gleich vor weg zu nehmen, Davids Buch ist in vielerlei Hinsicht gut, aber der Codestil ist leider nicht der Beste. Eben wegen dem schlechten OOD.

Was mich interessieren würde ist, möchtest du auch das man jeden scheiß selber programmiert, anstatt z.B. OGL oder D3D Funktionen zu nutzen?

Ich meine, vergleicht mal euer bestes Buch von einem deutschen Autor und zwei englische, dann werden ihr wissen was ich damit meine.

Weil das nervt mich ziemlich an deutschen Autoren.

Also vom Aufbau hört sich deins interessant an und wenn du es wirklich in rein OOD schreibst und nicht immer das Rad neu erfinden willst, dann werd ich sicher einen Blick riskieren. Schade das es noch so lange dauern wird.

Nun ja, es soll halt zwar nicht immer "Das Rad neu Erfunden" werden, aber es soll auch nicht gesagt, werden "Diese Funktion macht das und Fertig", drum wird man später entscheiden können, ob man jetzt z.B. glTranslatef benutzt oder eine eigene implementierung aus der matrixklasse

Kurz: Ich zeige auch wie man das fertige äquivalent (falls es diese gibt) zu der selbst gecodeten Funktion benutzen kann.

Oder sowas wie gluPerspective oder glOrtho werden jedoch selbst gecodet, aus dem ganz einfachen Grund damit der Anfänger (Der vorher noch nie gecodet hat, deshalb auch die C++ Einführung) weiß, was da passiert.

Kurz: Es wird ein Anfängerbuch und man soll mal "hinter die kulissen" sehen können.

Weiterer Vorteil ist natürlich, das man diese Funktionen später mit SIMD Optimieren kann und man sieht wie OOP Funktioniert Viele denken "Ah Ich hab ne klasse, also alles OOP!" dem jedoch nicht so ist

Nebenbei: Bei OpenGL muss man sog. fast alles selber coden Es gibt kein D3DX für Hilfsfunktionen, das hat jedoch nicht nur Nachteile sondern auch Vorteile

Hat alles Vor- und Nachteile, ich bin jemand der halt lieber alles selber codet, damit ich später sehen kann WAS da passiert Und ich denke, neulinge im Coding möchten das auch gerne sehen

- Patrick

Hi, nun ja im Prinzip ist das schon richtig. Man kann sich natürlich auch den Code der Funktionen einfach laden und ihn studieren, dann weiss man quasi auch was passiert. Aber OK, dass muss wohl jeder selbst entscheiden.

Eine Frage, hast du schon einmal ein englischen Buch über Game Development gelesen?
Ich finde es immer sehr schön, wenn jeder denkt, ach was Microsoft kann, dass kann ich schon lange und noch viel besser. Deshalb nutzen viele auch keine STL und coden lieber ihr eigene verkettete Liste.
Ich weiss nicht ob du auch zu den Anti-STLer gehörst, aber ich verstehe einfach nicht wie man von sich glauben kann, dass man besseren oder nur annähernd gleich optimierten Code wie in der STL oder in einer D3DX- Funktion schreiben kann.
Bestes Beispiel die Zerbst Bücher. Lieber alles selbst coden und weniger wichtige Sachen vermitteln wie OOD und am Ende hat man einfach nichts gescheides gelernt. Höchstens wie man seinen Code nicht entwerfen sollte und wie man schlechten Code programmiert.
Aber zumindestens ein Ansatz wird bei dir ja schon mal besser.

Also ich hoffe du machst wenigstens eins. Zeige wie man es selber machen kann, aber zeige auch wie man es nicht selber machen kann. Weil Beispielsweise in den Zerbst Büchern kommt keine Alternative zu dem "eigenen" Code und das finde ich ziemlich übel.

Mit OpenGL kenn ich mich nicht so gut aus, nur Grundlagen und weiss daher nicht in wie fern man da schon Code bekommt.

Aber "Man muss das Rad nicht immer neu erfinden" sollte man sich immer im Hinterkopf behalten, dadurch spart man Zeit und schreib auch gleich besseren Code.

Ach ja, wenn man natürlich wirklich die Fähigkeit hat den Code selbst zu optimieren, dann ist das eine andere Geschichte. Aber da es ja, wie die meisten, ein Anfängerbuch ist, glaube ich nicht das diese Fähigkeit nur annähernd da sein wird.

Natürlich wird es die nur annähernd geben, aber es ist möglich

Nun ja, bei OpenGL muss man wohl oder übel ALLES selber coden, von einer Laderoutine für BMP bis hin zu Mathefunktionen.

Naja das mit der STL: Ich bin totaler STL fan, ich geb nur 1 beispiel in den Buch wie man eine eigene Verkettete Liste codet damit man versteht wie z.B. eine std::list funktioniert. Später wird nur STL benutzt. Jedoch bevor ich jemanden hinklatsche "benutzte dies und das", mache ich erst einen schritt zurück erkläre was da passiert und dann wird es erst benutzt

D3DX oder sowas ähnliches gibt es in OpenGL nicht, zwar gibt es GLUT und GLAUX, aber die kann man regelrecht in die Tonne kloppen und sind gegen eine eigenimplementierung einfach dreck und lamarschig ;D

Ich hoffe ich konnte paar sachen klären!

- Patrick, der nun schlafen geht ;D

Ja klar.

Ich bin auf jeden Fall gespannt auf dein Werk.
Ich finde es auch gut, dass du OpenGL behandelst, weil davon gibt es doch sehr wenig Bücher.

Also viel Erfolg von meiner Seite!