"Jon M. Taylor" wrote:
> On Mon, 4 Oct 1999, Club Neon wrote:
>
> > I can feel this falling from the GGI topic very fast...
> >
> > > > I am currently doing research on other ways to extremely compress images
> > > > (which allow for lossless modes), but that will take a while.
> > > Have you investigated wavelets?
> > > As I understand them, they get incredible compression, and the quality
> > loss
> > > isn't very bad.
> >
> > The key part of that sentence is "quality loss", even if it isn't very bad
> > there is still some.
This has gotton WAY off-topic, but...
>
> Get used to it, because texture compression in hardware is here to
> stay. People need to get used to machine-independent programming, and one
> aspect of that is that you have to give up pixel-accuracy and lossless
> compression. It is worth it, though, because you gain enormous
> flexibility and portability.
Compression has nothing to do with machine independency (unless you are saying
you want to run on legacy hardware). Infact, it goes aganst platform
independency. The new platform now must have a decoder written for it as well as
the development machine. The only reason you would want to compress is if you
have massive amounts of data (like video) or you are streeming it through a low
bandwidth pipe. No flexibility is gained. Avrage textures are about 512x512 and
including bump-maps and RGB coloring + alpha you might as well say 512x512x5. If
you have about 40 of these (which is about the amount you would use in an very
average game screen) you want no bottleneck like your decompressor to slow your
frame rates, even in hardware. After that, what about multi layered textures, and
I haven't even begun talking about double sided textures, or even multi-layered
double sided textures with alpha holes.
> > Also the important part is they aren't pixel accurate.
> > Sure the longer you spend decoding the wavelet the closer you get to the
> > orginal pixels. The problem with this is you can't be assured that when you
> > are storing data for a sprite it will be decoded the same every time, by
> > every machine.
>
> I got news for you, then: you have already lost that guarantee to
> hardware texture filtering, which blends depending on lighting
> characteristics and geometry.
Which is exactly why you need to have acurate pixels. If you don't, your texture
starts to look smeared Especily if you get really close to an object, or if the
object has alpha in obscure places.
>
> > Might not be so bad for non-tiled textures wrapped around
> > polygon solids, actually for organic things they might not tile to bad
> > either especially if they were used in multi-layered textures were the seams
> > can be obscured some.
>
> Precisely. Everyone is doing compressed textures.
Not me. If I did, my demos would turn to crap ( as if they don't already look
that way :-) )
But your right, for a simple game, compressed textures are fine. But if you want
arcade quality, don't do it ;-)
>
> > > I've played a bit with them, if you're curious:
> > > http://students.washington.edu/eeyem/old/wavelet/
> > > That's only 1d compression, but 2d compression is not much more difficult.
> > > You'd need a book/website, anyway.
>
> Aren't wavelets patented?
>
> Jon
>
> ---
> 'Cloning and the reprogramming of DNA is the first serious step in
> becoming one with God.'
> - Scientist G. Richard Seed
