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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to