Re: [Warzone-dev] Upconverting WZ textures
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
Re: [Warzone-dev] Upconverting WZ textures
On 12/8/06, Dennis Schridde <[EMAIL PROTECTED]> wrote: Am Freitag, 8. Dezember 2006 05:21 schrieb kim metcalfe: > > kim: I'm guessing it's me, but I can't find the downloads section > > > > RJ > > you need to register - you will then receive a confirmation link - > then you can log in - that is the only way to see the downloads > section. Well, I can see the download page without logging me into anything and I don't think that Kamaze required any kind of login for any page... :) --Dennis the file i was speaking about is the warzone Documents Project file - which is what i emailed him about. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
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. --Dennis pgpBoh6INbEEQ.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ari: Still valid? Workaround for MacOS gcc 4.0.0 bug
Ari Johnson wrote:
Yes, the bug is still there.
On 12/8/06, Dennis Schridde <[EMAIL PROTECTED]> wrote:
Is the bug in this code still present? Or can we remove the tmp int?
lib/ivis_common/bitimage.c:92:
// Load the texture pages.
for (i = 0; i < Header->NumTPages; i++) {
int tmp;/* Workaround for MacOS gcc 4.0.0
bug. */
Just rename tmp to pageID. Then there's no problem with leaving it in
(for me, at least).
It's maybe even more readable, and the compiler will optimize it away
anyhow.
- Gerard
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Ari: Still valid? Workaround for MacOS gcc 4.0.0 bug
Yes, the bug is still there.
On 12/8/06, Dennis Schridde <[EMAIL PROTECTED]> wrote:
Is the bug in this code still present? Or can we remove the tmp int?
lib/ivis_common/bitimage.c:92:
// Load the texture pages.
for (i = 0; i < Header->NumTPages; i++) {
int tmp;/* Workaround for MacOS gcc 4.0.0 bug. */
LoadTextureFile((char*)Header->TPageFiles[i],
&ImageFile->TexturePages[i],
&tmp);
ImageFile->TPageIDs[i] = tmp;
}
--Dennis
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Ari: Still valid? Workaround for MacOS gcc 4.0.0 bug
Is the bug in this code still present? Or can we remove the tmp int?
lib/ivis_common/bitimage.c:92:
// Load the texture pages.
for (i = 0; i < Header->NumTPages; i++) {
int tmp;/* Workaround for MacOS gcc 4.0.0 bug. */
LoadTextureFile((char*)Header->TPageFiles[i],
&ImageFile->TexturePages[i],
&tmp);
ImageFile->TPageIDs[i] = tmp;
}
--Dennis
pgpLJJJM8jTY2.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
[EMAIL PROTECTED] schreef: > On Thu, 07 Dec 2006 17:36:39 -0500 Dennis Schridde > <[EMAIL PROTECTED]> wrote: > >> As far as I know (I am not perfect, nor do I know everything about >> WZ): >> >> - You don't need any map editor... You can simply extract the >> warzone.wz to a >> data/ folder in the same directory and Warzone will load it's >> stuff from >> there. (Overriding what is in warzone.wz if it finds the same file >> in data/) >> > He said he didn't want to compile the source code. So then his > only option is to use the 32bit map editor to view/use textures > that are bigger than what is default now. Unless there is a > command line switch to use higher resolution textures that you > snuck in when nobody was looking? > > Then once they are working fine with that, someone can modify wz to > the texture size he is using. I think there are 80 tiles per page, > and 4-5 pages. That is allot of work for 1 person to do, and you > can't really release only 1 page at a time either since the game > isn't built to handle multiple size tiles. > Well I'm always willing to compile wz for him, in fact I've got a windows installer here (r537): http://www.mortis.eu/node/9 -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
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 BTW, I have worked a bit with non-power-of-two textures in OpenGL before. You do not want to go there. The earliest extension lacks nearly all useful features, and the newest is poorly supported. Both are probably slower for real 3D tasks than ordinary power-of-two textures on most hardware. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
Am Freitag, 8. Dezember 2006 04:17 schrieb [EMAIL PROTECTED]: > On Thu, 07 Dec 2006 17:36:39 -0500 Dennis Schridde > > <[EMAIL PROTECTED]> wrote: > >As far as I know (I am not perfect, nor do I know everything about > >WZ): > > > >- You don't need any map editor... You can simply extract the > >warzone.wz to a > >data/ folder in the same directory and Warzone will load it's > >stuff from > >there. (Overriding what is in warzone.wz if it finds the same file > >in data/) > >--Dennis > > He said he didn't want to compile the source code. So then his > only option is to use the 32bit map editor to view/use textures > that are bigger than what is default now. Unless there is a > command line switch to use higher resolution textures that you > snuck in when nobody was looking? > > Then once they are working fine with that, someone can modify wz to > the texture size he is using. I think there are 80 tiles per page, > and 4-5 pages. That is allot of work for 1 person to do, and you > can't really release only 1 page at a time either since the game > isn't built to handle multiple size tiles. 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. :( I thought the tile textures were addressed using an interval of ( 0.0, 1.0 ), too... We should fix that... --Dennis pgpXKG70aTnOt.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
Am Freitag, 8. Dezember 2006 05:21 schrieb kim metcalfe: > > kim: I'm guessing it's me, but I can't find the downloads section > > > > RJ > > you need to register - you will then receive a confirmation link - > then you can log in - that is the only way to see the downloads > section. Well, I can see the download page without logging me into anything and I don't think that Kamaze required any kind of login for any page... :) --Dennis pgpABaiMyA41b.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
