[CLOSED] Texture loading classes

[broumbroum]

Hi everyone,

I've been working on a texture loading class, based on my own projects ones. Since some people are wishing very much to add them into LWJGL (http://lwjgl.org/forum/index.php/topic,2886.msg19976.html#msg19976  ) here are the updated/debugged files to possibly implement in the next release . (there's a TextureTest class)

see patches below

have fun ! 

EDIT : Important Note :
please report on the poll above for what system do you run with this LWJGL RFE ! THX

[broumbroum]

Did someone test this package on different platforms : Mac OS X, Linux, Windows and (deprecated ?) Solaris ?

[kappa]

I think it'll probably be best to wrap this up into a small standalone library that can be used with LWJGL.

I say this mainly because there are already a few options available for loading textures like MatthiasM's PNGDecoder and JPEGDecoder, Slick-Util, Devil, JME (also has its own classes), Ardor3D (also has its own), AWT, etc.

So to remain lightweight and neutral best to avoid having such a thing directly inside LWJGL. You could however link it up on the LWJGL Wiki and write a tutorial or two on there so users can easily find it and use it with LWJGL.

[princec]

I second kappa's opinion there. We were a bit naughty with the vector classes and other stuff that sneaked their way in there in the first place, don't want to let it keep creeping larger and larger...

Cas

[kappa]

We were a bit naughty with the vector classes and other stuff that sneaked their way in there in the first place

Yeh, some of those parts are now unmaintained and prune to code rot. Having a quick look in the util package it might be an idea to spin of some parts into a separate project/library since I don't think many use them so are just dead weight for the library. This would include the vector, matrix, shapes (like Rectangles, Points) and color classes. There are much nicer alternative 3rd party libraries available for these bits these days.

Also why is there another class called Display in there?! Should probably be renamed to DisplayUtil or something to avoid confusion/conflict.

[broumbroum]

Well i don t really agree with you Kappa for a couple of reasons :
-unlike other libraries, its very small amount of files to include,
-like other lwjgl utils, it turns out into 1-2 lines of code, e.g. loading sound with lwjgl Wavedata.
-unlike other opengl libraries, the coder is still aware of much of the opengl coding 'i.e. the texture still has to be uploaded into the graphics ram.

Now I dont have any kind of Display class to add. You are mistaken. it s just about the org.lwjgjl.util package.

I wont publish a separate library for so a few amount of code. I apologize for this.^^ Anyway, everyone can test this Texture rfe and report for any enhancement here. Its part of the job to test and give us some feedback. :-)

[elias4444]

There are much nicer alternative 3rd party libraries available for these bits these days.

Do you have any particular recommendations? It might help those that are just starting (and maybe some of us who've even been hiding in the background for a few years now ).

[kappa]

There are much nicer alternative 3rd party libraries available for these bits these days.

Do you have any particular recommendations? It might help those that are just starting (and maybe some of us who've even been hiding in the background for a few years now ).

- Vecmath library seems like a nice attempt at a common Math API (used by jBullet, jPCT, etc).
- Xith3D uses a nice standalone library called OpenMali, seems pretty complete.
- Both jMonkeyEngine and Ardor3D have had nice maths packages from a long time, which I've occasionally pinched bits from.
- LibGDX has a really nice and small maths package, seems pretty optimised.

The above bits of code are either BSD licence or similarly liberal, so shouldn't be any problems in using them.

[princec]

If we're going to flat-out remove API from LWJGL, even in the util packages, we should probably bump the major version number to 3.0 and think about cleaning up all the other little idiosyncrasies and inconsistencies.

Cas

[broumbroum]

Sure, 3.0 is the next step. Thoroughly to implementing MORE instead of removing. I think about including this RFE,  which makes sense to improving the coding experience on lwjgl.

[jediTofu]

I think that this would be best included in a separate lwjgl jar, like lwjgl-ex or something.  And all new middle-ware code would be there.

However, it would be good to keep the old math/vector stuff already present in LWJGL so old code doesn't break if the programmer wants to use the newest jars.

[broumbroum]

+1 for your suggest.