spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich möchte mal noch die Gelegenheit nutzen und ein bisschen über Vector2D und Bitset2D schreiben.

Vector2D ist eine template Klasse, die einen beliebigen Typ aufnehmen kann, also ganz so wie ein normaler std::vector. Anders als es vll viele Anfänger machen, ist intern ebenfalls nur ein großer std::vector enthalten, statt eben eines doppel Konstrukts wie std::vector<std::vector<T>>. Dadurch dürften Operationen, die die Größe verändern, deutlich schneller ausfallen, als in der anderen Variante, da die Größe einmal gesetzt wird und dann die Daten intern nur gemoved werden, statt durch jede einzelne Reihe zu iterieren und einzeln zu vergrößern/verkleinern.
Zusätzlich gibt die Klasse alle möglichen Iterator funtionen (begin, end, rbegin, rend, ...) nach außen weiter und ermöglicht so eine einfache Nutzung aller STL algorithm functionen.

Die Klasse Bitset2D ist abgeleitet von Vector2D<bool>. Da std::vector<bool> spezialisiert ist und jeder index einem bit entspricht, ist es auch sehr sparsam. Auch hier können alle STL Funktionen angewandt werden.

Den Code dafür findet ihr hier:

https://github.com/anti-freak/SimpleLib/…eLib/Vector2D.h
https://github.com/anti-freak/SimpleLib/…eLib/Bitset2D.h

Eine komplette Dokumentation der beiden Klassen findet ihr hier:
http://doc.simple-world.org/group___container.html

Kritik ist herzlich willkommen

mfg

Oi, danke. Habe ich erst neulich verschoben. Danke

Guten Tag,
hier mal eine kleine Wasserstandsmeldung zum Fortschritt und auch einiger Änderungen.

Der Geometry Part ist noch voll in Arbeit. Leider bin ich nicht konsequent genug mit den Git branches, deswegen ist da schon vieles wieder in master rein gerutscht... Nunja, war nicht beabsichtigt und da habe ich auch noch eine Menge Arbeit vor mir!

Den Vector2D (und gleichzeitig auch das Bitset2D) habe ich nochmal angepasst und stark verbessert. Es wurden ein paar Bugs entfernt und es gibt ab sofort RowModels und ColumnModels. Diese Objekte verweisen auf eine Spalte/Reihe des Vector2D und bieten direkten Zugriff, oder aber auch Iteratoren die mit der Standardbibliothek genutzt werden können. D.h. range based loops über eine Spalte/Reihe ist nun sehr einfach möglich.
Die Iteratoren der Models sind Marke selfmade (erben aber vor std::iterator), aber extrem nah an die STL Iteratoren angeleht. D.h. sie haben ihre Checks lediglich im Debug Modus, sodass der overhead ziemlich gering sein sollte.

Vll hat ja jemand Interesse daran, sich das Ganze mal ein wenig näher anzuschauen.
Im Übrigen könnt ihr meinen Blog (manche haben es schon gefunden) in meiner Signatur finden. Freue mich über jeden Besucher

mfg

So, ich habe mal wieder einen recht großen Teil aktualisiert und erweitert.

Vorweg: Ich habe nicht den Anspruch eine hoch optimierte Bibliothek zu erzeugen, aber sie soll die Dinge, die sie anbietet gewissenhaft ordentlich machen. Grundlegend sind das alltägliche Dinge wie Überschneidungen oder anderes.

Der geometry Namespace arbeitet jetzt wunderbar zusammen. Er gliedert sich wie folgt auf:

Die absolute Basisklasse ist Shape. Sie stellt eine absolut einfache Form dar z.B. LineSegment. Ich wollte "Point" auch davon ableiten, hat sich aber als etwas unzweckmäßig herausgestellt, deswegen habe ich davon abgesehen.
Die nächste Stufe wäre dann die Area, also Formen, die eine Fläche haben (Kreis, Polygon). Davon leiten sich wiederum Circle und Polygon ab. Polygon ist ein weiteres Interface für Formen mit Ecken und Circle sollte klar sein.

Als fertiges Polygon existiert bisher nur das Rectangle, wird sich aber noch ändern.
Die einzelnen Klassen bieten Methoden zum Prüfen an (intersects, contains, overlaps). Ich bin gerade dabei die calculateIntersections für alles zu erarbeiten.


Vll mag sich der ein oder andere das Ganze mal ein wenig genauer anschauen und ein wenig Kritik da lassen

dokomentation
Source

So, nachdem ich nun den letzten geometry namespace mal in Aktion erleben konnte (baue gerade an einem kleinen Gameserver), war ich von der performance ein wenig enttäuscht. Das hat mich dann zu dem Entschluss gebracht, das ganze nochmal komplett neu zu designen und diesmal hoffentlich in eine finale Form zu bringen
Es passt daher eigentlich ganz gut, dass der letzte Eintrag hier auch über den geometry namespace handelt, aber eben in seiner alten Form.

Die neue Philosophie ist nun das templating statt der Polymorphie. Ich bin zu dem Schluss gekommen, dass Polymorphe Formen und Flächen ja ganz schön und gut sind (hat sich super handlen lassen) aber es praktisch einfach eine Ebene zu früh für die Polymorphie ist. Wir befinden uns hier auf einer Ebene, auf der es noch sehr auf Geschwindigkeit und Optimierung an kommt und dort hat sich die alte Herangehensweise als nicht optimal herausgestellt. Ich will hier nicht sagen, dass es grundsätzlich eine schlechte Idee ist, Polymorphe Flächen zu nutzen, allerdings sollte das eben durch entsprechende Wrapper Klassen erreicht werden und nicht schon an der Wurzel so funktionieren.

Soweit so gut:

Die beiden Klassen Point und Size sind nahezu unberührt geblieben und 1:1 übernommen worden. Die Klasse LineSegmen ist nun auch keine derived Class mehr, genauso die beiden Klassen Rectangle und Circle (ja, Triangle fehlt immer noch...).
Statt nun aber das Interface aller Klassen mit Methoden - wie z.B. contains, intersects oder overlaps - vollzumüllen, habe ich mich für ein externes handling dieser Algorithmen entschieden. D.h. der geometry namespace stellt verschiedene freie template Funktionen zur Verfügung (contains, intersects, overlaps...) die, je nach Funktionsweise, nur Flächen (type trait "IsArea") oder sonstige Objekte entgegen nimmt. D.h. meine gewünschte Funktionalität verschiedene Flächen miteinander kombinieren zu können ist weiterhin erhalten geblieben, lediglich die Syntax hat sich ein klein wenig verändert.

Ich habe dann auch einen kleinen Test laufen lassen, der mir gezeigt hat, dass die template Variante in etwa 40% performanter ist als die polymorphe (bei einer kleinen Liste von 100 Objekten die gegenseitig auf overlaps untersucht wurden).

Das war es dann auch schon wieder von meiner Front. Ich beabsichtige jetzt tatsächlich den namespace so beizubehalten

Dokumentation
Source

PS: Ich meine mit final natürlich nicht, dass ich komplett fertig bin, sondern dass das System, wie es jetzt ist, so bleiben soll. Es fehlen noch die ein oder anderen Kombinationen und auch Funktionen.