Slightly confused by this implementation, but is it right that in order to use this new feature you have to extend the TGALoader and override the getNewWidth() and getNewHeight() methods in order to resize the texture? If so, you are essentially resizing every texture that's being loaded by this loader regardless if it's smaller or larger.

On another note I thought the Graphics api was notoriously bad at resizing images when resizing by a large amount of pixels (quality wise I mean).

What is your business case for this if I may ask? Why could you not just resize the texture before shipping it with your application in the first place?

I did it to be able to implement centralized configuration of quality of textures in my game.

So this means you will be shipping larger textures and then downscaling in your code at runtime/load time?

Does that not also mean you will be shipping several more megabytes of data for the client to download than what your application will be using?

Or are you simply saying that you ship large textures with the application and then the users can select what quality they want in the application?

I'm using it in offline client. It gives me the opportunity not to have storage options of different textures. I use Scalar in my loader to scale, which is able to use different algorithms.

Rejecting this due to usage of awt classes.

A JME wide logic for resizing images at load is something I would like to see however, as shipping all textures with half resolution would add a heavy +40% in download size. I think some global implementation based on the mippmaps might be interesting here.

In my opinion TGALoader should take care of resize of the image, at the algorithm not as a extension, that is if i understood well the problem