Punkt 2: Ich meinerseits benutze in der Tat einen vector mit Rects, die ich nach jeder Bewegung mit dem Playerrect vergleiche, und bei Bedarf eingreife. Hat sich nicht wirklich auf die Performance ausgewirkt. Falls du eine sehr große Map hast, solltest du die Rects eines Bereiches vllt. in Chunks zusammenfassen, und das Playerrrect nur mit den Rects in dem Chunk vergleichen, in dem er sich auch befindet.
In meinem Action Adventure habe ich keine Unterteilung in Chunks und dennoch ist die Kollisionsprüfung in Bezug auf die benötigte Rechenzeit mit der Umgebung vollkommen unabhängig von der Größe der Umgebung. Ich suche mir Anhand der Koordinaten des Spielers einfach die Felder heraus, mit denen er möglicherweise kollidieren könnte und prüfe nur mit diesen, ob es Kollisionen gibt.
und zur tilemap also ich versucch das jetzt so, das ich einfach immer um den spieler herum die felder überprüfe und festegelegt hab in nem vector was für zeichen stehen für solid objekte
Und du möchstest nun wissen, ob der Ansatz so gut ist? (Ich sehe jedenfalls keine Frage)
klingt nach einem verwendbaren Ansatz, nur denke ich, dass einzelne Zeichen für einzelne Felder (auf Dauer) nicht unbedingt so toll sind. Man schränkt sich ziemlich stark in der Anzahl der möglichen Felder ein und noch bevor man die maximale Anzahl an möglichen Feldern ausnutzen muss, wird man wohl Probleme mit der Unterscheidung der verschiedenen Zeichen haben. (Welches Zeichen ist welches Feld?)
Wenn du eine gute Editierbarkeit mittels Texteditor haben willst, dann solltest du eher richtige Namen verwenden (z. B. "grass", "water", "roof", ...) und ansonsten Zahlen, welche auch dem Index im Tileset entsprechen.
Aber mal ein paar weiter gehende Fragen: hast du nur eine einzige Ebene oder mehrere? Da du anhand der Art des Tiles auf Kollisionen prüfst, gehe ich von einer einzigen aus.
Was ist nun, wenn du ein solides Objekt auf einem begehbaren Untergrund platzieren willst? würdest du den Untergrund als Teil des Objekts behandeln und die Grafik des Untergrunds in die Grafik des Objekts übernehmen?
Wenn nun das Objekt verschwinden soll, müsstest du das Feld so anpassen, dass statt des Objekts mit dem Untergrund der richtige Untergrund angezeigt wird.
Wenn du mehrere Ebenen haben würdest, dann könntest du den Spieler auf eine dieser Ebenen setzen, beispielsweise auf die 2. Ebene (wenn die 1. den Boden darstellt).
Dann könntest du über das Vorhandensein von Feldern, also wenn einem Feld auch ein Tile des Tilesets zugewiesen wurde, die Kollisionsprüfung abhandeln und müsstest nicht separat definieren, womit man kollidiert.
Weiterhin kann man jedes beliebige Objekt auf jeden beliebigen Untergrund stellen, ohne dass für jede mögliche Kombination neue Grafiken angelegt werden müssen.
Du könntest fliegende Objekte haben, die die Kollision mit Objekten auf dem Boden nicht interessieren oder du könntest sehr einfach Brücken oder ähnliches basteln, von denen man einerseits verdeckt (darunter stehen) wird oder die man selbst verdeckt (darauf stehen).
Ich hoffe mal, du siehts meine Anmerkungen nicht zu kritisch. Das, was du dir bisher überlegt hast ist schon eine gute Grundlage und das, was ich hier genannt habe sind im Grunde nur Erweiterungen der Gedanken, die du bereits hattest. Es kann ja auch sein, dass du das von mir genannte für dein Spiel gar nicht benötigen wirst, aber dies einzuschätzen bleibt dir überlassen.