Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#Actualcr88192

Posted 25 March 2013 - 03:23 PM

yes, for example (for DXT5):

http://pastebin.com/8rq3z5F5

http://pastebin.com/8Sga1sd6

 

which basically try to do DXT5 compression reasonably quickly by reducing the process mostly to fixed-point arithmetic and bit-twiddly.

however, there is no real internal feedback or search for an optimal encoding, so the quality is basically "whatever the fixed point-math spits out".

 

 

there was also some fiddling with a non-DDS DXTn based format (which added a secondary LZ77 compression stage), mostly intended for video-decoding usage (to be cheaper to decode than my current usage of M-JPEG for video-map textures).

 

for the most part, I have just been loading PNG and JPEG images and converting to DXTn on load (post mipmap though, at least at present), as it has generally been "good enough"...

 

naively, LZ77 can reduce DXT5 to 1/2 its size by generally compressing down the often highly-redundant alpha-channel, but a lossy block-reduction filter can further increase compression... however, for size/quality tradeoffs (with on-disk storage), JPEG and PNG still have an advantage here in my tests.

 

 

ADD:

note that mipmaps aren't actually hard to generate.

basically, at each level you are dividing the X and Y resolution in half, and roughly averaging 4 pixels into a single pixel.

 

say, pixels:

A B

C D

become

P

 

so: P=(A+B+C+D)/4

 

in the simple case, this is basically done for all of the image pixels and for each component, and is basically repeated each time to generate each new mip-level.

 

slightly higher quality for alpha-blended images can be gained like this:

Ta=Aa+Ba+Ca+Da (where Aa=A's alpha, and Ta=Total alpha).

P=A*(Aa/Ta)+B*(Ba/Ta)+C*(Ca/Ta)+D*(Da/Ta)

 

or alternatively (Argb = RGB for A):

Prgb=Argb*(Aa/Ta)+Brgb*(Ba/Ta)+Crgb*(Ca/Ta)+Drgb*(Da/Ta)

Pa=Ta/4

 

then, each mipmap level can be converted into DXTn.

 

 

in actual code, this typically results in 2 levels of "for" loops (one for Y and one for X), with some math in the middle.

 

note that in the latter strategy (where Ta is used), a few special cases may need special handling: Ta=0 and Ta=1020, where a fallback to the original (simple average) strategy may be used. this also requires either fixed or floating point arithmetic (since with plain integer arithmetic, say, 240/960 will always give 0), or possibly alternatively something like (Argb*Aa)/Ta.


#4cr88192

Posted 25 March 2013 - 03:21 PM

yes, for example (for DXT5):

http://pastebin.com/8rq3z5F5

http://pastebin.com/8Sga1sd6

 

which basically try to do DXT5 compression reasonably quickly by reducing the process mostly to fixed-point arithmetic and bit-twiddly.

however, there is no real internal feedback or search for an optimal encoding, so the quality is basically "whatever the fixed point-math spits out".

 

 

there was also some fiddling with a non-DDS DXTn based format (which added a secondary LZ77 compression stage), mostly intended for video-decoding usage (to be cheaper to decode than my current usage of M-JPEG for video-map textures).

 

for the most part, I have just been loading PNG and JPEG images and converting to DXTn on load (post mipmap though, at least at present), as it has generally been "good enough"...

 

naively, LZ77 can reduce DXT5 to 1/2 its size by generally compressing down the often highly-redundant alpha-channel, but a lossy block-reduction filter can further increase compression... however, for size/quality tradeoffs (with on-disk storage), JPEG and PNG still have an advantage here in my tests.

 

 

ADD:

note that mipmaps aren't actually hard to generate.

basically, at each level you are dividing the X and Y resolution in half, and roughly averaging 4 pixels into a single pixel.

 

say, pixels:

A B

C D

become

P

 

so: P=(A+B+C+D)/4

 

in the simple case, this is basically done for all of the image pixels and for each component, and is basically repeated each time to generate each new mip-level.

 

slightly higher quality for alpha-blended images can be gained like this:

Ta=Aa+Ba+Ca+Da (where Aa=A's alpha).

P=A*(Aa/Ta)+B*(Ba/Ta)+C*(Ca/Ta)+D*(Da/Ta)

 

or alternatively (Argb = RGB for A):

Prgb=Argb*(Aa/Ta)+Brgb*(Ba/Ta)+Crgb*(Ca/Ta)+Drgb*(Da/Ta)

Pa=Ta/4

 

then, each mipmap level can be converted into DXTn.

 

 

in actual code, this typically results in 2 levels of "for" loops (one for Y and one for X), with some math in the middle.

 

note that in the latter strategy (where Ta is used), a few special cases may need special handling: Ta=0 and Ta=1020, where a fallback to the original (simple average) strategy may be used. this also requires either fixed or floating point arithmetic (since with plain integer arithmetic, say, 240/960 will always give 0), or possibly alternatively something like (Argb*Aa)/Ta.


#3cr88192

Posted 25 March 2013 - 03:14 PM

yes, for example (for DXT5):

http://pastebin.com/8rq3z5F5

http://pastebin.com/8Sga1sd6

 

which basically try to do DXT5 compression reasonably quickly by reducing the process mostly to fixed-point arithmetic and bit-twiddly.

however, there is no real internal feedback or search for an optimal encoding, so the quality is basically "whatever the fixed point-math spits out".

 

 

there was also some fiddling with a non-DDS DXTn based format (which added a secondary LZ77 compression stage), mostly intended for video-decoding usage (to be cheaper to decode than my current usage of M-JPEG for video-map textures).

 

for the most part, I have just been loading PNG and JPEG images and converting to DXTn on load (post mipmap though, at least at present), as it has generally been "good enough"...

 

naively, LZ77 can reduce DXT5 to 1/2 its size by generally compressing down the often highly-redundant alpha-channel, but a lossy block-reduction filter can further increase compression... however, for size/quality tradeoffs (with on-disk storage), JPEG and PNG still have an advantage here in my tests.

 

 

ADD:

note that mipmaps aren't actually hard to generate.

basically, at each level you are dividing the X and Y resolution in half, and roughly averaging 4 pixels into a single pixel.

 

say, pixels:

A B

C D

become

P

 

so: P=(A+B+C+D)/4

 

in the simple case, this is basically done for all of the image pixels and for each component, and is basically repeated each time to generate each new mip-level.

 

slightly higher quality for alpha-blended images can be gained like this:

Ta=Aa+Ba+Ca+Da (where Aa=A's alpha).

P=A*(Aa/Ta)+B*(Ba/Ta)+C*(Ca/Ta)+D*(Da/Ta)

 

or alternatively (Argb = RGB for A):

Prgb=Argb*(Aa/Ta)+Brgb*(Ba/Ta)+Crgb*(Ca/Ta)+Drgb*(Da/Ta)

Pa=Ta/4

 

then, each mipmap level can be converted into DXTn.

 

 

in actual code, this typically results in 2 levels of "for" loops (one for Y and one for X), with some math in the middle.

 

note that in the latter strategy (where Ta is used), a few special cases may need special handling: Ta=0 and Ta=1020, where a fallback to the original (simple average) strategy may be used. this also requires either fixed or floating point arithmetic (since with plain integer arithmetic, say, 240/960 will always give 0).


#2cr88192

Posted 25 March 2013 - 03:07 PM

yes, for example (for DXT5):

http://pastebin.com/8rq3z5F5

http://pastebin.com/8Sga1sd6

 

which basically try to do DXT5 compression reasonably quickly by reducing the process mostly to fixed-point arithmetic and bit-twiddly.

however, there is no real internal feedback or search for an optimal encoding, so the quality is basically "whatever the fixed point-math spits out".

 

 

there was also some fiddling with a non-DDS DXTn based format (which added a secondary LZ77 compression stage), mostly intended for video-decoding usage (to be cheaper to decode than my current usage of M-JPEG for video-map textures).

 

for the most part, I have just been loading PNG and JPEG images and converting to DXTn on load (post mipmap though, at least at present), as it has generally been "good enough"...

 

naively, LZ77 can reduce DXT5 to 1/2 its size by generally compressing down the often highly-redundant alpha-channel, but a lossy block-reduction filter can further increase compression... however, for size/quality tradeoffs (with on-disk storage), JPEG and PNG still have an advantage here in my tests.

 

 

ADD:

note that mipmaps aren't actually hard to generate.

basically, at each level you are dividing the X and Y resolution in half, and roughly averaging 4 pixels into a single pixel.

 

say, pixels:

A B

C D

become

P

 

so: P=(A+B+C+D)/4

 

in the simple case, this is basically done for all of the image pixels and for each component, and is basically repeated each time to generate each new mip-level.

 

slightly higher quality for alpha-blended images can be gained like this:

Ta=Aa+Ba+Ca+Da (where Aa=A's alpha).

P=A*(Aa/Ta)+B*(Ba/Ta)+C*(Ca/Ta)+D*(Da/Ta)

 

or alternatively (Argb = RGB for A):

Prgb=Argb*(Aa/Ta)+Brgb*(Ba/Ta)+Crgb*(Ca/Ta)+Drgb*(Da/Ta)

Pa=Ta/4

 

then, each mipmap level can be converted into DXTn.

 

 

in actual code, this typically results in 2 levels of "for" loops (one for Y and one for X), with some math in the middle.


#1cr88192

Posted 25 March 2013 - 12:37 PM

yes, for example (for DXT5):

http://pastebin.com/8rq3z5F5

http://pastebin.com/8Sga1sd6

 

which basically try to do DXT5 compression reasonably quickly by reducing the process mostly to fixed-point arithmetic and bit-twiddly.

however, there is no real internal feedback or search for an optimal encoding, so the quality is basically "whatever the fixed point-math spits out".

 

 

there was also some fiddling with a non-DDS DXTn based format (which added a secondary LZ77 compression stage), mostly intended for video-decoding usage (to be cheaper to decode than my current usage of M-JPEG for video-map textures).

 

for the most part, I have just been loading PNG and JPEG images and converting to DXTn on load (post mipmap though, at least at present), as it has generally been "good enough"...

 

naively, LZ77 can reduce DXT5 to 1/2 its size by generally compressing down the often highly-redundant alpha-channel, but a lossy block-reduction filter can further increase compression... however, for size/quality tradeoffs (with on-disk storage), JPEG and PNG still have an advantage here in my tests.


PARTNERS