C++ Kenntnisse für Spieleprogrammierung!

[Noboy]

Naja, ich würde sagen es ist nicht schlecht wenn man sich bei Vektoren auskennt, aber nicht unbedingt erforderlich, denn dafür gibt es die meisten Funktionen sowieso fertig.
Viel wichtiger ist meiner Meinung nach dass man sich bei den Winkelfunktionen Sin, Cos, Tan und vor allem auch den Umkehrfunktionen auskennt, denn damit muss man sich sehr oft selbst Funktionen zusammenbasteln.

mfg

[helium logged out]

Ich habe mehrere Vektorberechnungen (Richtungsvektor bei bestimmter Geschwindigkeit), Abstandsberechnungen, Wegfindung.
Bei 3D würden noch Matrixberechnungen hinzukommen.

Abstandsberechnugn ist doch nur Pytagoras. Das ist doch nicht wirklich Mathe, das ist kinderkram. Wegfindung ist hart. Aber zum glück findet man ja Texte über den A*-Algorithmus.

Bleiben Vektoren und Matrizen.

Naja, ich würde sagen es ist nicht schlecht wenn man sich bei Vektoren auskennt, aber nicht unbedingt erforderlich, denn dafür gibt es die meisten Funktionen sowieso fertig.
Viel wichtiger ist meiner Meinung nach dass man sich bei den Winkelfunktionen Sin, Cos, Tan und vor allem auch den Umkehrfunktionen auskennt, denn damit muss man sich sehr oft selbst Funktionen zusammenbasteln.

Ja, aber solche Dinge kennt doch jeder. Wie ich den Winkel zwischen mein Fahrtrichtung und der des gegners berechne oder so, ist nicht unbedingt dass, was ich als Mathematik bezeichne.

[Gast]

Mei, wie gesagt, Realschul-Kenntnisse sollte man meiner Meinung nach schon haben. Fertige Funktionen bei Vektoren... ich berechne meinen Abstand lieber selbst. Weil ich zum Beispiel aus Performancegründen die Wurzel nicht ziehe.

Ich bin jetzt nicht der 3D-Owner aber ich dafür soll man angeblich auch ein bisschen Matrix-Berechnungen beherrschen müssen.

[Helium]

Mei, wie gesagt, Realschul-Kenntnisse sollte man meiner Meinung nach schon haben. Fertige Funktionen bei Vektoren... ich berechne meinen Abstand lieber selbst. Weil ich zum Beispiel aus Performancegründen die Wurzel nicht ziehe.

Ich hab mir irgendwann ne Vektorklasse gebastelt, die bot unter anderem auch die Möglichkait das Quadrat der Entfernung zu berechnen, weils schneller geht und für vergleiche föllig ausreicht. Bei anderen Sachen reichts eben nicht, aber auch dafür bietet die Klase möglichkeiten. Ich weiß nicht, ab das jetzt das ist, was du mit vorgefertigt meinst, aber ein:

Vector position1, position2;
...
float distance = Vector_tools::distance_square(position1, position2);

ist mir lieber, als jedesmal

float distance;
{
   float temp_dist_x = position1.get_x() - position2.get_x();
   float temp_dist_y = position1.get_x() - position2.get_x();

   distance =  temp_dist_x * temp_dist_x + temp_dist_y * temp_dist_y;
}

zu schreiben.

Ich bin jetzt nicht der 3D-Owner aber ich dafür soll man angeblich auch ein bisschen Matrix-Berechnungen beherrschen müssen.

Das du 3D besitzt hätte ich dir auch nie geglaubt, da "dreidimensional" nichts ist, was man besitzen kann.

Ja der umgang mit Matrizen ist tatsächlich sehr hilfreich. Vieles lässt isch einfacher und vor allem schneller erledigen. Ebenfalls sinnvoll in diesem zusammenhang sind Quaternionen. Leider habe ich darüber nur wenig Tutorien gefunden, aber einige waren trotzdem recht hilfreich.

[Gast]

ist mir lieber, als jedesmal
float distance;
{
float temp_dist_x = position1.get_x() - position2.get_x();
float temp_dist_y = position1.get_x() - position2.get_x();

distance = temp_dis_x * temp_dist_x + temp_dist_y * temp_dist_y;
}
zu schreiben.

Na subba, ne eigene Funktion/Klasse zu schreiben hat ja nichts mit vorgefertigten Klassen zu tun. Ich rechne auch nicht jedes mal den Abstand so wie oben aus, sondern hab dafür eine Methode. Allerdings benenne ich meine Variablen nicht so hässlich

EDIT: Warte nur, bald besitze ich das 3D auch -.-

[Desire]

Optimizer schrieb:

Allerdings benenne ich meine Variablen nicht so hässlich

kennt jemand n buch übers bennen von variablen? meine sind nämlich regelmäßig ziemlich hässlich benannt

[Gast]

@ Desire

Dazu sind gute Englisch-Kenntnisse (Vokabeln) von Vorteil.
Je mehr Vokablen man kennt, desto genauer kann man durch den Namen der Variable beschreiben, was sie für einen Sinn hat.
Außerdem ist die Konvention sinnvoll, alle Variablen mit einem Kleinbuchstaben beginnen zu lassen und dann jedes weitere Nomen, das Bestandteil des Variablennamens ist, mit einem Großbuchstaben am Anfang zu schreiben:

carHeight, bottleNettoVolume

[TheTester]

also ich schreib meine variablen in deutsch hin, ich seh gar nich ein wieso ich das nicht tun sollte die sources bekommt eh kein englisch sprechender zu lesen

bye

[rapso]

Vector position1, position2;
...
float distance = Vektor_tools::distance_square(position1, position2);

CVector3 Pos1, Pos2;
...
float Dist = Pos1 * Pos2;

da man selten zwei vectoren multipliziert um sie nur zu skalieren, ist es sehr praktisch den operator*(..) zu überladen und als DotProduct zu nutzen... wozu hat man denn sonst operator überladung in c++? (da man auch selten ^ und % für vectoren nutzt, kann man eines davon als CrossProduct nutzen)

rapso->greets();

[Desire]

@tobias so mach ichs auch...trotzdem beschwert sich mein vater immer über meine namen *g+ (is informatiker)

[xroads42]

"Brauche ich C++??"
Nein. Du brauchst kein c++. Viele spiele werden in C++ programmiert, aber das heißt noch lange nicht das man in C++ muß!
Du kannst auch gerne Lisp, Haskel, C, Pascal, Fortran, Java usw. nehmen.
Wichtig ist nicht die Sprache, sondern das du die sprache beherschst, und weißt was du mit ihr machen kannst.
Für alle die oben genannten Programmiersprachen gibt es Grafiklibs ( opengl...).

"Wieviel Mathe brauche ich"?
Kommt drauf an. Wenn du das rad neu erfinden möchtest ( deine eigene Grafiklib schreiben) viel. Wenn du nur anwender von libs bist, nicht so viel. Oft reicht zu wissen was "was kommt dabei raus" wenn ich die und die Funktion aufrufe. Aber es währe nat. gut wenn man auch weiß wie diese Funktion funktioniert, um fehler zu vermeiden.
Gut wäre ein grundwissen in Linearer Algebra, trigonometrische Funktionen und ein wenig intelligenz um sich sachen über die man stolpert selbst anzueignen.

[rapso]

Tobias Dallmann schrieb:

@ Desire
Außerdem ist die Konvention sinnvoll, alle Variablen mit einem Kleinbuchstaben beginnen zu lassen und dann jedes weitere Nomen, das Bestandteil des Variablennamens ist, mit einem Großbuchstaben am Anfang zu schreiben:

und wieso ist es sinnvoll das erste Nomen klein und die restlichen gross zu schreiben? wäre eine einheitlicherere Konvention nicht besser?

rapso->greets();

[Helium]

also ich schreib meine variablen in deutsch hin, ich seh gar nich ein wieso ich das nicht tun sollte die sources bekommt eh kein englisch sprechender zu lesen

Das heißt nicht, das das bei allen so ist.

Zeig mal ein Beispiel für deine Variablenbenennung. Vielleicht finde ich die ja hässlich.

Und das verwenden von Operatoren ist natürlich vorteilhaft. Das letzte mal habe ich aber vor etwa drei Jahren Spiele programmiert. Ich hab überhaupt keine Ahnung mehr von meinem eigenen Code. Natürlich ließ sich das Punktprodukt auch mit Operatoren berechnen. * konnte auch gleichzeitig fürs Skalarprodukt verwendet werden. % war das Kreuzprodukt. Langsam erinnere ich mich. Ich müsste erstmal wieder reinkommen. Eigentlich ging mit meiner kleinen Minibibliothek alles, was man so in dem Bereich brauchte. Multiplizieren mit Matrizen zum rotieren, transformieren, ... , umrechnen von Quaternionen in Matrizen und umgekehrt, ... . Was weiß ich vielleicht sollte ichs mir nochmal angucken, bevor ich irgendwas schreibe.

[Gast]

rapso schrieb:

und wieso ist es sinnvoll das erste Nomen klein und die restlichen gross zu schreiben? wäre eine einheitlicherere Konvention nicht besser?

rapso->greets();

Das ist doch einheitlich

int eineLangeVariable;

class MeineLangeKlasse
{
};

oft bestehen ja Klassennamen nicht aus mehreren Wörtern (bei mir zumindest nicht).
Auf jeden Fall erkennt man so Variablen immer am kleinen Anfangsbuchstaben und Klassennamen am großen.
Den Unterstrich zu verwenden finde ich außerordentlich hässlich und anangenehm zu schreiben.
Mein Vorschlag für

float temp_dist_x;

wäre also

float distanceX; // Wozu das temp

Ach und wenn wir schon dabei sind...
Die Namen von Funktionen und Methoden schreibe ich immer Groß:

class MeineKlasse
{
[...]
};

MeineKlasse meineInstanz;

meineInstanz.BerechneZeitpunktsDesUrknalls();
meineInstanz.SetBla(4);

Get- und Set Methoden sollten auch immer mit Get oder Set beginnen -.-
man sieht hier übrigens ganz schön (anhand der Groß/Kleinschreibung!) dass MeineKlasse eine Klasse ist und meineInstanz ein Objekt.

So, jetzt wisst ihr alles über mich.

[rapso]

Optimizer schrieb:

Das ist doch einheitlich

int eineLangeVariable;

int EineLangeVariable; // das wäre einheitlicher

class CMeineLangeKlasse
{
};
class IMeineLangeKlasse
{
};
struct SMeineLangeKlasse
{
};

wenn du nur gross und kleinschreibung hast zu differenzierung, dann hast du viele variablen die "int","class" und "float" heißen

nein, aber mal das beispiel da, Jedes Nomen gross anfangen lassen, das finde ich besser als ne "unnütze" ausnahme einzubauen.

ein interface mit I anfangen lassen, denn es kann sein, dass man ein plugin schreibt, dann leitet man von einem interface ab, da weiß man gleich, dass das eine abstract class ist und man kommt nicht auf die versuchung IMeineKlasse& ... zu schreiben.

und S für kleine structuren für die es sich nicht lohnt eine gekapselte klasse zu erstellen mit accessorfunktionen.

bsp:

struct SLookUpTable
{
     int         m_Hash;
     float       m_SquareRoot;
}

desweiteren finde ich es sehr angenehm m_ zu schreiben für member variabeln, dann kann man auch

void CBla::Bla(float Position)
{
    m_Position  = Position;
}

schreiben, ohne sich für die eigentlich eindeutige benennung der Position etwas ausdenken zu müssen...was schreibt man statt Position?

rapso->greets();

[Gast]

wenn du nur gross und kleinschreibung hast zu differenzierung, dann hast du viele variablen die "int","class" und "float" heißen

hmmm versteh ich jetzt nicht so ganz was du meinst.

desweiteren finde ich es sehr angenehm m_ zu schreiben für member variabeln, dann kann man auch

void CBla::Bla(float Position)
{
m_Position = Position;
}

schreiben, ohne sich für die eigentlich eindeutige benennung der Position etwas ausdenken zu müssen...was schreibt man statt Position?

mein Vorschlag:

void Bla::Bla(float startPosition)   // Konstruktor, also wie wärs mit startPosition?
{
    position = startPosition;        // Das position ein Member ist, ist eigentlich offensichtlich.
// Davon abgesehen sollte man seine eigene Klasse schon kennen  ;)
}

Wie auch immer, es ist alles Geschmackssache (bis auf Unterstriche )
Das wichtigste ist, dass man seine Konvention konsequent durchhält.

[Helium]

ein interface mit I anfangen lassen, denn es kann sein, dass man ein plugin schreibt, dann leitet man von einem interface ab, da weiß man gleich, dass das eine abstract class ist und man kommt nicht auf die versuchung IMeineKlasse& ... zu schreiben.

MeineKlasse_adapter adapter;

IMeineKlasse & referenz = adapter;

Mist doch in die Versuchung gekommen.

und S für kleine structuren für die es sich nicht lohnt eine gekapselte klasse zu erstellen mit accessorfunktionen.

Was du sagen willst du verwendest S für PODs.

Konventionen hat jeder. Meine sind folgende: Wörter werden mit einem Unterstrich getrennt. Variablen und funktionen beginnen mit einem Kleinbuchstaben, Typen, egal ob Klassen Aufzählungen oder typedefs mit einem Großbuchstaben. Makros werden komplett groß geschreiben. Member werden durch ein m_ als Präfix markiert. Abstrakte Klassen beginnen mit einem I. für PODs gibts keine gesonderete Kennung, da Sie bei mir nur als verschachtelte Klasse vorkommen. Sicherlich habe ich noch irgendwas vergessen, aber das ist jetzt nicht sowichtig.

float distanceX; // Wozu das temp

Ganz einfach, weil es eine temporäre Variable ist, die nur kurz existiert (siehe den Kleinen Sie umgebenden Block) und nach Möglichkeit nach der nächsten Refaktorisierung verschwindet.

eine_lange_Variable kann ich wesentlich besser lesen als eineLangeVariable. Und außerdem werden bei dir Adjektive plötzlich groß geschrieben.

[Gast]

Zitat:
float distanceX; // Wozu das temp

Ganz einfach, weil es eine temporäre Variable ist, die nur kurz existiert (siehe den Kleinen Sie umgebenden Block) und nach Möglichkeit nach der nächsten Refaktorisierung verschwindet.

eine_lange_Variable kann ich wesentlich besser lesen als eineLangeVariable. Und außerdem werden bei dir Adjektive plötzlich groß geschrieben.

Wow, es ist eine Variable, die nur kurz existiert. Respekt. Das ist eine Erkenntnis, für die ich kein temp brauche, um sie innerhalb einer halben Millisekunde zu machen. Vor allem, wenn die Variable in einer Funktion definiert ist, die 5 Zeilen lang ist.
Und unwichtig ist es obendrein noch.

Adjektive werden großgeschrieben? Super, was hat Grammatik beim Programmieren verloren ;((
Sag bloß, du schreibst Substantive konsequent groß und Adjektive konsequent klein. Das ist auch mal ne nette Konvention.

class meine_kleine_Klasse_fuer_Wegpunkte

Gruß
Optimizer

EDIT:
Ja, du kannst eineLangeVariable schlechter lesen. Aber das liegt an der Schriftart...

int eineLangeVariable

Und es ist wesentlich angenehmer zu schreiben.

[Helium]

Wow, es ist eine Variable, die nur kurz existiert. Respekt. Das ist eine Erkenntnis, für die ich kein temp brauche, um sie innerhalb einer halben Millisekunde zu machen. Vor allem, wenn die Variable in einer Funktion definiert ist, die 5 Zeilen lang ist.
Und unwichtig ist es obendrein noch.

Hallo, die Variable existiert bei mir sowieso nicht; wieso also über den Namen steriten?

Adjektive werden großgeschrieben? Super, was hat Grammatik beim Programmieren verloren ;((
Sag bloß, du schreibst Substantive konsequent groß und Adjektive konsequent klein. Das ist auch mal ne nette Konvention.

class meine_kleine_Klasse_fuer_Wegpunkte

Bist auf das erste Wort in einem Bezeichner (siehe vorheriges Post) ist das tatsächlich so.

Ja, du kannst eineLangeVariable schlechter lesen. Aber das liegt an der Schriftart...
Und es ist wesentlich angenehmer zu schreiben.

Das ist Gewöhnungssache.

Aber wir sollten entweder wieder zum Thema zurückkommen oder den Thread endlich beenden.

[rapso]

Helium schrieb:

ein interface mit I anfangen lassen, denn es kann sein, dass man ein plugin schreibt, dann leitet man von einem interface ab, da weiß man gleich, dass das eine abstract class ist und man kommt nicht auf die versuchung IMeineKlasse& ... zu schreiben.

MeineKlasse_adapter adapter;

IMeineKlasse & referenz = adapter;

Mist doch in die Versuchung gekommen.

da interfaces nie objekte sondern nur pointer sein können und du dementprechend pointer auf eine referenz legen möchtest, verstößt du gegen die konvetion, dass referenzen nicht NULL sein dürfen, was beim Interfacepointer durchaus passieren kann. (es gibt ja kein interface objekt, sonst wäre es ja kein interface mehr, sondern eine ganz normale class, das objekt definiert durch die class).

das referenzen nicht NULL sein dürfen hab ich mir nicht ausgedacht, c++ standard ist schuld

rapso->greets();