paletted textures and bilinear filtering?

[saski]

hello,

I would like to use paletted textures for my sprite engine to save texture memory. doing the palette lookup is easily done in the fragment program. however I need bilinear filtering enabled and since I use the fragment program I guess I have to write a bilinear interpolation algorithm myself after the palette lookup, right?

my concern now is the the performance impact by doing the filtering in the fragment program. when does opengl (fixed pipeline) internally do the filtering anyway? once when passing the texture parameter after upload or each time during the render process?

is there a best practise?

thx in advance for any advice!

regards
saski

[menzel]

Hello,

yes, you would have to look up 4 texels with nearest (no interpolation) and interpolate in your shader.

That means: read out 4 texels with indices & read 4 texels with colors based on those indices -> 8 texture lookups and some simple arithmatic.

OpenGL would (in case of bilinear filtered RGBA textures) do just one lookup and interpolate (each time) in the texture units (which is as quick as one nearest lookup!).

There will be a performance penalty, depending on the complexity of your app it's possible that you will not realy notice it.
BUT: why do you want to use indexed textures in the first place? To save texture memory you can look into compressed textures as well. This can save even more memory than indexed textures!

[saski]

hi!
thanks for your input. is there any sample shader code for the texel lookup availble? I'm pretty new to glsl and could use a little heads up ;-). you're absolutely right regarding texture compression. it's easy and cuts ~60% off the memory comsumption. however my sprite textures (from the 1993 fps doom) are very low resolution and look terrible after "wrangling" them through the s3 compression stage :-(.

regards,
saski

[tanzanite]

...I would like to use paletted textures for my sprite engine to save texture memory...

hi!
...from the 1993 fps doom...

Does not compute. The whole level worth of textures/sprites fits in 2MB. 4*4(RGBA)=16MB. I can not remember when i last saw a GPU with less than 256MB available.

[saski]

well it's a project targeted for opengl ES 2.0 embedded systems with ~32MB texture memory availble.
and btw. enemy sprites in doom are composed of multiple frames with 8 different view angles. thas makes up to 50 textures for one single enemy @ ~50x100 rgba pixels. uploading them to the gpu umcompressed takes 30-40MB for all different sprites during gameplay. but you're right. descrete gpus from this decade shouldn't have a problem with that - even intel on board gpus with shared memory.

saski