spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich hab mir auch eine Math-Lib geschrieben und habe da gleich mal ein paar Ratschläge für dich:
- Mach ruhig einen namespace Math oder so, weil wenn es mal größer wird, kann man besser zuordnen.
- Die Membervariablen, wie x,y und z bei Vektoren sollten public sein. So erparst du dir ellenlange unübersichtliche get und set Aufrufe.
- Teste und kontrolliere, was das Zeug hält! Sonst gibt es nur schlimme Erwachen.
- Missbrauche Konstruktoren nicht für exotische Konstruktionen. Mach dir lieber ein paar Funktionen wie CreateFrom... Zum Beispiel kann man Geraden aus 2 Punkten oder aus einem Punk und einer Richtung konstruieren. Beides sind Vektoren, damit kommt der Compiler durcheinander, denn er weiß ja nicht, was du meinst.
- Wenn du VC++ verwendest, dann lass den Code für SSE2 (oder was besseres) automatisch optimieren. Der VC++ Compiler kann das besser als jeder Assembler-Performance-Junky
- Verwende für mehr Performance Inline-Funktionen (Auch dem Compiler bescheid sage, dass er inlinen soll!)
- Schau dir mal fertige Libs an, damit du dich etwas orientieren kannst, was deine so alles können sollte.
- Wenn du APIs mit fremden Math-Libs benutzen solltest, dann mach deine Lib so kompatibel wie möglich. -> Copy-Konstruktoren, Casts

Ich sag dir gleich, dass du da etwas länger daran sitzen wirst. Gerade Quaternionen haben es in sich (falls du die überhaupt willst).
Schau dir mal fertige Libs an, damit du dich etwas orientieren kannst, was deine so alles können sollte.

Viel Spaß!

Weis jetzt zwar nicht was an quaternionen kompliziert sein soll, aber nun gut. Sollten jedoch auch berücksichtigt werden und somit implementiert werden.

Ansonsten kann ich mit deinen anderen Punkte mehr oder weniger übereinstimmen.
Die mathematischen Instruktionen von DirectX nachmachen sollte aber schon eine ziemlich gute Übung sein Wobei ich sagen muss das xna math mit dem befehl _XM_SSE_INTRINSICS_ absolute schnell ist.

Zitat von »Male«

EDIT: Ich hab mir mal die Orge Engine runtergeladen und schau mir mal an wie sie die Mathe Sachen umgesetzt haben

Ich finde nicht gut. Ogre::Vector3 packt alles in eine Klasse, wo freie Funktionen viel sinnvoller wären. Ganz besonders trifft das auf Dinge wie operator+ oder dotProduct() zu. Daran würde ich mir nicht unbedingt ein Beispiel nehmen.

Ich finde, dass das Geschmackssache ist. Also ich mag es lieber Funktionen irgendwelcher Klassen aufzurufen als wenn da irgendwo im Namespace welche rumfliegen. Ich finde dotProduct() ist für mich eben Teil der Vector-Klasse. Dafür beiße ich eben in dne sauren Apfel, dass ich keine freien Funktionen habe. Stört mich aber herzlich wenig.

Auf eine Art hat ist es bestimmt Geschmackssache, aber der Vorteil an freien Funktionen ist halt, dass sie ja unabhängig von der Klasse sind. Z.b möchtest du, bei einer völlig allgemeinen Vektorklasse einmal ein anderes Skalarprodukt, als das euklidische haben und da wäre es hinderlich, wenn die Klasse bereits eines in sich verinnerlicht.

Zitat von »Fred«

Ich finde, dass das Geschmackssache ist. Also ich mag es lieber Funktionen irgendwelcher Klassen aufzurufen als wenn da irgendwo im Namespace welche rumfliegen. Ich finde dotProduct() ist für mich eben Teil der Vector-Klasse. Dafür beiße ich eben in dne sauren Apfel, dass ich keine freien Funktionen habe. Stört mich aber herzlich wenig.

Ja, es hat sicher auch mit Geschmackssache zu tun. Aber nicht nur.

Unter Geschmackssache fällt zum Beispiel, dass ich a.dotProduct(b) hässlicher finde als dotProduct(a,b), weil es eine nicht vorhandene Asymmetrie suggeriert.

Probleme gibt es, weil dadurch tatsächlich eine Asymmetrie entsteht. Während das rechte Objekt durch implizite Konvertierungen zustande kommen kann, ist das beim linken nicht möglich. Sagen wir, ich hätte zusätzlich eine eigene Vektorklasse, aus irgendeinem Grund.

Bei dotProduct() sieht es natürlich gleich aus. Dazu kommt, dass man mit freien Funktionen viel flexibler ist, weil man Überladung nutzen und andere Typen einbeziehen kann. Warum wird darauf verzichtet? Syntax? Oder weil das "objektorientierter" ist? Besonders durchdacht kommt mir das jetzt nicht vor. Man muss ja nicht Java in C++ betreiben.

Ein weiterer Punkt, der mir an Ogre::Vector3 nicht gefällt, ist die zu grosse Schnittstelle (und der damit verbundene Aufgabenbereich). Man hat operator[], ptr() und die öffentlichen Variablen x,y,z zur Verfügung, um auf Koordinaten zuzugreifen. Oder makeFloor() und makeCeil(), das sind meiner Ansicht nach einfach nicht Funktionen, die in eine Vektorklasse gehören. Oder die Division durch einen anderen Vektor, zu der die Dokumentation nicht mal etwas Brauchbares sagt (es handelt sich um elementweise Division, analog Multiplikation). Es gibt viele weitere Beispiele.

Gleiches gilt für operator< und operator>, für welche bei Vektoren keine intuitive Konvention besteht. operator<= und operator>= existieren übrigens nicht. Man könnte denken, operator< sei bereitgestellt, um Sortierungen in assoziativen Containern zu ermöglichen. Doch die Implementierung erfüllt das Strict-Weak-Ordering-Kriterium nicht, man kann also kein std::set<Ogre::Vector3> ohne undefiniertes Verhalten haben. Ogre::Vector3 bietet ein schönes Beispiel dafür, wie Operatorüberladung nicht aussehen sollte.

Doch damit nicht genug. Die Implementierung ist auch etwas speziell und verlässt sich auf Dinge, die nicht vom Standard abgedeckt sind. Falls man das für Performance tut, könnte man unerwünschte Effekte wenigstens mit Assertions absichern. Aber einfach so tun, als könnte damit nie ein Problem entstehen, scheint mir keine gute Lösung zu sein.

Im Grossen und Ganzen könnte man etliche Dinge besser machen. Auch wenn die Ogre-Entwickler so von Objektorientierung schwärmen, haben sie diese teilweise fragwürdig umgesetzt. Ich würde mich für eine eigene Implementierung jedenfalls nicht an Ogre::Vector3 orientieren.

Ich denke, dass eine Vektor-Klasse in der Hauptsache funktionieren muss, wobei der Code natürlich recht gut lesbar sein muss, der Rest ist Geschmackssache.

Das ist aber die falsche Einstellung. Man sollte sich schon auch über das Design Gedanken machen, auch wenn es direkt keine Auswirkung auf das Verhalten des Programmes hat. Übersichtlichkeit, Wartbarkeit, Erweiterbarkeit usw. sind keine unwesentliche Punkte.