Slick Forums

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, if setForcePOT is false and isNPOTSupported returns true, Slick will not try to force textures into POT sizes.
• 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...

If it's not making anything worse why not? Go ahead and do it I say. As long as the end user does not need to handle anythin differently and still be able to use image.draw() or getSubImage() as expected I'm totally in for it.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

My computer is still unable to use OpenGL 2.0 (believe me, it's painfully inconvenient), but if you can keep it from breaking on earlier hardware, I think it's good.

_________________
"Artificial intelligence will never be a match for human stupidity" - "Jamos Kennedynos"

Another plus is that this wouldn't happen

I'd also say go for it, davedes.
You seem to be the most experienced in this area and your explanation sounds all reasonable.

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

Do we have a good way to handle FBO's/PBuffers? What I means is that we might want to give the developer an easy way to use an FBO for Post-Processing. Especially now where we have shaders (still using davedes version but you get my point).

Currently we have a FBOGraphics class which I don't really like. First of it takes an whole image... Imho a better way would be to just take the texture. Or even better have a C'Tor which just takes the width and height creating a new empty texture for us. Also I don't understand why bind and unbind are private in the current class :/

We might even want to abstract it so the dev can check on FBO or PBuffer and use what's supported?

Just some ideas I had

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

I like the idea of giving more power to the user -- since these classes are pretty much invisible to the user at the moment, we can go wild changing them. I'm also not a huge fan of my createOffscreenImage fix -- it's useful as a temporary workaround but ideally we should have something a bit cleaner, maybe something that ties in with changes we'd like to make to FBO/PBuffer stuff.

For my game, I made my own FBO implementation that doesn't depend on Graphics -- which makes it more useful for people like me (who do custom "low-level" rendering instead of relying on Graphics). It would also be useful as a standalone utility for Slick-Util users. We could write something similar for PBuffer/PBufferUnique, then implement these using Graphics with, say, an OffscreenGraphics class (which decides whether to use FBO/PBuffer/PBufferUnique).
FBO.java
TextureUtils.java

Some things my FBO does differently:

• Doesn't depend on enabling/disabling Graphics; instead uses the more OpenGL-like bind()/unbind() convention
• Doesn't use SlickCallable -- meaning bind/unbind is a bit faster
• Doesn't push ALL client attributes each bind; and allows advanced user to specify which attributes to push (or none at all)
• Allows for NPOT texture size; useful for making full-screen FBOs that need a particular clamp to display borders (i.e. clamp to edge)