PureBoard

dauert das nicht zu lang, das jedes mal zu machen?

Nö

Ich glaub es dauert länger, bei jedem Scrollen oder jeder Bewegung einer Figur ein komplettes neues Riesensprite vorzubereiten...

ja das schon aber ich meinte das anzeigen wenn nicht gescrollt wird.

Wenn NIE gescrollt wird, dann wäre es unter Umständen denkbar, einfach alles als Bild vorzubereiten und das jedesmal anzuzeigen. Also bei Pacman z.B. (da wird ja, zumindest in der Originalversion, nie gescrollt).

Wenn aber hin und wieder gescrollt wird, dann wär es doch umständlich, immer danach zu entscheiden - wurde gescrollt, okay dann müssen wir jetzt halt alles so aufbauen, ahhh jetzt wurde mal ein paar Sekunden nicht gescrollt, jetzt bereiten wir das als Bild vor. Macht keinen Sinn, denn Du weißt ja auch nicht, wann zum nächsten mal gescrollt wird (sofern das vom Spieler abhängt).

Ich programmiere zur Zeit auch ein Iso-Game mit einer großen Tilemap, und ich zeichne immer genau den Bereich, der nötig ist, damit der ganze Bildschirm ausgefüllt ist. Und da bei jeder Bewegung, die meine Figur macht, gescrollt wird, wäre es sinnlos, das immer als komplettes Bild vorzubereiten. Und auch wenn die Figur steht, wird einfach alles komplett aufgebaut. Hat auch den Vorteil, daß die Frames per Second immer recht konstant bleiben, da jeder Frame in etwa gleich lang braucht.

ok dann mache ich das so.
wie könnte man gebäude anzeigen? wenn man eins baut in eine linked list oder auch in einen array?
linked list wäre um einiges einfacher etwas hinzuzufügen aber wenn ich mir das dann vorstelle soeins wieder anzuzeigen würde ich lieber das array nehmen. was könnt ihr mir da empfehlen?

Wenn es nicht zu viele Objekte werden dann ist eine Linked List genau das passende dort. Einfach die Tilekoordinaten + Grafik und eventuelle Aktion des Objekts speichern und nach dem Anzeigen der Spielkarte die Liste durchlaufen und die Objekte platzieren.

auch nicht unbedingt schlecht, allerdings würde ich größere grafix nur für objekte nutzen..

die eigentlich map würde ich aus gleichgroßen tiles zusammensetzen (wie in deinem beispiel 32x32)

dann wäre zb. bei
Map(3,4) = 65

an der screenkoordinaten 3*32,4*32 das Tile mit der ID 65

Das hat den Nachteil, dass es bei komplexen Karten eine Unmenge von geladenen Sprites werden und alle mit IDs vereinbart werden müssen. Wenn ich jetzt ein Tileset von 16 x 16 Tiles habe (512 x 512 Pixel) dann wären das schon 256 IDs für Sprites. Einfacher wäre eine ID = 1 Sprite und die Tiles werden daraus geclipt. Noch dazu kann man aus den Daten wie "feld[3][4].tilegrafik_x = 3 " direkt herauslesen, dass es das 4te Tile (da Beginn bei 0 ist) von links ist. Mit der Y-Koordinate kann man sich genau heraussuchen welche Grafik es ist, ohne das man wissen muss, welche Grafik mit welcher ID eingeladen wurde. Will sagen, man hat zwar eine Variable mehr als mit der ID dafür hat man ein Koordinatensystem welches eindeutig übertragbar ist auf jede Art von Tilesets. Man tauscht einfach das Tileset gegen ein anderes aus und muss nur ein Sprite neu einladen, das Koordinatensystem kann man übernehmen. Man muss also nicht für jede Grafik eine neue ID vergeben und dann beim Platzieren der neuen Grafiken müssen diese neuen IDs bekannt sein.

Aber letztlich ist es ja seine Sache, wie er es umsetzen will. Ich hab nur bisher schon etliche Tilebasierte Spielchen und Map-Editoren gemacht (3 - 4 in PureBasic und 2 - 3 in C++ mit OpenGL) und da hat sich das immer als Vorteilhaft erwiesen, weil die Koordinatenmethode überall gültig ist, unabhängig von IDs oder Ähnlichem.

Wenn NIE gescrollt wird, dann wäre es unter Umständen denkbar, einfach alles als Bild vorzubereiten und das jedesmal anzuzeigen. Also bei Pacman z.B. (da wird ja, zumindest in der Originalversion, nie gescrollt)

Eine 1024 x 768 Pixel große Bitmap braucht aber mehr Speicher als ein Tileset von vielleicht 256 x 256 Pixeln (64 unterschiedliche Tiles) welches mehrfach verwendet wird. Und wenn die Karte nun nicht unbedingt so hochwertig ist, dass kein Bereich dem anderen gleicht und immer einmalig ist, kommt man mit der Methode speichersparender ans Ziel. Weil man eben bereits eingeladene Sprites mehrfach verwenden kann.

Wenn's um den RAM geht, dann hast Du Recht, aber mir ging's jetzt momentan nur um die Geschwindigkeit beim Anzeigen.

Ich würd generell das Bild immer neu aufbauen... ist irgendwie flexibler wollte damit nur sagen, daß es auch Fälle gibt wo man immerhin drüber nachdenken kann

bei gebäden könnte man eventuell den bau auch im map array speichern, dann wird die wegfindung auch ein bischen einfacher, aber natürlich muß man dann speichern was vorher unter dem gebäude zu sehen war, falls es wieder entfernt wird.

die idee von sunny mit den tileset-locations in dem array ist gar nicht mal übel.

aber man kann auch die position auf dem tileset aus der ID berechnen.

Tileset bedeutet übrigens nur eine sammlung von tiles,
diese könnten auch als einzelne sprites gespeichert werden,
dann entfällt der rechenvorgang das clippens.
der verbrauch an grafikkarten-speicher ist trotzdem gleich.

außerdem kann man dann mehr tiles im set haben,
da clipping nur funktioniert, wenn das Set-Sprite maximal so groß ist,
wie der Screen.

wenn man jetzt tiles der größe 64x64 verwenden möchte und 256 verschiedene hat,
wäre das Tileset 4096x4096 groß, das läßt sich nicht mehr clippen.

die Tiles kann man in aufeinanderfolgende sprite# einladen,
damit korrespondiert die TileID direkt mit der Spritenummer.


noch was zu den objekten:
wenn du das array als Longs erzeugst, also Map.l(Breite,Höhe)
dann brauchst du für 256 unterschiedliche Tiles nur das untere byte.
die drei oberen bytes stehen noch zur verfügung,
dort kann man z.b. IDs von objekten speichern.

das hat den vorteil, daß du direkt auf die anzuzeigenden objekte zugreifen kannst,
die IDs stehen im selben arrayauschnitt wie die Tiles, die du gerade anzeigen willst.
Dann brauchst du nicht eine lange LL durchzugehen.

außerdem kannst du 2 bit dieses long dafür verwenden,
um flags für "erforscht" und "nebel des krieges" zu setzen.

Zaphod hat geschrieben:bei gebäden könnte man eventuell den bau auch im map array speichern, dann wird die wegfindung auch ein bischen einfacher, aber natürlich muß man dann speichern was vorher unter dem gebäude zu sehen war, falls es wieder entfernt wird.

Für den Zweck hab ich dann ein zweites Array, das so groß ist wie meine Map, aber in dem gespeichert wird, ob ein Feld belagert ist von irgendwas oder nicht... keine Ahnung, ob das elegant ist, aber funktionieren tut es