[sldev] Reformatting Textures for the cache

[Tim Shephard]

sqllite, as proposed by jippen is the way to go.

On 3/22/07, Skal Tura <skaltura at gmail.com> wrote:
> 2007/3/22, Jippen <cheetahmorph at gmail.com>:
> > MD5 hash? you must be joking! We _already_ have a perfectly useable
> > way to do lookups! All images have a uuid. All you would need would be
> > a basic sqlite table with uuid->filename lookups, or even just store
> > them in the cache as "
> 5748decc-f629-461c-9a36-a35a221fe21f.tga", etc.
> > And, lets face it, if someone wants to use that trick to steal
> > textures, they would be willing to steal them out of video ram or
> > using thier own modded client to do so.
> >
> > I'm just proposing something that make sense to me. Might not work as
> > well for objects or avatars, but it would do quite well for textures,
> > which seem to be the biggest hog anyways.
> >
> >
>
> You are completely right on the MD5 vs UUID, wasn't thinking applicaton
> specific there.
> To save memory i would get rid of - chars and .tga :) not much, but even
> there's plenty of memory to fool around with, every byte still counts, don't
> do memory hogs, make efficient use of memory ;)
>
> Oh, and i'd prefer to use full blown MySQL but i haven't digged out would
> there be an efficient way of distributing and controlling it application
> specific. I know that some statistical software use it and has
> auto-installer and everything, but conflicts if you already have MySQL, and
> it needs to be 0-click thing for mainstream.
>
> Can handling dynamic data within memory go much faster than what MySQL does?
> Ofc, building inside app would be more faster as no interfacing would be
> needed, but you get what i mean.
>
> Or would that be overkill? ;)
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>