Wahl des richtigen Containers für dynamisches 2D-Array
-
Grafikfetischist schrieb:
Auch wenn es sich zuerst komisch anhört. Es könnte wirklich besser sein die Chunks vollständig in jedem Frame mit dem Genarator und den (wenigen) Änderungsinformationen neu zu berechnen.
Wenn dies vollständig in der Grafikkarte pssiert könnte es wirklich schneller sein.Es gibt in meinem Spiel nicht "den Algorithmus". Generierungsalgorithmen können über shared libraries hinzugefügt und entfernt werden. Auch den Default-Algo werde ich als sharedlib erstellen. Damit wird es wohl nicht möglich sein, diese auf der Graka laufen zu lassen.
Patrickssj6 schrieb:
Die Chunks sind 32x32xHöheDerWelt(128)
Fast. 16x16x128
Patrickssj6 schrieb:
Wenn man nun sich zu einem Ort teleportiert wo keine Chunks geladen wurden, dann werden von 0,0 bis 32,32 Chunks geladen...das sieht natürlich blöd aus und vor allem, ist das erneut ineffizient.
Das kann ich mir nicht vorstellen. Ich habe mich schon mal zum testen an den Rand der Map geportet, wo durch Rundungsfehler bei Fließkommazahlen die Physik etwas rumspinnt. Die Map war sofort da. Selbst wenn, ich mache das nicht so.
-
Patrickssj6 schrieb:
Dabei wird Leere auch mit abgespeichert.
Dass die Leere mit abgespeichert wird, ist der Sinn und macht das Ganze überhaupt erst möglich. Denn sonst müsstest du für jeden Block die Position speichern.
-
cooky451 schrieb:
Patrickssj6 schrieb:
Dabei wird Leere auch mit abgespeichert.
Dass die Leere mit abgespeichert wird, ist der Sinn und macht das Ganze überhaupt erst möglich. Denn sonst müsstest du für jeden Block die Position speichern.
Naja, ist jetzt Auslegungssache was man unter "Leere mit abspeichern" versteht.
---
Ich meinte es auf jeden Fall so (die Sache mit der Höhe ignoriere ich mal):
Basis-Block: hält z.B. 8x8 Elemente. Kann nicht weiter unterteilt werden. Ob für "leere" Elemente auch *sämtliche* Daten mit abgespeichert werden, oder bestimmte Dinge nicht (die in den "belegten" Elementen dann über Zeiger referenziert werden) ist (mir) dabei erstmal egal.
Wie genau der Basis-Block seine Elemente hält (also ob über Zeiger oder direkt als fixed-size Array-Member mit allen nötigen Daten) müsste man sich dann noch überlegen, bzw. etwas experimentieren.L2-Block: hält 16x16 Basis-Blöcke über ein fixed Size 2D Zeiger-Array. In dem 2D Zeiger-Array können Nullpointer drinstehen - d.h. dann dass der ganze Basis-Block der dort wäre "leer" ist, und daher weggelassen wurde.
L3-Block: hält 16x16 L2-Blöcke - nach dem gleichen Schema wie der L2-Block seine Basis-Blöcke verwaltet.
Das ganze kann man quasi beliebig weit fortsetzen, da ab einem bestimmten Level eh immer nur ein "Kind-Block" non-null ist.
Ich bin mir auch nicht 100% sicher ob das wirklich so schlau ist. Ist nur der beste Ansatz der mir auf die Schnelle eingefallen ist.
-
Das kann ich mir nicht vorstellen. Ich habe mich schon mal zum testen an den Rand der Map geportet, wo durch Rundungsfehler bei Fließkommazahlen die Physik etwas rumspinnt. Die Map war sofort da. Selbst wenn, ich mache das nicht so.
Dann berechne das doch so, als ob es jeweils nur die Blöcke gibt, die in der theoretischen Sichtweite liegen. Hierbei wählst du einen der mittleren Blöcke als Nullpunkt für die Physikberechnung. Dann hast du keine Probleme mit zu großen Gleitkommazahlen.
Für Blöcke die zu weit weg sind, wird dann zwar keine Physik berechnet... aber da sollte mangels Anwenderinterakion nicht viel passieren.Um auch dieses Problem zu beheben kann man bei jedem Block berechnen wann zuletzt die Physik berechnet wurde. Wenn der Block wieder näher kommt kann man dann die fehlenden Berechnungen nachholen. So scheint dann auch die gesamte Welt physikberechnet zu sein.
