Re: [Warzone-dev] Upconverting WZ textures
Well, the main problem is that it's not loading the texture(s) :). It displays the model just fine, but it's not giving me an error or anything once I've converted the texture to pcx and renamed the texture name inside the pie file (I'm assuming that it assumes that the two are in the same directory). If anyone else can get this working I'd like to know what I'm missing. Right now it's not loading a texture at all - the texture editor is empty. If this worked, it'd be much more awesome than running the game to check things out. RJ Giel van Schijndel wrote: Christian Vest Hansen schreef: 2006/12/9, Ranger Joe <[EMAIL PROTECTED]>: 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. Cranphin made such an app once. I'll see if I can dig it up but don't be too hopeful - it's a couple of disk wipes since. I've got PieSlicer DX which works for viewing purposes at least. I'm not going to provide a judgement as on how good it works, since I have no experience with this kind of software (3D Studio Max comes closest). It does require you to rename the texture file name referred to in the PIE-file to a PCX extension to actually be able to view it as textured. So see the attachments. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.15/580 - Release Date: 8.12.2006 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
I mean the latter - using scaled down "noise textures" (as you put it) to add detail to a surface (these aren't really noise, mind you, but actual coherent detail textures that bring out the non-existent fineness of the texture when viewed up close). Implementing multitexturing is simple in OpenGL (doesn't matter if you're doing it through extensions or multipassing) and adding a separate layer for detail textures shouldn't be too difficult. It would, in my opinion, enhance the overall quality of the terrain considerably. If you want to see detail textures in action, I think the best example is Serious Sam - just enable detail texturing and move up close to a wall. Adding detail texturing to buildings would probably be a bad idea, though. And while we're discussing technicalities, are there plans for implementing bump mapping (meaning, if yes, then are there plans for dynamic or static bump maps)? RJ Per Inge Mathisen wrote: On 12/9/06, Ranger Joe <[EMAIL PROTECTED]> wrote: Question for whoever is working on graphics code: have you considered implementing detail texturing (I could create the detail textures) for the terrain? I am not sure what you mean by 'detail texturing'. Do you mean mipmapping? If so, yes, we use this internally by creating smaller versions during loading. Grim suggested we make handcrafted mipmaps instead, and this would be easy to add support for in the code, if someone went to the (not inconsiderable, I would guess) work of making handcrafted mipmaps. It would also increase the size of the image data considerably. Or do you mean some kind of multitexturing, where you add noise textures on top of existing terrain textures? If so, no we do not use multitexturing at the moment, but I know how to do it, and, well, depending on how fancy you want it, it should not be too hard to implement either, if we just have some graphics to use. Not that I would have time to do it for another two months, though :-( I do not know the answer to your other questions. Sorry. - Per ___ 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
Re: [Warzone-dev] Upconverting WZ textures
On 12/9/06, Ranger Joe <[EMAIL PROTECTED]> wrote: Question for whoever is working on graphics code: have you considered implementing detail texturing (I could create the detail textures) for the terrain? I am not sure what you mean by 'detail texturing'. Do you mean mipmapping? If so, yes, we use this internally by creating smaller versions during loading. Grim suggested we make handcrafted mipmaps instead, and this would be easy to add support for in the code, if someone went to the (not inconsiderable, I would guess) work of making handcrafted mipmaps. It would also increase the size of the image data considerably. Or do you mean some kind of multitexturing, where you add noise textures on top of existing terrain textures? If so, no we do not use multitexturing at the moment, but I know how to do it, and, well, depending on how fancy you want it, it should not be too hard to implement either, if we just have some graphics to use. Not that I would have time to do it for another two months, though :-( I do not know the answer to your other questions. Sorry. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
2006/12/9, Ranger Joe <[EMAIL PROTECTED]>: 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. Cranphin made such an app once. I'll see if I can dig it up but don't be too hopeful - it's a couple of disk wipes since. -- Venlig hilsen / Kind regards, Christian Vest Hansen. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
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. RJ 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... --Dennis ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev 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 Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
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] 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
Re: [Warzone-dev] Upconverting WZ textures
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. it is this way due to the original site getting so much spam and attacks. if you have any problems - let me know. kim (lav_coyote25) metcalfe [EMAIL PROTECTED] [EMAIL PROTECTED] - is also addy for the msn messenger. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
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. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
Ranger Joe schreef: > Dennis Schridde wrote: >> Am Donnerstag, 7. Dezember 2006 23:36 schrieb Dennis Schridde: >>> As far as I know (I am not perfect, nor do I know everything about WZ): >>> >>> - UV coords are handled in the engine as being in the interval ( >>> 0.0, 1.0 >>> ), because that's how OpenGL does it. If the PIE files gave explicit >>> (non >>> relative) coords, then those are very probably diveded by the >>> texturesize >>> given in the same file when loading into the engine. >>> This is much more flexible when you are going to resize the >>> textures, Giel. Well that was what I wasn't sure off. Because the current PIE-files define U/V coordinates as x/y coordinates within the range of the widthxheight dimensions of the specified texture resolution. But I guess it is indeed divided by the texture dimensions to create a fractional number, as I'll try to explained below. >>> - 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/) >>> >>> - Binaries are at http://wz2100.net/downloads.html >>> >>> - Power of 2 textures would bring a performance benefit, correct? >>> I guess in theory the tiles could be regrouped to fit into a quadratic >>> texture, but we'd also have to adapt the maps to this change, I fear. >>> Generally I like the idea, but someone would have to provide a map >>> converter. >>> >>> - Vector graphics are probably not practical for textures... >>> Most textures are photographs or similar, as was said, and for the >>> handmade >>> or algorithm-generated ones I don't think vector graphics would be >>> sensible, either. >>> What is defenitely usefull (and nearly required) is the >>> GIMP/PhotoShop/Whatever file you created the textures with... >>> Especially if >>> you use multiple layers and similar. >> PS: When you work on the tile textures you need to keep in mind that >> they need to be rotationally seamless... >> >> Maybe we can improve this for 2.1 or 2.2, to give artists willing to >> volunteer less headache? > Ok - thanks for the link. As for vector graphics - I think the > intended subtext was that the textures could be resized as needed and > rasterized at any conceivable resolution. Regardless, I think I won't > try to recreate the textures, but rather upscale and rework the > existing ones at far greater resolutions, which can then be > downsampled to any resolution using standard interpolated methods. > > As for power of two texture size preference - those are the natively > supported sizes by any hardware-based graphics API due to memory > access and mipmapping solutions used by the GPU (and thus the video > drivers). Most (read: all) current drivers should have automatic > support for non-power-of-two textures (although at least for older > cards you'd definitely need to use some extension to resize the > textures on GPU, or do resizing in software prior to loading the > textures (if there is no support for non-power-of-two textures)), > although I'm not sure. > > Using fractional U/V coords is standard practice, Giel, and a lot more > intuitive when you're using non-fixed texture sizes. Well what I meant with unintuitive is that having to define U/V coordinates relative to the texture-bitmap's resolution requires more math than can be good for you. Meaning that, as is currently the case AFAIK U/V coordinates are specified within the range of the dimensions given. Hmm, lets quote a PIE-file: data/structs/blpower0.pie: > > ... > TEXTURE 0 page-11-player buildings.png 256 256 > ... > LEVEL 1 > POINTS n > ... > POLYGONS n >original line: >10200 4 20 23 76 77 0 109 0 81 0 81 0 109 > >translated line: >(polygon)1: flag=10200, n_points=4, point1=20, point2=23, > point3=76, point4=77, U_point1=0, V_point1=109, U_point2=0, > V_point2=81, U_point3=0, V_point3=81, U_point4=0, V_point4=109; > As you can see there, all U/V coordinates are specified as integers, probably in the range of 0-255. I first thought that those U/V coordinates are absolute, meaning they are independent of the provided resolution of 256x256. Which would mean that increasing texture size would make U/V coordinates be wrong. If however those U/V numbers in the 0-255 range are *not* absolute, but relative to the dimensions (i.e. 256) then I would find that to be very far from intuitive. Because retrieving a fractional U/V coordinate set would then have to be accomplished by these equations: U_fract= U_abs / width and V_fract= V_abs / height. So what I basically said (or tried to say) here is: * 0.0-1.0 fractions are good to my opinion; * 0-255 absolute coordinates are reasonable to my opinion. * 0-255 fractions are bad to my opinion; -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-de
Re: [Warzone-dev] Upconverting WZ textures
Ok - thanks for the link. As for vector graphics - I think the intended subtext was that the textures could be resized as needed and rasterized at any conceivable resolution. Regardless, I think I won't try to recreate the textures, but rather upscale and rework the existing ones at far greater resolutions, which can then be downsampled to any resolution using standard interpolated methods. As for power of two texture size preference - those are the natively supported sizes by any hardware-based graphics API due to memory access and mipmapping solutions used by the GPU (and thus the video drivers). Most (read: all) current drivers should have automatic support for non-power-of-two textures (although at least for older cards you'd definitely need to use some extension to resize the textures on GPU, or do resizing in software prior to loading the textures (if there is no support for non-power-of-two textures)), although I'm not sure. Using fractional U/V coords is standard practice, Giel, and a lot more intuitive when you're using non-fixed texture sizes. RJ Dennis Schridde wrote: Am Donnerstag, 7. Dezember 2006 23:36 schrieb Dennis Schridde: As far as I know (I am not perfect, nor do I know everything about WZ): - UV coords are handled in the engine as being in the interval ( 0.0, 1.0 ), because that's how OpenGL does it. If the PIE files gave explicit (non relative) coords, then those are very probably diveded by the texturesize given in the same file when loading into the engine. This is much more flexible when you are going to resize the textures, Giel. - 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/) - Binaries are at http://wz2100.net/downloads.html - Power of 2 textures would bring a performance benefit, correct? I guess in theory the tiles could be regrouped to fit into a quadratic texture, but we'd also have to adapt the maps to this change, I fear. Generally I like the idea, but someone would have to provide a map converter. - Vector graphics are probably not practical for textures... Most textures are photographs or similar, as was said, and for the handmade or algorithm-generated ones I don't think vector graphics would be sensible, either. What is defenitely usefull (and nearly required) is the GIMP/PhotoShop/Whatever file you created the textures with... Especially if you use multiple layers and similar. PS: When you work on the tile textures you need to keep in mind that they need to be rotationally seamless... Maybe we can improve this for 2.1 or 2.2, to give artists willing to volunteer less headache? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.14/578 - Release Date: 7.12.2006 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
Am Donnerstag, 7. Dezember 2006 23:36 schrieb Dennis Schridde: > As far as I know (I am not perfect, nor do I know everything about WZ): > > - UV coords are handled in the engine as being in the interval ( 0.0, 1.0 > ), because that's how OpenGL does it. If the PIE files gave explicit (non > relative) coords, then those are very probably diveded by the texturesize > given in the same file when loading into the engine. > This is much more flexible when you are going to resize the textures, Giel. > > - 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/) > > - Binaries are at http://wz2100.net/downloads.html > > - Power of 2 textures would bring a performance benefit, correct? > I guess in theory the tiles could be regrouped to fit into a quadratic > texture, but we'd also have to adapt the maps to this change, I fear. > Generally I like the idea, but someone would have to provide a map > converter. > > - Vector graphics are probably not practical for textures... > Most textures are photographs or similar, as was said, and for the handmade > or algorithm-generated ones I don't think vector graphics would be > sensible, either. > What is defenitely usefull (and nearly required) is the > GIMP/PhotoShop/Whatever file you created the textures with... Especially if > you use multiple layers and similar. PS: When you work on the tile textures you need to keep in mind that they need to be rotationally seamless... Maybe we can improve this for 2.1 or 2.2, to give artists willing to volunteer less headache? pgpjG91aQ13u6.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
As far as I know (I am not perfect, nor do I know everything about WZ): - UV coords are handled in the engine as being in the interval ( 0.0, 1.0 ), because that's how OpenGL does it. If the PIE files gave explicit (non relative) coords, then those are very probably diveded by the texturesize given in the same file when loading into the engine. This is much more flexible when you are going to resize the textures, Giel. - 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/) - Binaries are at http://wz2100.net/downloads.html - Power of 2 textures would bring a performance benefit, correct? I guess in theory the tiles could be regrouped to fit into a quadratic texture, but we'd also have to adapt the maps to this change, I fear. Generally I like the idea, but someone would have to provide a map converter. - Vector graphics are probably not practical for textures... Most textures are photographs or similar, as was said, and for the handmade or algorithm-generated ones I don't think vector graphics would be sensible, either. What is defenitely usefull (and nearly required) is the GIMP/PhotoShop/Whatever file you created the textures with... Especially if you use multiple layers and similar. --Dennis pgpPxScEXz3k1.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
I have no real experience with vector graphics, but I guess I'll check it out. I'm afraid there's a rather steep learning curve to it, though. As for changing the U/V coordinates - why? U/V coordinates are fractional. Unless I change the relative positioning of image data in the texture, there shouldn't be any need to update these; what worries me more is that I can't find texture coordinates in the respective pie files. Once more, though - where could I obtain working compiled binaries of the WZ:R source code since I can't compile it myself (and frankly don't want to get into the hassle of doing so because of the required setup and lack of experience). kim: I'm guessing it's me, but I can't find the downloads section RJ Giel van Schijndel wrote: zz zz schreef: From: Ranger Joe <[EMAIL PROTECTED]> Reply-To: Development list To: warzone-dev@gna.org Subject: [Warzone-dev] Upconverting WZ textures Date: Thu, 07 Dec 2006 07:58:17 +0200 Hi, I can't seem to be able to register on realtimestrategies.net - I still haven't got the confirmation email over a period of several days. So I'm posting here. In any case, I'd be interested in upconverting any existing low-resolution textures WZ:Resurrection will be using (from the original WZ). To test these, however, I would need some help as to how to best load them up in the game without having to compile the source code itself. I haven't been able to figure out precisely what you've done to/with the source code, so I'd really appreciate a small rundown on the process of getting the modified textures into the game with the smallest possible amount of trouble. That is, of course, if WZ:R supports non-fixed texture sizes in the first place (if it doesn't, it shouldn't be too demanding to add the support). I'm figuring being able to jump to any campaign and having all the techs available would be really helpful as well. Since most textures seem to be 256x256 pixels in size, I figured the reasonable upgrade would be to 512x512 and possibly (since there aren't too many textures in the game) also to 1024x1024. The terrain textures are 1152x1280 in size, so doubling these wouldn't kill anyone either on today's hardware. I have no idea why these would have such a weird resolution. Wouldn't changing them to a power of two make more sense? As far as I have observed, the original textures need quite a bit of work, not just resizing, as they are quite raw and plagued with low-bit depth, low-resolution aliasing. In fact, I think that's the biggest problem I had with the game - when the camera came really close to a building, the visual quality would plummet. Please let me know if someone is already working on this and, if not, then how best to go about testing the textures. noone is working on textures as far as I know. with 2.0.5rc1+? you can create a folder called 'data',then create a sub-folder of 'data' called 'textpages' and copy new texture files there,it'll override the ones in .wz files that comes with 2.0.5rc1.Also you need to change the pie file's texture info accordingly to use 512x512 textures I think. Are you sure the pie-files support 512x512 (or higher) because I've read somewhere that there is a limit to it (256x256 I believe). @Ranger Joe: it is also important to modify the U/V coordinates in the PIE-files when modifying the textures. As for some cheats which might assist in campaign/level jumping: http://wz2100.net/wiki/user:cheats PS It would be nice if you (or anyone for that matter) made the textures as vector graphics. So that they can be reproduced at higher resolutions without much trouble. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.14/578 - Release Date: 7.12.2006 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
On Thu, 07 Dec 2006 00:58:17 -0500 Ranger Joe <[EMAIL PROTECTED]> wrote: >Hi, > >I can't seem to be able to register on realtimestrategies.net - I >still >haven't got the confirmation email over a period of several days. >So I'm >posting here. The "new" forum home is at http://wz2100.net/ >In any case, I'd be interested in upconverting any existing >low-resolution textures WZ:Resurrection will be using (from the >original >WZ). To test these, however, I would need some help as to how to >best >load them up in the game without having to compile the source code > >itself. I haven't been able to figure out precisely what you've >done >to/with the source code, so I'd really appreciate a small rundown >on the >process of getting the modified textures into the game with the >smallest >possible amount of trouble. >That is, of course, if WZ:R supports non-fixed texture sizes in >the >first place (if it doesn't, it shouldn't be too demanding to add >the >support). > >I'm figuring being able to jump to any campaign and having all the >techs >available would be really helpful as well. > >Since most textures seem to be 256x256 pixels in size, I figured >the >reasonable upgrade would be to 512x512 and possibly (since there >aren't >too many textures in the game) also to 1024x1024. The terrain >textures >are 1152x1280 in size, so doubling these wouldn't kill anyone >either on >today's hardware. I have no idea why these would have such a weird > >resolution. Wouldn't changing them to a power of two make more >sense? > >As far as I have observed, the original textures need quite a bit >of >work, not just resizing, as they are quite raw and plagued with >low-bit >depth, low-resolution aliasing. In fact, I think that's the >biggest >problem I had with the game - when the camera came really close to >a >building, the visual quality would plummet. > >Please let me know if someone is already working on this and, if >not, >then how best to go about testing the textures. > >Cheers >RJ >From what I have read in the past, you could just do your work from the old texture files once you unzip the warzone.wz file, then use the 32bit map editor for your new textures and see how it looks. That is what I think the old artist did. Right now, you would have to compile the source code to support bigger textures than what is default. I think your best bet is to contact lav_coyote, since he is a map maker, and knows pretty much all there is to know about this subject since he did all the beta testing as stuff from the old artist. I am pretty sure there is really no limit on the 32bit map editor besides being power of 2 tiles, so you can make 512x512 if you want. You may also want to check out the old artists work. (Contact lav_coyote again). Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
Christian Ohm schreef: > On Thursday, 7 December 2006 at 10:08, Giel van Schijndel wrote: > >>> there,it'll override the ones in .wz files that comes with >>> 2.0.5rc1.Also you need to change the pie file's texture info >>> accordingly to use 512x512 textures I think. >>> >> Are you sure the pie-files support 512x512 (or higher) because I've read >> somewhere that there is a limit to it (256x256 I believe). >> >> @Ranger Joe: it is also important to modify the U/V coordinates in the >> PIE-files when modifying the textures. >> > As long as you keep the relative positions, you don't need to adjust > anything in the PIE files. The size value isn't used anymore, that was > for the software renderer. The texture coordinates are relative, all you > need to do is upscale the old texture and add your new textures. > > You can just unzip the data.wz file to see the used file structure, and > then replace whichever files you like. (Warzone will use real files if > it finds some, or what is in data.wz if there are no files.) > So if I understand correctly the U/V coordinates are now relative to the specified size? E.g. if the specified texture size is 256x256 a U/V coordinate of (32,32) really means (12.5%,12.5%) relative to the actual picture's size? This seems a bit cumbersome to me; since specifying absolute U/V coordinates based on the actual picture's dimensions seems more intuitive to me. More than relative U/V coordinates that is. >> PS It would be nice if you (or anyone for that matter) made the textures >> as vector graphics. So that they can be reproduced at higher resolutions >> without much trouble. >> > I don't think most textures will use vector graphics but photographs or > other raster graphics as base. Vectors are useful for plain colours or > gradients, but not structures as used in textures (dirt for example - > you want a more detailed structure and not just enlarged blotches). > > But even for raster graphics, having the original Gimp file with all > layers and base images would be nice, so the textures can be adapted for > future use (for example in new models in another format and higher > resolution textures). > Probably true for stuff like sand, etc. Some building's textures however would easily be described by vector graphics. That aside, I do agree it is probably best to have the original source files from textures. -- 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 Thursday, 7 December 2006 at 10:08, Giel van Schijndel wrote: > zz zz schreef: > >> From: Ranger Joe <[EMAIL PROTECTED]> > >> I can't seem to be able to register on realtimestrategies.net - I > >> still haven't got the confirmation email over a period of several > >> days. So I'm posting here. This list or the forum on wz2100.net is the right place, realtimestrategies.net is more or less dead. Where did you get that address from? Perhaps we can change that... > >> That is, of course, if WZ:R supports non-fixed texture sizes in the > >> first place It does. > >> Since most textures seem to be 256x256 pixels in size, I figured the > >> reasonable upgrade would be to 512x512 and possibly (since there > >> aren't too many textures in the game) also to 1024x1024. The terrain > >> textures are 1152x1280 in size, so doubling these wouldn't kill > >> anyone either on today's hardware. I have no idea why these would > >> have such a weird resolution. Wouldn't changing them to a power of > >> two make more sense? Depends. Currently it works, if you can change it in a way that still works, it'll probably be added. > > with 2.0.5rc1+? you can create a folder called 'data',then create a > > sub-folder of 'data' called 'textpages' and copy new texture files texpages > > there,it'll override the ones in .wz files that comes with > > 2.0.5rc1.Also you need to change the pie file's texture info > > accordingly to use 512x512 textures I think. > Are you sure the pie-files support 512x512 (or higher) because I've read > somewhere that there is a limit to it (256x256 I believe). > > @Ranger Joe: it is also important to modify the U/V coordinates in the > PIE-files when modifying the textures. As long as you keep the relative positions, you don't need to adjust anything in the PIE files. The size value isn't used anymore, that was for the software renderer. The texture coordinates are relative, all you need to do is upscale the old texture and add your new textures. You can just unzip the data.wz file to see the used file structure, and then replace whichever files you like. (Warzone will use real files if it finds some, or what is in data.wz if there are no files.) > PS It would be nice if you (or anyone for that matter) made the textures > as vector graphics. So that they can be reproduced at higher resolutions > without much trouble. I don't think most textures will use vector graphics but photographs or other raster graphics as base. Vectors are useful for plain colours or gradients, but not structures as used in textures (dirt for example - you want a more detailed structure and not just enlarged blotches). But even for raster graphics, having the original Gimp file with all layers and base images would be nice, so the textures can be adapted for future use (for example in new models in another format and higher resolution textures). -- Function reject. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Upconverting WZ textures
zz zz schreef: >> From: Ranger Joe <[EMAIL PROTECTED]> >> Reply-To: Development list >> To: warzone-dev@gna.org >> Subject: [Warzone-dev] Upconverting WZ textures >> Date: Thu, 07 Dec 2006 07:58:17 +0200 >> >> Hi, >> >> I can't seem to be able to register on realtimestrategies.net - I >> still haven't got the confirmation email over a period of several >> days. So I'm posting here. >> >> In any case, I'd be interested in upconverting any existing >> low-resolution textures WZ:Resurrection will be using (from the >> original WZ). To test these, however, I would need some help as to >> how to best load them up in the game without having to compile the >> source code itself. I haven't been able to figure out precisely what >> you've done to/with the source code, so I'd really appreciate a small >> rundown on the process of getting the modified textures into the game >> with the smallest possible amount of trouble. >> >> That is, of course, if WZ:R supports non-fixed texture sizes in the >> first place (if it doesn't, it shouldn't be too demanding to add the >> support). >> >> I'm figuring being able to jump to any campaign and having all the >> techs available would be really helpful as well. >> >> Since most textures seem to be 256x256 pixels in size, I figured the >> reasonable upgrade would be to 512x512 and possibly (since there >> aren't too many textures in the game) also to 1024x1024. The terrain >> textures are 1152x1280 in size, so doubling these wouldn't kill >> anyone either on today's hardware. I have no idea why these would >> have such a weird resolution. Wouldn't changing them to a power of >> two make more sense? >> >> As far as I have observed, the original textures need quite a bit of >> work, not just resizing, as they are quite raw and plagued with >> low-bit depth, low-resolution aliasing. In fact, I think that's the >> biggest problem I had with the game - when the camera came really >> close to a building, the visual quality would plummet. >> >> Please let me know if someone is already working on this and, if not, >> then how best to go about testing the textures. > noone is working on textures as far as I know. > > with 2.0.5rc1+? you can create a folder called 'data',then create a > sub-folder of 'data' called 'textpages' and copy new texture files > there,it'll override the ones in .wz files that comes with > 2.0.5rc1.Also you need to change the pie file's texture info > accordingly to use 512x512 textures I think. Are you sure the pie-files support 512x512 (or higher) because I've read somewhere that there is a limit to it (256x256 I believe). @Ranger Joe: it is also important to modify the U/V coordinates in the PIE-files when modifying the textures. As for some cheats which might assist in campaign/level jumping: http://wz2100.net/wiki/user:cheats PS It would be nice if you (or anyone for that matter) made the textures as vector graphics. So that they can be reproduced at higher resolutions without much trouble. -- 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
From: Ranger Joe <[EMAIL PROTECTED]> Reply-To: Development list To: warzone-dev@gna.org Subject: [Warzone-dev] Upconverting WZ textures Date: Thu, 07 Dec 2006 07:58:17 +0200 Hi, I can't seem to be able to register on realtimestrategies.net - I still haven't got the confirmation email over a period of several days. So I'm posting here. In any case, I'd be interested in upconverting any existing low-resolution textures WZ:Resurrection will be using (from the original WZ). To test these, however, I would need some help as to how to best load them up in the game without having to compile the source code itself. I haven't been able to figure out precisely what you've done to/with the source code, so I'd really appreciate a small rundown on the process of getting the modified textures into the game with the smallest possible amount of trouble. That is, of course, if WZ:R supports non-fixed texture sizes in the first place (if it doesn't, it shouldn't be too demanding to add the support). I'm figuring being able to jump to any campaign and having all the techs available would be really helpful as well. Since most textures seem to be 256x256 pixels in size, I figured the reasonable upgrade would be to 512x512 and possibly (since there aren't too many textures in the game) also to 1024x1024. The terrain textures are 1152x1280 in size, so doubling these wouldn't kill anyone either on today's hardware. I have no idea why these would have such a weird resolution. Wouldn't changing them to a power of two make more sense? As far as I have observed, the original textures need quite a bit of work, not just resizing, as they are quite raw and plagued with low-bit depth, low-resolution aliasing. In fact, I think that's the biggest problem I had with the game - when the camera came really close to a building, the visual quality would plummet. Please let me know if someone is already working on this and, if not, then how best to go about testing the textures. Cheers RJ noone is working on textures as far as I know. with 2.0.5rc1+? you can create a folder called 'data',then create a sub-folder of 'data' called 'textpages' and copy new texture files there,it'll override the ones in .wz files that comes with 2.0.5rc1.Also you need to change the pie file's texture info accordingly to use 512x512 textures I think. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
