Re: Replicated textures

[Roger H. <rog...@mi...>]

On 13 Feb, 2007, at 20:41, James Walker wrote:

> Roger Holmes wrote:
>
>> Can I presume the edit index of the storage object is kept up to  
>> date?
>
> Good question.  Q3Storage_SetData bumps the edit index, but there are
> probably a number of other ways to change a storage object.  For
> instance, I suppose you could use Q3MemoryStorage_GetBuffer to get a
> pointer to the bytes, and then change some bytes, and the storage  
> object
> would have know way of knowing it was edited.

In the documentation and header file comments we would have to note
something like : If you modify a memory storage object, you must call
<The routine which increments the edited count> before calling the
hash routine, otherwise you may get the old value of the hash.
If we write a texture equal function, we would have to have the
same note for it too as it would call the hash routine.


>
>>>> The question is where to store the hashes. I could put them
>>>> in a custom attribute. This would be fine for me, but would
>>>> we be missing an opportunity. If they were stored in the
>>>> texture shaders or even the storage objects, would this
>>>> be of any use to either the renderers or the saving code
>>>> or anywhere else?
>>> It's not immediately obvious to me how it would be of use.
>>
>> Ok, but you have done the same as I'm going to so maybe it
>> would help the next person who wants to reinvent the wheel.
>>
>> Maybe we could have a method on the storage object which gives a
>> hash code. If we stored a cached value and the edit index (which
>> gets set to an invalid value in the NEW method) in the storage
>> object's header, then when we are asked for the hash, we compare
>> the edit indexes. If they match we return the cached value, if not
>> we update the copy of the edit index, hash the data block, store it
>> in the cache and return its value.
>>
>> The extra information in the header would not need to be saved
>> on disc.
>
> Of course, if it's a file storage, you'd have to read the file to
> compute the hash... though I don't know if anyone is likely to use a
> file storage for texture data.


Yes unlikely. Maybe we only support it for RAM storage objects.
Do file storage objects have an edit count? On disc they have a
last modified date we could use instead. But why make work for
ourselves which we don't expect anybody will ever use.

I suppose we could keep the hash routine private and only
expose a texture compare in the API.


Roger.