spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"defaultplayer"«

und das mit DX 10/10.1/11 EA etc. zu ueberlassen

Zitat

Manche verstehen es wohl immernoch nicht, dass EA nur ein Publisher ist.

Aber ich bin eigentlich auch dafür, dass beim nächsten Buch DirectX9 behandelt wird.

EA kauft die Spiele aber von Profis, welche die neuen DX Versionen verwenden sollten :p

Edit: Sry Abrexxes is ja aber nur ne antwort, hab dein Post erst nacher gelesen

Zitat von »"SirForce"«

Mich würde spontan echt am meisten Karakteranimation interessieren.

Genau meine Meinung.
Ja ich weiß, dass das ein fortgeschrittenes Thema ist, aber das war meiner Meinung nach das einzig Wichtige, das im letzten Buch gefehlt hat.

Karakter..? Haben die was mit Kakteen zu tun?

Zitat von »"Beneroth"«

Karakter..? Haben die was mit Kakteen zu tun?

Ich glaub er meinte Charaktere
Thema:Charakteranimation,Skinning,Bone-Animation....

schon klar

Ob DX9, 10, 10.1, 11, 12, 13 ,14 ,15 spielt finde ich keine große Rolle.

Nicht die DirectX Version macht Spaß. Das Spiel macht Spaß.
Alles andere sind Angeberein, wer die beste Grafikkarte hat.
Sicher bekommt man einige tolle Grafik-Effekte mit einer aktuellen DX-Version hin. Geometrie-Shader aus DX10, Tesselation mit DX11. Und so weiter. Realtime-Raytracing wird in einigen Jahren sicher den Rasterizer ablösen.

Wie schon erwähnt, schaffen es Hobby-Entwickler schon kaum DX8 voll auszureizen.
Vista hat eh kaum einer. 7 wird da schon beliebter.

Aber die, die noch XP haben würden da schon am Arsc* sein. Und das sind nicht wenige.

Meine Vorschläge wären:
Direct3D 9, wie im ersten Buch. Einmal aus Gründen von Kompatibilität zu XP. Zum anderen könnte man ja vorausschauend für kommende Versionen schon mal die FFP durch eigene Shader ersetzten.

Das erste Buch könnte man als eBook auf CD dazugeben und Teile davon als Grundlage verwenden. Beispielsweise kann man sich so das Kapitel über Vektoren und Matrizen schenken. Einfach Siehe Erstes Buch auf CD Kapitel 2. Damit kann man nehmlich gleich zu fortgeschrittenen Themen übergehen.

Fortgeschrittene Themen behandeln wie Charakteranimation, ShadowMapping und PostProcessing.

"leichte" Fremd-Libs benutzen wie TinyXML (bitte tu uns allen den Gefallen und verzichte auf diese INIs).

Als Spiel finde ich die Idee mit den Panzern nicht schlecht. Bitte keinen Weltraum-Shooter und keinen Ego-Shooter. Unterwasser lässt einiges zu... (ich plane schon was eigenes )

Wieder ein Kapitel über "Vorausschauendes": Darunter Netzwerk/Multiplayer: Ein paar Tipps und Adressen geben.

Ich hoffe David findet die Zeit das Buch zu schreiben. Auch wenn andere behaupten können "Ich zeige euch, wie man mit DX11 programmiert", soll David stolz sagen können "Ich zeige euch, wie man Spiele programmiert".

Ehmm. Ich denke nicht, dass das der Sinn des Buches ist.

In erster Linie gehts in dem Buch (wie auch im letzten) darum einem die grafische Programmierung mit der gegebenen Technik (Directx10, wahrscheinlich wirds aber eh DX11) nahe zu bringen und nicht darum, wie man Spiele programmiert, weil das ist grundsätzlich bereits genug diskutiert, weil das ja eher etwas allgemeines ist.

Ich z.B habe im ersten Buch die DX spezifischen Sachen durchgelesen und die Spiele hauptsächlich durchgeblättert.

Meine Wünsche wären Folgende:

1.
Ich finde es grundsätzlich gut, wie Dinge in dem Buch erklärt sind.
Sachen, die zu grundlegende Kenntnisse erfordern, werden häufig ausgelassen.
Bsp: Warum werden Richtungsvektoren mit der invertierten, transponierten Matrix multipliziert?
-Es wäre schön, wenn man eine Infobox für Fortgeschrittene hätte, die diese Sache etwas ausführlicher beschreibt.

2.
Das Buch beschreibt stark vereinfachte Themen, was beispielsweise Interpolation angeht. Deshalb gehe ich davon aus, dass der Code absichtlich so ist, wie er da steht. Es geht um die auf Seite 85f beschriebene Methode:
TRIBASE_API tbVector3 tbVectorTransformNormal (....){...};

Das ist ein super Beispiel dafür, dass man nicht immer alles irgendwelchen Funktionen anvertrauen sollte. Was ich meine:
Es wird zunächst eine Invertierte Matrix berechnet, die anschließend transponiert wird. Man merke sich, dass hier 2 geschachtelte Funktionsaufrufe stattfinden. Wenn man allerdings nur invertiert und die Multiplikation, die ja eh von Hand ausgeführt wird, ein bisschen abändert, kann man sich den Transponier-Aufruf komplett schenken.

Man tausche einfach alle mij durch mji aus.. tadaa. Ich denke, es ist unnötig zu erwähnen, dass Funktionsaufrufe Zeit kosten. Das wäre ein gutes Beispiel für Optimierung on the fly. (Wird an anderer Stelle auch gemacht: siehe tbVector3Angle(...) . Seite 60)

3. Ich bin mir vollkommen darüber bewusst, dass es Ansichtssache ist, aber ich gehe auch davon aus, dass Matrixmultiplikation andersherum stattfinden sollte. Soll heißen: Matrix * Vector und nicht Vector * Matrix
Begründung: Ich weiß, dass beides das gleiche ist und es wird auch in der Regel beides gelehrt, ABER es wird an Universitäten meistens die "Matrix * Vector"-Schreibweise benutzt. Es wäre für viele einfach viel intuitiver, denke ich.

Zitat von »"Brainsmith"«

Bsp: Warum werden Richtungsvektoren mit der invertierten, transponierten Matrix multipliziert?
-Es wäre schön, wenn man eine Infobox für Fortgeschrittene hätte, die diese Sache etwas ausführlicher beschreibt.

Das kann ich dir schnell beantworten, hab ich hier im letzten Beitrag mal erklärt:

https://www.spieleprogrammierer.de/phpBB2/viewtopic.php?t=6463