Lady Rowena on 29/9/2012 at 13:15
Ah, thanks! Even if I will leave them in 256x256 gif format there will be still be the advantage of not having color losses due to the conversion to a common palette. :thumb:
LarryG on 29/9/2012 at 13:20
Thanks! I'll look.
LarryG on 29/9/2012 at 13:32
Quote Posted by Lady Rowena
Ah, thanks! Even if I will leave them in 256x256 gif format there will be still be the advantage of not having color losses due to the conversion to a common palette. :thumb:
Found these explanations from the past about graphics formats:
Quote Posted by Nameless Voice
.pcx if a rather obscure format that takes up more space than .gif and which is not supported (by default) by Windows' Thumbnail View, or as a valid texture format by many 3D programs.
.gif should be used when possible for convenience.
TGAs are another matter entirely. They are true colour, and don't count towards the palette count, but due to the way that Dark handles them, they generally look worse than .gif images.
However, they have some advantanges, such as a full alpha channel for per-pixel transparency, plus TGA textures are rendered with less pixellation, which is especially useful for text.
See (
http://www.ttlg.com/forums/showthread.php?p=1288241#post1288241) this thread for more information about TGA textures.
Quote Posted by ZylonBane
To expand on what NV said--
From the end user's perspective, PCX and GIF are identical. The only time you should ever use PCX is when explicitly overriding a built-in PCX texture.
GIF/PCX
* 255 unique 16-bit colors per image (65535 colors)
* 5 bits red, 6 bits green, 5 bits blue (RGB565)
* Palette entry #0 is always treated as full transparent
* Global limit on the number of unique palettes used by all images.
TGA
* Unlimited 12-bit colors per image (4096 colors)
* 4 bits red, 4 bits green, 4 bits blue, 4 bits alpha (RGBA4444)
* Per-pixel 4-bit alpha channel (16 levels of transparency)
* Do not count toward the global palette limit, but the file size is huge
I thought I remembered something about Paletted textures being better to use if a) you don't need the transparency gradations possible with an alpha channel and b) you don't need really smooth color shading. And that non-Paletted textures are better in just the reverse. But I can't find that thread just now. I'm pretty sure it was something ZB posted a year or so back. There may have been something about Palette based textures being crisper, sharper than non ... ? Ah, it was the (4096 colors) vs. (65535 colors). Palettes can have 256 colors from a wider pool to choose from. Non-Paletted can have more in a single texture, but from a smaller pool of possible colors. That was it, I think.
Edit: maybe it was that Palettes are better with images that have less rgb variation, that is are more uniform in colors used, but non-Paletted are better if there are lots of different colors use in a single image? Was that it?
Sensut on 29/9/2012 at 14:14
My only problem with the palettes was that general 256 limit. Because of that limit I had to spoil a lot of textures instead of using them in the original HQ form. With those 256 color textures Thief looks like a real old-school PC game, now with the HQ textures almost looks like a movie :D .
The Watcher on 29/9/2012 at 14:19
Quote Posted by LarryG
Palettes can have 256 colors from a wider pool to choose from. Non-Paletted can have more in a single texture, but from a smaller pool of possible colors. That was it, I think.
That is only the case with the old thief engine's handling of TGA. The newly supported 24 or 32 bit images formats(PCX-32, new handling of TGA, PNG, DDS/DXT) are not subject to that restriction, and every pixel can be a different colour out of a possible
16.7 million per pixel. Palletised images are not
worse (note: this does not make them better) in one very specific case: where the image has less than 256 unique colours in it to begin with. If it ever has more than that, you should be using one of the 24/32 bit colour formats, or you will lose some quality when converting to palletised format, whether you are using a common palette or not.
ie: as I said before, if you don't want to go for DDS, you should be using PNG (which wins out over TGA and PCX-32 for on-disc compression and supports 24 and 32 bit formats), there really is no actually good reason to use gif or pcx any more.
ZylonBane on 29/9/2012 at 14:52
Quote Posted by The Watcher
ie: as I said before, if you don't want to go for DDS, you should be using PNG (which wins out over TGA and PCX-32 for on-disc compression and supports 24 and 32 bit formats), there really is no actually good reason to use gif or pcx any more.
Seconded. PNG should be the go-to medium-sized texture format now. It supports paletted images, true-color images, one-bit transparency, and 8-bit transparency, all rolled up in one handy format, with superior file compression. NewDark most likely uses libpng for its PNG implementation, so it's probably safe to assume that it supports the entire baseline spec.
But for large textures (1024x1024 or greater), yeah, DDS is the way to go. DDS is a container format for various DXT codecs, which decompress in realtime directly on the video card, saving huge amounts of VRAM. The downside of DXT is that, somewhat like JPEG, it's a lossy format that works best with organic textures. That's good for Thief, but bad for SS2.
(
http://blogs.msdn.com/b/shawnhar/archive/2008/10/28/texture-compression.aspx)
LarryG on 29/9/2012 at 15:29
Thanks, ZB :thumb:
Used to be:
Quote Posted by Nameless Voice
Using animated textures (for objects)Updated: 19 Jun 2006It is possible to animate any texture used in DromEd, be a terrain texture, interface image, bitmap particle effect, or custom object texture. This is done by creating each frame of the animation as seperate texture file and giving them all special names.
The naming convention is as follows:
The Dark Engine will animate any texture if the filename (in the .bin file for objects and meshes) ends with an underscore ("_"). It will animate it by cycling through all availiable images that have the same name, plus a number at the end. The extension of the files is ignored, so you can have .pcx and .gif frames as part of the same animation. These additional frames will not be loaded into the texture palette if you add the family that contains them to your mission.
So, Test_.gif will be animated to Test_1.gif, Test_2.pcx, Test_3.gif, etc.
Animated textures are looped, and also include the original filename (Test_.gif in this example) as the first frame.
You can also use .tga textures in your animation, but since the Dark Engine's support for .tga images is somewhat temperamental, always save your work before attempting to do so.
There are three limits:
First, the texture names, including the _#, must be equal to or less than 8 characters plus extension. So, TestFile_1.gif will not be animated, but TestFi_1.gif will be.
Second, every frame in the animation must use the exact same palette. (For a guide on creating common palettes using Bright, click (
http://www.ttlg.com/forums/showthread.php?p=1322376#post1322376) here.
Third, I think the maximum number of frames you can use in a single animation is 20 (*_ through *_19) - however, you could use a carefully timed Model tweq to overcome this limit.
The rate (I haven't found a way to change it for objects yet) seems to be fixed at around 4fps.
You can change the animation rate for brush textures by applying the Renderer->Texture Anim Data to the texture's entry in the textures section of the object hierarchy.
Applying this property on any other type of object will crash DromEd.
From the modders_notes:
Code:
Max texture animation frames: 99 (from 20)
so now we can have MUCH (~5X better) animated textures. And can use PNGs for them. Has the filename length restriction ("texture names, including the _#, must be equal to or less than 8 characters plus extension") been lifted? I didn't see anything about that in the modders_notes, so I assume not. I also assume that the palette issues are now gone with support for png and tga. Very cool!
The Watcher on 29/9/2012 at 15:44
Quote Posted by release_notes.txt
- Increased the maximum number of frames allowed in animated textures from 20 to 99, and increased the allowable filename length for animated textures (before the underscore) to support more than 7
- Animated texture rate can now be specified via a material file for that texture
Doesn't say how much the filename length has been increased by, though. And that second point looks like it'll be really useful...
LarryG on 29/9/2012 at 16:00
I wish there were a "material file" example of that, and, IIRC, I think I read that material files only apply to mesh and object textures, not bitmaps. If so, then no speed control over animated bitmaps. But who's complaining? I'm reading the material_format.txt notes just now, and found this:
Code:
ani_rate <int>
--------------
Animation rate, specified as milliseconds per frame, for animated textures. Default is 250.
The "Texture Anim Data" property in DromEd overrides any material setting, unless "force_ani_settings" is
set. If the texture isn't animated the parameter is ignored. This parameter only has an effect on objects
where "Texture Anim Data" would also have an effect.
Ex:
ani_rate 33
ani_frames <int>
----------------
Animation frames. Default is 0, which means the frame count is determined by the number of files found.
While not required it may be good practice to set this param, this avoids conflicts with other mods. For
example if one mod overrides the water textures and has 15 frames, then another mod has 20 frames. Without
setting ani_frames this can result in 15 frames from one mod being used and the last 5 frames from the other.
If the texture isn't animated the parameter is ignored.
Ex:
ani_frames 20
ani_mode <"WRAP" | "REVERSE" | "PINGPONG">+
----------------------------------------------------
Animation mode flags, related to the "Texture Anim Data" property, one or several flags can be specified
separated with spaces. Default is WRAP. PINGPONG and WRAP are mutually exclusive. The "Texture Anim Data"
property overrides any material setting, unless "force_ani_settings" is set. If the texture isn't animated
the parameter is ignored. This parameter only has an effect on objects where "Texture Anim Data" would also
have an effect.
Ex:
ani_mode WRAP REVERSE
ani_mode RAND
force_ani_settings [<0,1>]
--------------------------
Apply material animation rate and mode settings even if the texture has a "Texture Anim Data" property.
If I read this correctly,
[INDENT]ani_rate 33[/INDENT]
is faster than
[INDENT]ani_rate 250[/INDENT]
Because with
[INDENT]ani_rate 33[/INDENT]
you get each frame shown for only 33 milisecs before the next frame is shown, where
[INDENT]ani_rate 250[/INDENT]
has each frame shown for 250 milisecs. Is that right? No mention of how slow you can go ... 1000 (=1 frame per second) ?
NOTE TO MODERATORS: maybe all this texture stuff should be moved to it's own thread?
