level
- NicTheQuick
- Ein Admin
- Beiträge: 8808
- Registriert: 29.08.2004 20:20
- Computerausstattung: Ryzen 7 5800X, 64 GB DDR4-3200
Ubuntu 24.04.2 LTS
GeForce RTX 3080 Ti - Wohnort: Saarbrücken
Ihr habt meinen Code wohl nicht durchgelesen oder einfach nicht
verstanden. Ein kleines einfaches Beispiel:
Da man in seinem Spiel ja meist mehr als nur eine Art Boden benutzt,
würde ich dazu raten die verschiedenen Böden in einer einheitlichen
Struktur verpackt in eine LinkedList zu lesen.
Jetzt gibt es das Field-Array, das die einzelnen Tiles beinhaltet. Dieses
Array speichert aber pro Feld nur den Pointer zu einem Element der
Boden-LinkedList, also 4 Byte, trotzdem liegen dann alle Daten zu dieser
Art Boden vor und man kann direkt damit arbeiten. Wenn man jetzt in der
Boden-LinkedList eine Art Boden verändert, z.B. das man darauf
langsamer laufen kann o.ä., dann wird das sofort auf jedes Feld im Field-
Array vererbt, weil diese neue Eigenschaft ja nur einmal im Speicher ist
und nur der Pointer im Field-Array darauf weist.
Und da es nicht nur verschiedene Böden, sondern auch Häuser, Gewässer
und was weiß ich noch alles gibt, habe ich dafür auch eine Beispielstruktur
entworfen und alles in der Field-Struktur in eine StructureUnion
geschrieben.
Und langsam ist das keineswegs, höchstens schneller, einfacher,
Speicherplatzschonender, usw.
verstanden. Ein kleines einfaches Beispiel:
Da man in seinem Spiel ja meist mehr als nur eine Art Boden benutzt,
würde ich dazu raten die verschiedenen Böden in einer einheitlichen
Struktur verpackt in eine LinkedList zu lesen.
Jetzt gibt es das Field-Array, das die einzelnen Tiles beinhaltet. Dieses
Array speichert aber pro Feld nur den Pointer zu einem Element der
Boden-LinkedList, also 4 Byte, trotzdem liegen dann alle Daten zu dieser
Art Boden vor und man kann direkt damit arbeiten. Wenn man jetzt in der
Boden-LinkedList eine Art Boden verändert, z.B. das man darauf
langsamer laufen kann o.ä., dann wird das sofort auf jedes Feld im Field-
Array vererbt, weil diese neue Eigenschaft ja nur einmal im Speicher ist
und nur der Pointer im Field-Array darauf weist.
Und da es nicht nur verschiedene Böden, sondern auch Häuser, Gewässer
und was weiß ich noch alles gibt, habe ich dafür auch eine Beispielstruktur
entworfen und alles in der Field-Struktur in eine StructureUnion
geschrieben.
Und langsam ist das keineswegs, höchstens schneller, einfacher,
Speicherplatzschonender, usw.
- freedimension
- Admin
- Beiträge: 1987
- Registriert: 08.09.2004 13:19
- Wohnort: Ludwigsburg
- Kontaktdaten:
Wenn man die Anzahl der der Böden, Gewässer, Häuser usw. kennt kann man auch mit Arrays arbeiten.
Ist noch Speicherplatzschonender da man hier keine interene Struktur mit Pointer bräuchte, für eine Linkedliste
. Und wenns sogar noch sehr viele von diesen Elementen gibt, dürfte das Laden und Freigeben vielleicht sogar merklich schneller ablaufen.
MFG PMV
Ist noch Speicherplatzschonender da man hier keine interene Struktur mit Pointer bräuchte, für eine Linkedliste

MFG PMV
Öhm, wenn mit hilfe von Pointer auf ein Element einer LinkedListe zugreift gibt es keinen unterschied zu einem Array.Batze hat geschrieben:Das mit der LL ist wirklich ein gutes Beispiel. Der Zugriff ist doch auch besser als mit Arrays.
Bei LinkedListen muss man sogar zudem entweder die PB interne Struktur von LinkedListen auslesen um den Pointer zum nächsten Element aus zu lesen oder die PB-Befehle verwenden. Bei Arrays geschieht das natürlich ganz einfach in dem man einen anderen Index eines Elementes angibt.
MFG PMV
- NicTheQuick
- Ein Admin
- Beiträge: 8808
- Registriert: 29.08.2004 20:20
- Computerausstattung: Ryzen 7 5800X, 64 GB DDR4-3200
Ubuntu 24.04.2 LTS
GeForce RTX 3080 Ti - Wohnort: Saarbrücken
Ok, dann ist die Methode eben genial.
Das geniale daran ist meiner Meinung nach die Unabhängigkeit des Field-
Array von den eigentlichen Tile-Daten. Eine Änderung und alles ist getan.
Schwierig wirds natürlich, wenn ein Tile den Typ Boden hat und trotzdem
anders sein soll wie alle anderen, aber deswegen habe ich noch die
Speziell-Struktur eingebaut. Vielleicht braucht man die aber auch gar
nicht.
Natürlich könnte man die Böden und so auch in ein Array schreiben, aber
dort kann man nicht mal eben ein Element aus der Mitte rauslöschen,
ohne dass dieser Speicherbereich dann unbenutzt bleibt oder die
Restlichen nachrücken und somit die Pointer im Field-Array auf das
falsche zeigen. Die Elemente einer LinkedList haben ihren Speicherbereich
und rücken nicht von der Stelle, egal was mit den anderen Elementen ist.
Also LinkedLists sind mir dafür einfach lieber. Und ein "MaxElements"-
Variable für eine Liste muss man sich auch nicht merken, wohl aber bei
einem Array. Ich arbeite eben gerne mit wenigen Variablen, aber vielen
Strukturen und Pointern. Gefällt vielleicht nicht jedem, finde ich allerdings
sehr praktisch.
@PVM:
Du brauchst bei dieser Methode garantiert nicht herausfinden, wo das
nächste Element in einer LinkedList ist. Die LinkedList wird lediglich dazu
verwendet dynamisch Speicher reservieren zu können und gleichzeitig
noch schön in einer Liste alle Böden sortiert zu haben zum schnellen
Finden oder Manipulieren.


Das geniale daran ist meiner Meinung nach die Unabhängigkeit des Field-
Array von den eigentlichen Tile-Daten. Eine Änderung und alles ist getan.
Schwierig wirds natürlich, wenn ein Tile den Typ Boden hat und trotzdem
anders sein soll wie alle anderen, aber deswegen habe ich noch die
Speziell-Struktur eingebaut. Vielleicht braucht man die aber auch gar
nicht.
Natürlich könnte man die Böden und so auch in ein Array schreiben, aber
dort kann man nicht mal eben ein Element aus der Mitte rauslöschen,
ohne dass dieser Speicherbereich dann unbenutzt bleibt oder die
Restlichen nachrücken und somit die Pointer im Field-Array auf das
falsche zeigen. Die Elemente einer LinkedList haben ihren Speicherbereich
und rücken nicht von der Stelle, egal was mit den anderen Elementen ist.
Also LinkedLists sind mir dafür einfach lieber. Und ein "MaxElements"-
Variable für eine Liste muss man sich auch nicht merken, wohl aber bei
einem Array. Ich arbeite eben gerne mit wenigen Variablen, aber vielen
Strukturen und Pointern. Gefällt vielleicht nicht jedem, finde ich allerdings
sehr praktisch.

@PVM:
Du brauchst bei dieser Methode garantiert nicht herausfinden, wo das
nächste Element in einer LinkedList ist. Die LinkedList wird lediglich dazu
verwendet dynamisch Speicher reservieren zu können und gleichzeitig
noch schön in einer Liste alle Böden sortiert zu haben zum schnellen
Finden oder Manipulieren.
^^ich fühl micht jetzt einfach mal angesprochen@PVM:
Du brauchst bei dieser Methode garantiert nicht herausfinden, wo das
nächste Element in einer LinkedList ist. Die LinkedList wird lediglich dazu
verwendet dynamisch Speicher reservieren zu können und gleichzeitig
noch schön in einer Liste alle Böden sortiert zu haben zum schnellen
Finden oder Manipulieren.

Beim freigeben des Speichers bzw löschen der Elemente schon, oder wenn man die Objekte warum auch immer durchlaufen, z.B. wegen einer Animation, um das aktuelle Sprite zu verändern.
Ob Array oder LinkedListe kommt im Endeffekt auf das Spiel drauf an bzw der Verwendung der Objekte der Liste. Wenn man während des Spiels Elemente löschen muss ist eine LinkedListe besser.
Wäre es aber notwendig eine "Liste" von solchen Objekten bei jedem Frame komplet durch zu arbeiten wäre ein Array ab einer bestimmten Menge für die Optimierung unumgänglich.
Und wenn beides der Fall ist kommt es wohl auf die maximale Anzahl der möglichen Elemente und den dadurch verursachten Rechenaufwand an.
Aja, mir ist aufgefallen das ich auch immer mehr Pointer und Strukturen verwende. Könnte aber auch an den aktuellen Projekten liegen

MFG PMV