Slick Forums

Hello,

I am working at a project that involves loading a large number of grayscale textures stored as PNGs. Sadly the fast PNG loader and the texture loader are not able to handle such images and so they are converted to RGBA images by the very slow native Java image loader.

That is a state I really dislike and I got already a tested proposal on how to change this. Checkout my patch:

Based on the first tests this changes work smooth and fast. I hope you can use it.

Nitram

awesome martin

does it use a single channel texture also?

Who do I need to poke to get this patch considered to be added to the SVN state?

Nitram

Now as Slick got a bunch of new developers I'd like to bump this patch once more into consideration.

Nitram

I want to point out that the PNGDecoder used in Slick is a cut down version of an early version of . And it also does a lot of unnecessary memory copies - so maybe instead of patching it to support a few more formats it should be replaced with the latest version which supports many more PNG formats.

Good point, Matthias!
Does your current PNGLoader support the formats Nitram mentions? Or would you be willing to add them if not?

_________________
|
| |

This patch does not alter the PNG Decoder that is implemented in Slick. Updating this one to a later version can be done separated from this patch.

This patch does how ever use the ability of the PNG Decoder to load non-RGBA graphics and load those graphics as the best fitting OpenGL texture type. So currently if you put in a grayscale texture, the internal texture loader will reject the loaded data from the PNGDecoder and load the image using the IIO-based decoder. This decoder also converts any image to a RGBA image. The texture loader then loads the graphic that is now a RGBA texture for sure into OpenGL. My patch changes this behavior by adding the ability to Slick to load RGB, Grayscale-Alpha and Grayscale images directly into OpenGL.

Nitram

Bump!

Anything?

As I said, my patch does not effect the PNGDecoder implementation in any what what so ever. It just improves the way Slick uses the information received from the PNGDecoder. If a old PNGDecoder is used or a updated one does not matter. How ever after all a updated one would surely be preferred

Nitram