Ich glaube da stimmt irgendwas nicht damit, wie du tw und th berechnest. Wenn deine Tile Textur immer noch die gleiche wie aus dem ersten Post ist, also 2x2 Tiles, dürfte ja eigentlich garkeine y-Koordinate mit 0.0 bzw. 1.0 vorkommen (je nachdem von wo man anfängt zu zählen)

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Nun funktioniert es, hatte noch einen kleinen unscheinbaren Fehler beim aufstellen der Textur Koordinaten.
Danke an alle.

Ich wärme das Thema nochmal auf.
Wenn ich jetzt vorhabe, Texturkoordinaten eines bestimmten Tiles zu ändern, wäre es schlau, dies mittels glMapBuffer zu tun?
Sprich Buffer Speicher holen, den Index raussuchen und die Koordinaten anpassen und dann natürlich mit glUnmapBuffer zurück transferieren.

für die paar Dreiecke, die Du da malst, ist ein VBO total überdimensioniert. Wieviele Dreiecke werden es am Ende? 1000? 10000? Da ist es vermutlich einfacher einfach für jedes Tile den TexturIndex zu merken, und wenn dieser sich ändert werden die TexturCoords für das jeweilige Tile neu geholt/gerechnet.

Ansonsten: ja, glMapBuffer...

Kannst Dir ja mal http://arcsynthesis.org/gltut anschauen...

Am Ende werden es so 1000 x 1000 sein.
Ich guck' mir mal den Link an.

Aber die 1000000 Dreiecke werden doch nicht alle gleichzeitig sichtbar sein, oder?
Mal grob überschlagen mit einer Tilegröße von 16x16 sind es grade mal knapp über 8000 Tiles, die bei Full-HD sichtbar wären.
Überleg mal ob du die Tiles nicht in Gruppen zusammenfasst: 16x16 oder 32x32. Die Gruppen lassen sich dann einfach aktualisieren und du brauchst auch nur die Gruppen rendern, die sichtbar sind.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Inwiefern in Gruppen? Quadtree mäßig?
Und wieso keinen VBO?

Mit Gruppen meine ich VBO oder Displaylisten. sry. hätte ich auch gleich schreiben können. wollte es dir überlassen was du nimmst.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Also anstatt dass die TileMap aus einem zusammengehörigen VBO besteht, würdest du das ganze lieber in Chunks aufteilen, so dass die Karte am Ende aus mehreren Gruppen/VBO's besteht? Oder missverstehe ich das?

1 VBO, wenn dann, welches nur die sichtbaren tiles "malt"

Ja, Chunk ist wohl das Wort, dass dazu passt.

Ich hatte an so etwas gedacht:

Blau = wird gerendert
Rot = nicht sichtbar
Roter Rahmen = Bildschirm/Sichtbereich

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Dann müsste ich zunächst einmal eine Gruppierungsfunktion schreiben. Inwiefern würde mir die Aufteilung/Gruppierung in Chunks nützen?

Mal ein Beispiel:

Karte besteht aus 1024x1024 Tiles. (2097152 Dreiecke)
Wenn die Chunks 8x8 Tiles aufnehmen, sind das 128 Tiles pro Chunk. (256 Dreiecke)
Der Viewport kann (sagen wir mal) 64x48 Tiles darstellen. Also werden mindestens 8x6 und maximal 9x7 Chunks gerendert werden. (min 12288 ; max 13824 Dreiecke)

Ein Unterscheid um den Faktor 170,66 bzw. 151,70!

Und wenn du nun ein Tile aktualisierst musst du nicht alle 1024x1024 Tiles neu auf die Graka ballern, sondern eben nur einen Chunk.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Ok, klingt plausibel. Aber was, wenn der zu zeichnende Bereich einen bzw. mehrere Chunks nur streift? Die dann komplett zeichnen oder wie?
Und wie wäre so ein Chunk dann aufgebaut?
Stelle mir das gerade in etwa so vor:

Um beim Beispiel zu bleiben:
Bei 9x7 Chunks sind im schlechtesten Falle 63 Chunks zu Zeichnen. Die am Rand werden halt abgeschnitten. Sind 28 Chunks, die nur teilweise gezeichnet werden. Also nicht mal die Hälfte. Ich denke das ist vertretbar.

Zur Implementation:
Ob man wirklich die Chunkgröße in jedem Chunk speichern muss ist fraglich, es sei denn man will unterschiedlich große Chunks haben. Ich denke eine Konstante sollte da reichen.

Eigentlich brauchst du in deinem Chunk struct nur einen Verweis auf dein VBO.
Wenn du deine Chunks in ein 2-dimensionales array speicherst kannst du einfach anhand der Spieler-/Kameraposition in der Welt und Größe des Sichtbereiches mittels for-Schleifen deine Chunks durchlaufen und Zeichnen.

Kurzer Abriss wie ich's bei mir implementiert hab (bei mir ist's 3D, also keine Tiles sondern Blöcke):
Klasse World
-eine HashMap hält die Chunks vor (indiziert mit den Weltkoordinaten)
-eine update Funktion prüft wo sich der Spieler befindet und fordert ggf. einen neuen Chunk an (wird von Platte geladen oder generiert)
-bietet Funktionen wie set/getBlockAt(Vector v) und sucht dazu den passenden Chunk und gibt die Funktion weiter
Klasse Chunk
-enthält die Blockdaten und einen Verweis auf die id der Displayliste
Klasse ChunkBuilder
-wird von der World-Klasse aufgerufen um die Geometrie für einen Chunk zu generieren
Klasse Renderer
-bekommt die Geometrie vom ChunkBuilder und gibt ne Displayliste zurück

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next