I'd like to replace defaultfont.tga - 1 MB - with defaultfont.png - 40 KB (same content). Is there anything I am missing?
Swing dependency? (the TGA loader is the only "native" loader that we have, aside from DDS afaik). Also I think the size in the .jar (compressed) is probably a lot closer to the png size (since a .png uses almost the exact same compression as jar). It'll still improve CVS checkout times though.
Not that I actually care about any of my arguments, go for it, I'd say 
llama said:
Also I think the size in the .jar (compressed) is probably a lot closer to the png size
:-o indeed (28KB), didn't realize that. That makes it really less important to change
With PNGOUT it’s only 15,2 kB (15.595 bytes). Then again if we rezipped the jME jars with Kzip (the compression engine behind PNGOUT), everything in the jars would be a lot smaller too.
Funnily enough that’s twice today I mention kzip in the jME forums KZip/PNGOUT
TGA has true alpha channel support whereas PNG does not… for some reason I am under the impression that this could matter for crisp looking fonts. Would be nice to have a native png loader btw.
renanse said:
TGA has true alpha channel support whereas PNG does not...
:? png does have alpha - and it works fine
You might want to look at those libraries if you're writing the png loader: Image Saving Toolkit for Java Images (JVG/JIS)
they are under LGPL though.
I think you're confusing JPG and PNG a bit…?
PNG can have a full 8 bit alpha channel… they can also have an indexed pallette with a transparent color. Compression is always lossless (it's just good old deflate like in pkzip, jar, gzip, etc).
<— My user icon for instance is a PNG with partial tranparancy (you'll need a non-IE browser to see that though)
renanse said:
TGA has true alpha channel support whereas PNG does not... for some reason I am under the impression that this could matter for crisp looking fonts. Would be nice to have a native png loader btw. :)
I thought Java (from 1.3) had a built in Toolkit.getImage() loader for PNGs, also, javax.imageio supports encoding PNG images natively since 1.4 :?
I think there's confusing terms of the words "native" here. With native we mean "jme's" and not Swing's. This is so you can throw out Swing when you package your game with a JRE or for instance compile it with JET.
But isn't Toolkit part of the base Java language? (in other words, not part of swing). If so, perhaps a subset of JAI would be better, since they include ImageReader for PNGs?
The javax.imaging package loads the images as BufferedImage (package java.awt.image), and that class uses a large portion of the image handling APIs from AWT.
Even though Toolkit is supposed to be part of the java language, many 3rd party java implementors do not support it (gcj for example).
The problem is it depends on Swing so it's not easy to strip down (possible but hard). The standard Java API does not expose any kind of image loading that does not depend on Swing afaik. There's 3rd party libs that do though (eg LWJGL wraps DevIL/OpenIL).
llama said:
I think you're confusing JPG and PNG a bit..?
PNG can have a full 8 bit alpha channel.. they can also have an indexed pallette with a transparent color. Compression is always lossless (it's just good old deflate like in pkzip, jar, gzip, etc).
<--- My user icon for instance is a PNG with partial tranparancy (you'll need a non-IE browser to see that though)
No, I know that PNGs support transparency, but I was under the impression that it was only transparent color since I generally do not see an alpha channel when I load a PNG into photoshop.
Edit: this is probably from my previous life making websites since IE 6 and previous only supported that kind of png transparency. :/