Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Dan P. <ba...@al...>]

On Nov 28, 2005, at 7:58 AM, atani wrote:

> I am not sure the copy is needed.  Currently we have two blocks of  
> memory allocated for a texture, one in the original form (as loaded  
> from image file) and one in ARGB8888 form.  Both of these are in  
> RAM not VRAM.  Currently in lock/unlock we use the "original"  
> texture data and reconvert it to ARGB8888 on unlock.

If that's true, I think the ARGB8888 data is totally unnecessary. A  
good first step might be to free that up as soon as it's loaded with GL.

The reason I have it set up the way it's currently set up is because  
of exactly what Mike's talking about. I had some stuff that would  
stuff a new generated texture in each frame. What might be nicer is  
to specify somewhere that the texture will be used for that sort of  
purpose, and to keep the original form around. We can then move to GL- 
only textures for about 99% of the texture data and (especially on  
the DC) shortcut all those transforms and wasted memory. On those  
textures, lock()/unlock() would just fail.

> For Palette based textures though, the original form is required to  
> ensure proper color mapping.  It would be very slow to process the  
> ARGB8888 data back to palette data and then diff it to "current  
> palette" to get the new values.

Keep in mind too that the DC has hardware paletted texture support.  
So there might be something clever to be done there too.