A few things that might be nice to think about at some point... Post your thoughts.
- Slick forces textures to be power of two. Non power of two textures (NPOT) have been supported since OpenGL 2.0 and earlier (with the extension), and most computers these days can use them. I vote we add the following to InternalTextureLoader:
- setForcePOT / isForcePOT -> forces all images to be loaded into POT textures (true by default for backwards compatibility)
- isNPOTSupported -> checks compatibility, returns true if the system can use NPOT textures
- Then change image decoders so that they don't force POT textures. It's bad practice, anyways... If you were to use image decoders on their own (i.e. outside of OpenGL context) would you expect them to return only POT data??! Instead, the POT fix should be placed in InternalTextureLoader. And instead of padding the extra space by manually looping through and adding transparent pixels, we could simply glTexImage2D with an empty byte buffer to create the full-sized image, then glTexSubImage2D with the image data to upload the image itself. This is cleaner and (should be) faster.
- There is no way to specify internal formats for loaded textures. This would be nice, especially now that we have Nitram's ImageData.Format class.
- We could also add some helper methods to TextureImpl: upload (uses glTexSubImage2D), setWrap (clamp/repeat/etc)
- InternalTextureLoader uses a lot of repeated/ugly code -- things like get2Fold can be cleaned up with a better algorithm, createIntBuffer can (probably) be replaced by BufferUtils, we can minimize clutter by having texture creation route to a single private method, etc.
- Maybe TextureLoader should be made more Slick-friendly at some point since it's meant to be the "rational interface" to InternalTextureLoader, i.e. add more method overloading, throw a SlickException instead of IOException (breaks compatibility), add a createTexture method for empty textures, etc.
- Texture reloading seems buggy/messy -- not really suitable for public use at the moment IMO, and it really only seems to be used for Slick-AE. For example, InternalTextureLoader.reload(...) doesn't change the Texture's ID -- is this a bug? And TextureImpl.reload() does nothing unless setHoldTextureData was true when InternalTextureLoader created the texture (or the user explicitly calls setTextureData). In short... we could maybe fix that up too.
Overall, it should mostly be doable with backwards compatibility (overloading methods etc). Unless a game depends on Slick's image decoders to return POT-padded byte buffers, which is just plain silly...
