Re: [cadcdev-tiki] TikiBlap Demo 0.1

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

On Nov 28, 2005, at 1:00 PM, atani wrote:

> This is the current allocations that I can spot in the code:
> Texture::loadFromFile(...):
>   m_ptr contains the "raw" image data
>   m_txrdata contains the ARGB8888 data used in the glTexImage2D call
>
> m_ptr can equal m_txrdata if the image file is in ARGB8888 format.   
> If not, m_ptr is allocated and the "raw" image data is memcpy into  
> it.  Ideally this can be avoided by moving "img" from being a  
> method variable to a class member variable and then m_ptr can be  
> destroyed (maybe).

Yeah, that sounds right.

> Here is what I suggest :)
>
> 1) Take current Texture class and rename it to DynamicTexture and  
> remove the support for loading image files.  This in effect would  
> become the "palette" based Texture class.
> 2) Create a new ImageTexture class that supports only loading from  
> a file.  Remove support for getPtr(), canvasLock(), canvasUnlock().
> 3) Move "common" bits to a new pure virtual Texture class so we can  
> still bind a Texture to Banner, etc.  Using a pure virtual class  
> would be good in this case since it can be treated as an  
> "interface" of sorts rather than a normal class.  However, a normal  
> class which we extend to add "extra" functionality would also work,  
> similar to Object.

That's not a bad plan. We've been discussing a lot of this design  
pattern stuff at work, re C++ commonly accepted practice. So I may  
take a shot at this soon. Maybe I'll actually have some time on it  
tonight if my wife doesn't lock her keys in the car again ;)

> True, the DC does have paletted textures, but IIRC the texture data  
> must be twiddled so we will need to keep that in mind as well.

Yeah, true. It might be nice to have some platform-specific support  
for pre-twiddled textures in there too, to avoid doing that  
processing at runtime if it's possible. Similar things could be done  
for DXT(?) encoded textures on GL platforms.