I just learned about randomly tileable texture sets in The Dark Side of Game Texturing. Is there a way to utilize them in Unity without scripting?
…Then, I read about palettizing textures:
“The programmers of games like Half-Life and Unreal force artists to palettize their textures, or convert their artwork to use a self-contained palette consisting of only 256 (8-bit) colors. This will help to dramatically speed up the game without much loss of texture quality (sort of).”
What about that technique? If it, say, helped for iPhone games, I’d probably want to use it.
That seems to be quite a bit out of date…I’m not sure graphics cards can even do 8-bit textures anymore. With the iPhone, you have PVRTC compression. As I understand it, palettized textures are actually slower because you’d have to read both the color and the index.
–Eric
The book is from 2004, and it sounded that way. However, while I thought that the palettizing could possibly be specifically useful on the iPhone (I know relatively little about hardware), I figured the random tiling could be useful on any platform.
This might have been true in 1999 (about the time when original HalfLife and Unreal were released). Since 2000, I think no graphics card supports palettized textures.
Why? Because to read a pixel from a texture with a palette, the hardware needs to do two consecutive memory reads (one to get the index, another to read actual color from a palette). Which is twice the latency of an ordinary read.
Hardware uses other compression schemes nowadays, that don’t require multiple consecutive reads (like DXT on regular platforms, PVRTC on iPhone etc.)
What is random tiling?
hmm, I can see a repeating pattern on that second image ?!?
I would also like to chime in on colour palletes.
With my TGA textures in photoshop I often convert them from RGB to Index colour and drop the colour count to around 32 or 64 (basically I keep lowering the colour value until i start to see a difference). In the “other” engine I use (which is old and based on DX7) this has a big impact on in memory texture size. Doing this on a recent project I went from using 120MB of texture memory to 40MB of run-time texture memory.
So my experience on this is different to what you said above.
EDIT: forgot to mention that I still save as 32bit TGA
Ta
Geoff
There’s a difference between “how much memory on disk” versus “how much memory on the graphics card”. Sure, storing a texture at 4 bits/pixel palettized (16 colors in total) uses less disk memory. But no graphics card made in the last 5+ years supports palettized textures. So what actually happens is that those 4 bits/pixel get expanded into 16 bits/pixel or 32 bits/pixel RGBA texture on the graphics card.
DXT1, on the other hand, is 4 bits/pixel, and can support much more than 16 colors per whole image. It is lossy compression as well, but in majority of cases much better than palette texture compression. And even more, DXT1 texture stays at 4 bits/pixel on the graphics card.
If you save as 32 bit TGA, then it should not matter at all how many actual colors are used. Texture is 32 bits/pixel on disk, and 32 bits/pixel on the graphics card. Yes, if you zip that texture on disk, then it’s likely to compress better if it has fewer colors. But that’s about it.
There’s no way graphics cards don’t support palettized textures anymore - forget memory size and performance, there’s other reasons why palette textures are useful, and exactly why I was searching for them on the forum and found this post.
I’m working on a game in Unity that uses sprites for the characters, I want people to be able to swap in and out schemes on their character - the best way to do this(off the top of my head) would be to use indexed or palette textures - then save a series of these alternate palettes. The other option would be to make variations of the sprite sheet, but that’s ridiculous. I want one sheet, multiple palettes, makes perfect sense.
Anyone know if this is possible in Unity?
If it is true that cards don’t support indexed color images, does that mean it’s impossible to use indexed images in Unity?
Hardware has stopped supporting paletized textures around Geforce 1 a decade ago for true 3D cards.
Intel, SiS and some lower S3 cards might have supported them longer but only because those cards had no hardware 3d till half way through the decade.
As Aras mentioned, for the past years no card manufactured even has any kind of paletized texture support anymore.
if you don’t care about performance paletized textures can partially be replicate through usage of pixel shaders though by mapping colors to colors of the “palette texture” and alike.
But its really questionable what you get performance wise from that.
Wow - so because we’ve got new cards and such, we’ve actually lost functionality, way to go technology.
Ok, so a shader method(yay overkill alternatives sigh…) not too familiar with shader language unfortunately, anyone point me in the right direction for an “indexed color” shader using some form or another of a “palette?”
I agree palettes are way way way old-school from the days when a 256-color display was new, and slow, like, in the 1990’s. Truecolor displays nowadays are both faster and have many more colors.
This discussion did, however, remind me of the HAM (Hold And Modify) mode on the Amiga computer - using 6 or 8 bit code bytes, you could either use one of 16 or 64 full palette colors, or modify the value of the previous pixel’s color in one of the color components only, with 18-bit color accuracy (262000 colors). The only major problem is color bleeding but it can be mostly avoided with a good palette, or multiple palettes (sliced HAM). A modified version could use 16-bit data per pixel for much more accurate ability to modify 2 color components per pixel, or to draw from a 16384 color palette.
It could give you good storage size, the only problem is it’s not necessarily faster. If you have to lookup 3 x 8-bit values in a palette, whether it’s stored in a texture or whatever, plus looking up the code word byte, that’s still as much lookup as a regular truecolor image and requires two texture fetches instead of one. Maybe if you’re doing lots of modify rather than new color codes for each pixel, maybe it would actually be faster? The only major issue I see is that the GPU doesn’t deal with pixels from left to right, it does any number of pixels all at once in parallel, which makes the algorithm much more difficult to figure out and maybe not possible at all.
One thing that springs to mind though is if you have an 8-bit paletted image and a palette texture, the palette texture would be very small (256 x 1 RGB = 768 bytes) and perhaps would be very fast in the texture cache? Even if it’s not faster, or slightly slower, you would at least be able to store up to 4 times as many textures in video ram? You could use a GL_I8 or GL_ALPHA8 texture to store the index bytes. So long as your texture is not too big or does not have too many color variations it could work out very well with a palette.
As for coloring sprites, it sounds like you could use a remapping shader… ie use a very simple texture as a palette to map from/to, then the shader would automatically pull colors from the texture and remap them on the fly. Not as fast as a regular truecolor render, though, so it remains dubious as to any benefit speed-wise - but would give you flexibility to recolor parts of the sprite, and is certainly more flexible than applying a color tint to the entire sprite.
Yeah, way to go technology, really!
If the designers of these card had to keep all the old dirty tricks supported, then where does it end… disc drives in computers supporting floppy disks. Blue Ray drives supporting Vhs. Cars having attachments for reins,. in case someone would still use horses.
Human breathing capability still supporting underwater environments (well, that WOULD actually be useful!).
Things move on. It would be a mess to keep outdated technology supported, just because of a few still usable features of it.
No we lost it because palette graphics were a stone age thing of the 2D age and were present on pure 2D cards only (DX6 and worse technically).
Matrox likely were among the few that decided to produce crap graphics cards with the idea of supporting unneeded 2D functionality longer.
They don’t work at all with performant 3D rendering.
If you don’t want to do performant 3D you can do what was done in the good old days by the cpu and “gpus”: go through each pixel and look it up in realtime (or whenever you switch palettes)
As for the “palette shader”: This requires a grayscale image and a palette image. Then in the shader you use the brightness of the color to define a U coordinate on the palette texture (-> max of 256 colors thus) and read the color from there.
So a brightness of say 120 would result in a u coord of 120/255 and you would then read the pixel with that coordinate.
The interesthing thing here is if you have a second parameter that allows you to control the V coordinate. then you can store up to 256 palettes in a single 256x256 palette texture …
All this is purely hypothetical basing on some toon shading shader I wrote last year (with fixed brightness steps instead of smooth lighting so technically not much different than a palette lookup)
Yeah yeah I get it, stone age, fine, just looking for a viable replacement for that kind of job then(Again, I’m not looking at it for performance, I’m looking at it so I can allow hundreds of “color schemes” but using the same sheet and just tinting won’t do the trick):
That sounds like a good option, however, as I said I am not very familiar with shader language. I guess I’ll check out the unity wiki to see if there’s a shader like that.
Thanks for the input, sorry if I raised anyone’s blood pressure, was just kind of shocked to hear it wasn’t going to be as simple as it used to be.
I made this; does it fit your needs? It’ll be especially awesome once Unity has batching across the board.
Thanks, Jessy - I’ll give this shader a spin and let you know how it goes.
You could always recreate what a palletized texture actually does, and store 8-bit “textures” that create 24-bit textures using SetPixel and a lookup table for the colors.
–Eric
I think Sidestepper’s frustration may be more about the fact that, as games have focused more on 3D, the tools that are hugely beneficial for 2D games have been given lower priority.
I am curious about Eric’s method, though.