Hallo,
ich hab vor nicht allzulanger Zeit mit DelphiGL angefangen, und habe mich in letzter Zeit vorallem mit 2D-Spielen beschäftigt.
Mein momentanes Projekt ist ein kleines Rollenspiel, in dem der Spieler sich später durch kleine Dungeon kämpfen soll. Ich habe mich in letzer Zeit, nachdem ich ein kleines Inventar und Itemsystem eingebaut habe, mit den Karten beschäftigt. Und hier bin ich auf einige Probleme gestoßen.

Bei der Erkundigung wie ich am besten 2D-Karten für mein Spiel erstelle, bin ich auf den Tiled Editor gestoßen. Dieser gefällt mir sehr gut, da man mit wenig Aufwand eine Karte erstellen kann, und in dieser ebenfalls "Objekte" platzieren kann (Power-ups, Wände, etc.). Gespeichert wird die ganze Information dann in einer tmx Datei (letzendlich nur eine XML-Datei). Jedes Tile besitzt eine sogenannte gid ,eine ID die zu einem ganz bestimmten Teil in dem verwendeten tileset verweißt.

Veranschaulichung:

Bild von dieser Seite

Soweit sogut. Das Auslesen der Datei müsste eigentlich funktionieren. Mein Problem ist nun, dass ich das Bild nicht richtig auf meinen Bildschirm bekomme.
Meine erstelle Karte sieht so aus:


"Ingame" sieht das allerdings so aus:


Grundsätzlich funktioniert es, jedoch sind die übergänge nicht "sauber". Oft ist noch eine Linie Pixel vom tile daneben drauf, was zu unschönen Linien etc. führt.

Das verwendete tileset sieht folgendermaßen aus:


Das Bild wird als Bitmap mit dem glBitmap2D Loader in das Programm geladen. Das funktioniert auch soweit.



In dem Array gidMap ist die gid der jeweiligen Tiles gespeichert. tileSetsImages ist ein array von TglBitmap2D, in dem die verschiedenen tilesets gespeichert sind. Momentan ist nur die Bitmap mit dem Index 0 relevant. imagewidth und imageheight sind zusammen die "Größe der Karte in tiles".
Jetzt muss die gid in Texturkoordinaten umgerechnet werden. Zuerst wird die Position der Textur mit der gid ausgerechnet. Anschließend wird das ganze dann im Aufruf von DrawQuad in Texturkoordinaten umgerechnet.

DrawQuad sieht folgendermaßen aus:


Eigentlich müsste da alles stimmen. Ich weiß nicht, warum das Programm nicht die exakten "Grenzen" von den Tiles nimmt.
Ist irgendwo ein blöder Denkfehler oder sogar ein Tippfehler? Oder woran könnte das liegen und wie kann man es verhindern?

Schonmal danke im vorraus an alle, die sich mit dem Problem beschäftigen!

Gruß,
Astobix

Du gibst die Textur hoffentlich pixelgenau aus und hast keine Filter aktiv?

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Die Ausgabe der Textur findet in der Render-Procedure mit folgendem code statt:


Der Code von RenderVillage ist im 1. Beitrag zu sehen.

Daran kann es also kaum liegen, oder? :/

Da ich mich mit Delphi, den depraceted Funktionen und deinen Code nicht so gut auskenne, kann ich das gerade auf die nicht überprüfen, aber bist du dir bewusst das die Pixelmittelpunkte versetzt sind? Zum Erklären nehmen wir mal an, dass deine Textur 16 * 16 Pixel groß ist(Nur Beispiel). Die Texturkoordinaten gehen ja bei normalen Texturen immer von 0 ... 1
Der "0." Texel von 0 ... 0.0625, der 1. von 0.0625 zu 0.125, der 2. von 0.125 bis 0.1875, 0.1875 bis 0.25 ...
Wenn man jetzt zb. einen Ausschnitt vom 1 bis zum inklusiv 3 Texel nehmen willst, dann reicht es nicht aus, die "Texelkoordinaten" einfach durch die Texturgröße zu Teilen um die Texturkoordinaten zu erhalten. Als Beispiel: 1 / 16 = 0.0625. 0.0625 liegt jetzt exakt zwischen zwei Texeln in der Textur. Beim Nearest Pointfilter ist es jetzt Glückssache ob der "0." Pixel mit dabei ist oder es erst beim nächsten los geht, wie vorgesehen. Bei der Oberen Grenze ist es natürlich das selbe bloß anders rum. (3 / 16 = 0.1875)
Eine einfache Lösung wäre es, vor der Division durch die Texturgröße bei den unteren Texturkoordinaten 0.5 hinzuaddieren und an der oberen Grenze abzuziehen. (1 + 0.5) / 16 = 0.09375; (3 - 0.5) / 16 = 0.15625. Jetzt liegen die Texturkoordinaten genau auf der Texelmitte.

Du solltest außerdem natürlich sicherstellen, dass Mipmaping oder zb. der Anisotrope Filter ausgeschaltet sind.

errr du, genau das ist die Loesung fuer das Problem das du gerade Beschrieben hast. Kuckst du hier:
http://wiki.delphigl.com/index.php/Tuto ... en_filtern

_________________
Meine Homepage

Ein wenig Offtopic:

Bzgl. Performance reicht es im Moment aus, wenn du die Textur nur einmal bindest. Falls du später auf mehrere Texturen zugreifen musst, empfiehlt es sich, wenn du die Texturen bzw die Quads sortierst, so dass du möglichst wenige Statechanges hast.

Bzgl. glBegin: Es wäre besser, wenn du glBegin nur einmal vor der Schleife und glEnd nach der Schleife aufrufst. OpenGL baut dann nach jedem vierten glVertex ein Quad zusammen. Besser wäre auch direkt auf Quads zu verzichten und es direkt in 2 Dreiecke zu zerlegen. Ist einfacher dann zukünftig auf neuere OpenGL Versionen umzubauen.

_________________
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

Vielen Dank für die schnelle Hilfe!



Das ergibt grundsätzlich Sinn. Alleine damit klappt es jedoch (bei kleinen Zahlen ( ~ 0.005)) nicht, bei größeren Zahlen (~0.05) geht es zwar, aber die Texturen passen dann nicht mehr genau.



Alleine damit klappt es bei mir auch nicht. Grundsätzlich ist der Fehler behoben, sobald ich mich bewege taucht es aber immer wieder mal auf. (-> siehe Bilder)




Mit einer Kombination aus beiden klappt es auf jeden Fall! Konkret: Ich habe für den MAGnification Filter folgendes benutzt:


Dann habe ich jeweils 0.005 dazu addiert bzw subrahiert.

Ob die Lösung jetzt in irgend einer Weise sinnvoll ist weiß ich nicht. Funktionieren tut sie fürs erst allerdings.

Ja ist auch ok, du solltest dir aber mal die Matrizen anschauen. (genauer gesagt http://wiki.delphigl.com/index.php/Tuto ... GL_TEXTURE)
Damit kannst du solche Dinge wesentlich besser haendeln. Gerade irgendwelche Spritegeschichten (z.B. Feuer) gehen damit richtig gut und stressfrei.

Ausserdem solltest du dir nochmal ueberlegen ob du diese Art von Tileset verwenden willst. Deine Tiles sind nicht kompatibel mit den Wraps und Filter (fuehrt
halt wie du siehst zu Fehler). Diese Geschichten sind aber extrem praktisch und ersparen viel Code.

_________________
Meine Homepage

Ich würde das filtern so umstellen, dass er garnicht erst filtern will.
Hier gibt es eine Tabelle, ob Mipmaps auf welchen Kombinationen verwendet werden und ideal wäre in deinem Fall Mag und Min Filter auf Nearest zu stellen.
Wenn du keinen Border um deine einzelnen Tiles machst dann musst du entsprechend deine Texturkoordinaten anpassen, damit kein Bleeding entsteht.
Üblich macht man UV 0,0 bis 1,1 in allen Varianten oder halt entsprechend für die Tiles den relativen Ausschnit aber das hat ein Problem.
Durch Rundungsfehler kann es mal passieren, dass 0 auf -0.0000.... geht und nun wird noch der linke Nachbarpixel mit gerendert und noch schlimmer das Bild wird getaucht und bei Nearest entsteht ein etwas matschigeres Bild(merkt man nur im direkten Vergleich mit dem Orginal).
Wenn das auch für die rechte Seite passiert, dann kann es ein Offset geben oder noch matschiger werden.

Das umgeht man, indem man ein halben Texel auf die UV addiert(links/oben) bzw. subtrahiert(rechts/unten).
Dadurch kann eine Ungenauigkeit kein Sprung zwischen den Texeln verursachen.
Wie groß der halbe Texel sein muss bekommt man wie folgt raus.


Da man aber nun rechts raus rutscht, weil man ja den Offset überall drauf addiert muss man entsprechend die Größe der Tiles um 1 Texel reduzieren.
Nun wird der Interne Code einfach jeden Pixel deiner Textur nehmen und die Farbe 1zu1 auf den Bildschirm rendern, wenn die Projektion stimmt(orthogonal) und das Tile nicht skaliert wird.


Nun wäre es Pixelperfekt, es gibt kein bleeding und es werden auch nie MipMaps zum filtern verwendet.
Wenn du das ganze skalieren willst, dann solltest du nicht nearest verwenden, sondern GL_LINEAR / GL_LINEAR.
So werden immer noch keine Mip-Maps verwendet und es wird interpoliert.
Solltest du auch aus den Orthogonal Modus raus wollen, um z.B. mal eine schräge View zu haben, dann müsstest du Mip-Maps mit rein packen und GL_LINEAR / GL_LINEAR_MIPMAP_LINEAR zum filtern verwenden.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hallo,

eine andere Möglichkeit wäre, ersteinmal zu probieren, ob Texture wrapping auf GL_CLAMP statt GL_REPEAT gestellt ist, siehe hier.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Hallo,

ich mache das einfach so, dass ich ein normales Tileset (ohne Ränder zwischen den Tiles) erstelle und beim Laden zuerst die Tiles in einem neuen Bitmap im Speicher mit Abstand zwischen den einzelnen Tiles neu platziere und die Ränder der einzelnen Tiles einfach oben, rechts, unten und links dupliziere. Das funktioniert mit Scanline ganz gut. Alle Randpixel sind also doppelt. Anschließend wird das neue Bitmap in die Textur geladen. Vielleicht etwas unkonventionell, aber es funktioniert. Hatte auch am Anfang viel experimentiert und das war für mich die beste Lösung. Das Problem ist nämlich, wenn Du keine Filter verwendest, dass Du keine verschiedenen Auflösungen verwenden kannst. Denn ohne Filter siehts einfach nicht gut aus. Und wenn Du schon beim Erstellen des Tilesets bereits darauf achten musst, dass die Randpixel doppelt sind, ist das einfach nur nervig. Wenn die einzelnen Tiles unterschiedlich groß sind, wirds allerdings etwas komplizierter.

Wenn die Tiles alle die gleiche Größe haben, sind Texture Arrays die einfachste Lösung.

Ich selbst nutze die Textur auch für den Zeichensatz. Dadurch brauche ich nur eine Textur. Klingt aber trotzdem gut. Funktioniert das auch mit einer großen Anzahl an Tiles?



Man kann ja auch große Tiles oft ohne Probleme in kleine aufteilen.

Ich hab auf Arbeit ein Atlas generator gebaut, der benutzt ein Codefragment, zum laden welche Texturen ich brauche und welche Maße diese haben.
Dann verwende ich ein externen Codeblock http://www.blackpawn.com/texts/lightmaps/default.html zum packen der rechtecke.
Der letzte Codeblock benutzt devil und die neu sortierten rechtecke um ein atlas zu bauen.
Der Atlas ist eine textur und eine file wo die uv's mit id's drin stehen.

Das rendern mach ich wie schon vorher beschrieben.
So brauch ich keine Border und die Atlanten sind optimal gepackt und das ganze hat nen knappen tag an arbeit gekostet, weil der schlimmste Code von externen kommt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

cooler link

_________________
Meine Homepage