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: > <PIE-HEADER> > ... > 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
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzonefirstname.lastname@example.org https://mail.gna.org/listinfo/warzone-dev