Steps how to debug things like this that don't work:1) Make sure your texture is actually being loaded properly: render a triangle or a quad with immediate mode to make sure you are actually able to display texture properly;2) Make a VBO which contains triangle or quad without any colors, just vertices. Make sure its being rendered properly;3) Add color to the VBO;4) Add texturing to the VBO;

Following these steps you will gradually increase complexity in your code, so you will know if something doesn't work along the way.

Steps how to debug things like this that don't work:1) Make sure your texture is actually being loaded properly: render a triangle or a quad with immediate mode to make sure you are actually able to display texture properly;2) Make a VBO which contains triangle or quad without any colors, just vertices. Make sure its being rendered properly;3) Add color to the VBO;4) Add texturing to the VBO;

Following these steps you will gradually increase complexity in your code, so you will know if something doesn't work along the way.

Well, so I did that... somewhat and I'm not able to render the texture on my VBO. How? Well before binding the texture I added these 4 lines.

With the tCoords.put(...) you're passing texture coordinates to openGL that define which part of the texture correlates to each vertex, where the top left corner is (0, 0) and the bottom right is (1, 1).

Would someone please explain what this means?, Why di I need todo this? From what I understand I'm telling openGL the coordinates of the texture, but I thought I did that with this...

Each time you call glTexParameteri, you're defining something about your texture. GL_TEXTURE_MIN_FILTER means your specifying the minification filter (AKA how it reacts to be being scaled down), where GL_TEXTURE_MAG_FILTER filter defines how it is when it is magnified, or scaled up. GL_LINEAR is what you're specified the scaling filters to do. GL_LINEAR blurs each pixel into the next pixel, making it good for high-res things as it gets rid of any pixelation. What you should probably be using considering what you're texture looks to be, is GL_NEAREST. This doesn't do any blurring, and is good for lower-res stuff like pixel art and subsequently what you appear to be doing. Here is a good representation of GL_NEAREST v. GL_LINEAR

The second two lines effectively define what happens when you give texture coords (otherwise know as UV or ST) that are greater than one. GL_CLAMP_TO_EDGE means that the edge pixels will be repeated continuously, while the alternative GL_REPEAT means the texture will just repeat itself infinitely. In images:

Upon what I just said about UVs, looking at your code you bind one face of UV coords, and although it's hard to know without seeing your code, the context implies that block.getVerticies() returns more than one face of vertex positions, but all exposed faces. However, every vertex position has to line up to a vertex, as shown with this diagram here:

Assuming I right in saying that block.getVerticies() returns all exposed faces, you would have to have a for loop around your UV coords like so:

This method GL11.glGetError() will return an non-zero number if there has been an issue.while(GLErr != 0) will iterate until there are no more issues to be resolved.GLU.gluErrorString(GLErr) will give greater insight into what the error is beyond just the error code.NOTE: GLU.gluErrorString() requires that you have lwjgl_util.jar importing into your workspace.

When an error occurs, the error flag is set to the appropriate error code value. No other errors are recorded until glGetError is called, the error code is returned, and the flag is reset to GL_NO_ERROR.

With the tCoords.put(...) you're passing texture coordinates to openGL that define which part of the texture correlates to each vertex, where the top left corner is (0, 0) and the bottom right is (1, 1).

Would someone please explain what this means?, Why di I need todo this? From what I understand I'm telling openGL the coordinates of the texture, but I thought I did that with this...

Each time you call glTexParameteri, you're defining something about your texture. GL_TEXTURE_MIN_FILTER means your specifying the minification filter (AKA how it reacts to be being scaled down), where GL_TEXTURE_MAG_FILTER filter defines how it is when it is magnified, or scaled up. GL_LINEAR is what you're specified the scaling filters to do. GL_LINEAR blurs each pixel into the next pixel, making it good for high-res things as it gets rid of any pixelation. What you should probably be using considering what you're texture looks to be, is GL_NEAREST. This doesn't do any blurring, and is good for lower-res stuff like pixel art and subsequently what you appear to be doing. Here is a good representation of GL_NEAREST v. GL_LINEAR

The second two lines effectively define what happens when you give texture coords (otherwise know as UV or ST) that are greater than one. GL_CLAMP_TO_EDGE means that the edge pixels will be repeated continuously, while the alternative GL_REPEAT means the texture will just repeat itself infinitely. In images:

I hope I have cleared things up a little for you

Thank you, this really cleared things up. However I would have to say, I've read many tutorials and guides on this and i never understood the s & t cordinates was of the texture. I thought it was which corner the texture should bind to. However now when that's cleared up I made a atlas texture and things works fine almost.

When using one texture things work fine. but when trying to load a secondary texture the first stop's to display? O.o'?

To be honest no idea. You seem to call "bind()"...Maybe something with that method is wrong, if the texture's id is not correctly stored before (for whatever reason) bind() would bind 0 - might not be the case here.

Leaving "unbind()" out is probably helpful because the texture gets bound when it gets generated and theres a problem with "bind()" doing nothing...

EDIT:Did you try putting the lines with glTexParameteri(...) before glTexImage2D(...) in the initializer instead of the bind method?

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