Inhoud van een map file

[calsmurf2904]

LOL, met TGA textures werkt het nog raarder. Ik krijg wel goed resultaten maar het lijkt also de texture met 10, 10 pixels is verschoven.
En de tiles worden incorrect gekozen, als ik bijvoorbeeld de text0 bestand hebt zijn de tile indexes dan horizontal oplopend of verticaal oplopend?
dus:
[0][1][2][3][4][5][6][7]
of
[0]
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Volgens mij ligt daar mijn fout namelijk, ik denk dat het horizontaal oplopend is
Dus:
[0][1][2][3][4][5][6][7]
[8][etc.]

[edit]
Hier staan de C++ codes online:

in CRendererGL::LoadTileTexture in de bestand CRendererOpenGL.cpp laad ik de aparte textX.tga bestanden in en "snij" ik ze in stukken en zet ik de pixeldata van de in stukken gesneden stukken in een opengl array.
Dan kies ik bij CRendererGL::SetMap in CRendererOpenGL.cpp per tile de opengl texture die die moet gebruiken, of texture 0 als ie een tile gebruikt die niet beschikbaar is om de een of andere reden.

[King Harold]

Ze gaan zo van
[0][1][2][3][4][5][6][7]
[8][9] etc
(de logische manier zegmaar)

Snijden ah ok, ik zet een type om in een texture coordinate met wat grappige berekeningen (oa ook een stukje van het randje af, anders waren er vooral bij stijle bergen wat artifacts langs de rand)

[calsmurf2904]

Wacht even, ik upload even een screenshot van hoe het er nu uitziet.

[edit]
Klaar:

Het ziet er heel raar uit, ik denk dat dat komt omdat opengl het texture formaat toch niet goed heeft. (Misschien is het wel GL_RGBA inplaats van GL_RGB)

[calsmurf2904]

Als ik het goed begrijp is dus de y coordinate van elke linker bovenhoek van de tile y-height of y+height?
En elke andere hoek neemt de y+/-height over van de aanliggende tile van die tile?

[King Harold]

Y-height ja

[calsmurf2904]

OK, even gedebugged...hij denkt dat die tile die je helemaal rechts onder in het plaatje ziet tile 0 is. Dat is natuurlijk niet correct.

[King Harold]

Ah er klopt niet sowieso niet zo veel van, ziet er een beetje gemixed uit

[calsmurf2904]

Ja, maar ik denk (nou ja, weet wel zeker) dat dat komt omdat die tile id's niet kloppen intern. Ik snap niet waarom btw, ik heb het gedebugged en hij gaat toch echt elke tile texture af. (alle 4*64 = 256 tile textures), en een std::vector slaat het op oplopend dus de eerste texture zou id 0 moeten hebben. Misschien klopt mijn "snij" code niet.

[King Harold]

Tja ik denk dan dat het toch aan de snij ligt, de tiles die hij laat zien zijn duidelijk opgebouwd uit reepjes van meerdere tiles

[calsmurf2904]

En jij snijd gewoon doormiddel van:
tile id <= 63:
text0 v1: u = ((1.0f/256)/8)*tileid
v = ((1.0f/256)/8)*tileid
etc. ?

[King Harold]

[calsmurf2904]

Als ik het per bestand dus wil zou ik dit moeten doen:
x0 = (tileid & 7) * 0.125f;
y0 = (tileid >> 3) * (1f/8);
per vertex (met verschillende coordinaten natuurlijk)

[edit]
Heb je niet msn ofzo dat je zou willen delen? maakt dit veel makkelijker en sneller

[calsmurf2904]

Het begint er nu beter uit te zien, alleen volgens mij zijn de u&v coordinaten nog steeds niet correct. (Ik doe nu: (1.0f/256)*(id*32) per u&v coordinaat)
btw, ik heb mijn msn details toegevoegt aan mijn profiel..als je wilt kunnen we ook via msn eventueel praten. Gaat veel sneller dan met een forum

[King Harold]

Waarom id*32? Je moet niet vergeten dat het in rijen en colommen zit he, dus eigenlijk doe je:

row = tileid / 8; (aka timeid >> 3)
column = tileid % 8; (aka tileid & 7)
x0 = column * (1f / 8 ); (8 colommen breed)
y0 = row * (1f / 32); (32 rijen hoog)
Of 8 ipv 32 als je ze los wil laten

[calsmurf2904]

ik doe die id*32 omdat ik eerst doe 1.0f/256 en die 256 is de breedte&hoogte van de textuur. Dus hij moet de uv pakken van de coordinaten.