Okay then - I'll start fiddling with the files. Whenever you guys manage to convert the source code to handle dynamic textures sizes, I'll get to fine-tune them if necessary.

PS - I'm omitting the terrain tiles for starters - mostly because of the complexity - as I'm afraid these require more work than I have time for. I have experience with working with existing textures, but not so much creating (or re-creating) new textures from scratch. I can do some filter magic, but while hand-painting structure textures is relatively simple, hand-painting seamless textures can be a nightmare (for me at least).

Question for whoever is working on graphics code: have you considered implementing detail texturing (I could create the detail textures) for the terrain? That would do away with the need to redo the surface tiles (some propping up would still be nice, though).

Are there any plans for additional (new) vegetation (grass, bushes, etc)? Will water be redone or left as it is?

And this is a key question: what about increasing the number of animation frames for smoke puffs and explosions? These are currently part of the existing textures, but placing them in separate textures with additional frames wouldn't be to difficult for anyone (coders or artists).

Furthermore, is there a "model viewer" of some sort for the objects in WZ that could be used to test the textures directly without having to run the game? If there is, a link or equivalent would be nice.


Dennis Schridde wrote:
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...


Warzone-dev mailing list

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.15/579 - Release Date: 7.12.2006

Warzone-dev mailing list

Reply via email to