Slick Forums

Discuss the Slick 2D Library
It is currently Sun Nov 19, 2017 3:06 am

All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Thu Mar 08, 2012 8:59 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
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... :P


Top
 Profile  
 
PostPosted: Fri Mar 09, 2012 8:51 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
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:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Sat Mar 10, 2012 4:49 am 
Offline
Oldbie
User avatar

Joined: Thu Jan 13, 2011 4:42 pm
Posts: 349
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"


Top
 Profile  
 
PostPosted: Sat Mar 10, 2012 4:54 am 
Another plus is that this wouldn't happen


Top
  
 
PostPosted: Sat Mar 10, 2012 10:07 am 
Offline
Game Developer

Joined: Sun Nov 12, 2006 11:18 pm
Posts: 890
Location: Germany
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


Top
 Profile  
 
PostPosted: Tue Mar 20, 2012 8:25 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
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:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Tue Mar 20, 2012 5:48 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
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)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group