Am Freitag, 8. Dezember 2006 19:57 schrieb Dennis Schridde: > Am Freitag, 8. Dezember 2006 11:06 schrieb Per Inge Mathisen: > > On 12/8/06, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > > > I thought Grim was able to "snuck in" higher resolution textures... > > > > I just tired to resize tertiles1hw a little bit. Now it looks like a > > > > patchwork carpet in game. :( > > > > ... > > > > > My very first guess is that WZ uses a hardcoded amount of memory to > > > store the textures and if the image is bigger... Something get's > > > discarded or similar... I think that because of the segfault when using > > > a different size. > > > > IIRC tile sizes are still are hardcoded both in size and number. I > > promised Grim I would fix this, but I have not gotten around to it > > (although I did clean up the code quite a bit). Most of the relevant > > code is in src/texture.c and also see lib/ivis_common/bitimage.c > > I began looking at that code: Nasty at least... > > 1. The texture is loaded > 2. Call makeTileTexturePages with a hardcoded tile width/height > 3. Copy over tileWidth*tileHeight*PAGE_DEPTH (the latter is again hardcoded > to 32bpp) chunks of the given texture to some temporary buffer > 4. Copy over PAGE_WIDTH*PAGE_HEIGHT (hardcoded) chunks into another buffer > 5. Add that last buffer to the texture pages > > I'll try to fix this and improve interaction with the texture loading. What I've found out so far:
Steps2+3 from above: Grab one tile(128x128) from the tertiles page (into tmp buffer) and then put it into a 512x512 texture page. (All texture pages seem to be limited to 512x512.) The UV coordinate of the final texture is then "calculated" weirdly... It stores the x/y index (offset, integer) of each tile into tileTexInfo. When it then draws the tiles (display3d.c:drawTerrainTile), it multiplies it with 64 and adds 0 or 63, depending on which corner it is. Then it does some memcpy magic goes through pie_DrawPoly and finally arrives in pie_Polygon, where it interpretes the former integers as floats and gives it to glTexCoord2f, then being in the range ( 0.0, 1.0 ). I guess to fix this we would have to rip out the whole polygon drawing, to replace those integer memcpy weirdos with sane floats... Actually I wonder how this would work on systems with different size of int and float... --Dennis
pgpVPIHpQ1FFJ.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
