. The use of a nested class is not necessary and to be honest, neither is the use of a static method to load the pixel data. The design of this as a whole is terrible IMO. You could handle the texture as an instance which would be better OOP, e.g:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

publicclassTexture {

privateintid;privateintwidth;privateintheight;

publicTexture(Stringpath) {// load the texture here... }

publicintgetId() {returnid; }

// getters for height and width...

}

This would also reduce the number of OpenGL functions the user has to implicitly call. Making everything static is not the way to go.

Static design is actually quite fine, and I use it in my GLUtils library, which I've used to make multiple games, so I have no idea why you think a static design is terrible. Your code should go something like this:

Also, of course it looks like the one in the tutorial series, that's the standard way of loading textures. Don't try to tell someone else they're wrong until you have more experience.

I was referring to the similarity of using static methods and intermediate mode. The reason I was saying that it was messier is because there is no need to use a nested class for handling the texture data. That's bad design. Also there's no standard way of loading textures. That's just the way most people do it using the Java API.

Second off, you say that the use of static should be avoided, I say a good programmer should use static when he/she needs to. Building your program entirely on a static model is probably not smart, but it's also not smart to completely avoid static like its the plague. I think you need to re-evaluate your use of static and realize that you can use, just you have to be careful with it. Not to mention the fact that statically calling a method like I showed you above is actually easier than creating a new instance of Texture manually, and has the same outcome.

Quote

Also there's no standard way of loading textures. That's just the way most people do it using the Java API.

This is not true. Everywhere I've looked, this is the general way people have loaded textures in OpenGL.

Second off, you say that the use of static should be avoided, I say a good programmer should use static when he/she needs to. Building your program entirely on a static model is probably not smart, but it's also not smart to completely avoid static like its the plague. I think you need to re-evaluate your use of static and realize that you can use, just you have to be careful with it. Not to mention the fact that statically calling a method like I showed you above is actually easier than creating a new instance of Texture manually, and has the same outcome.

I don't see much difference between

Texturetexture = newTexture("rgirn.png")

and

Texturetexture = Texture.loadTexture("rgirn.png")

. When I say you should avoid the use of statics wherever possible I mean you should avoid the use of statics wherever possible. If you had a House class there is no reason to use a static method to create a House object, thus I don't see a reason to use a static method that returns a Texture object.

Regarding loading the pixel data via the constructor; I don't see a reason why:

EDIT: To add to that, the only good use of something being designed in this way is using the singleton pattern. This seems to be what the OP is doing, but the OP is using it in the wrong way. The singleton pattern is used to restrict having more than one instance of a class.

Seems like no one likes imperative Java programming. I will turn away.

Object orientated programming is a form of imperative programming. What you're doing is structuring of an object orientated program. This is no more an imperative form of programming than OOP is; this is only a bad way of structuring object orientated code.

The main downside to doing the texture loading in the constructor is that it's hidden away, e.g. from a user who might want the same utility for a more advanced texture loader (say, for cube maps or texture arrays). IMHO it's not a big deal if a simple GL utility library does this -- you can't be expected to support every possible need of the user.

LibGDX also loads textures in the constructor, although it's abstracted out the image and texture loading to provide easier support for float texture and such.

I didn't exactly mean it that way. I meant that the way the texture is loaded, i.e from a static method and using pretty much the same naming conventions, is similar. The reason I implied that that's messy you can read above.

//Matching coordinate positive/negative signs is a must, in order to create directionally specific textures.//Texture coordinates (s, t) ranges from -1 to 1, with -1 being the lowest (analogous to 0 on the number line)

Please read the OpenGL spec on how texcoords are normalized, how they map to texels and how repeating/clamping works

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org