Hey JGO, this isn’t the first time this has happened to me.
LWJGL has a issue of ‘keeping data’ even after I shutdown / cleanup my LWJGL application…
I’d assume that once I close my application, all the data pertaining to the application while it’s running is disposed of. (But it’s not…)
For example:
If I load a texture and bind it, and upon program exit I delete the texture, the next time I start my program (Even if I don’t bind my texture) it still binds the texture…?
(And people wonder why I stick to Java2D :L)
I’ve even tried booting up the application and right after OpenGL initialization deleting the textures, it still chooses to bind them…
Any feedback will be helpful guys, I’m fairly new to OpenGL/LWJGL.
Make sure you call Display.destroy() when you are done. Also, I do not think it is possible for something like what you are saying to happen unless you got drivers made by a rock or something. If it is driver issues you can’t blame opengl but yourself for not updating them.
Also, opengl is state based. So if you bind a texture, it will stay bound until you bind something else. The slick utils are kinda bad from what I understand so maybe make your own texture loader and texture class so you know what is going on.
All these issues you post with opengl I never had when learning it and many of them show signs of a lack of general programing knowledge. This is fine but do not blame a library that has been use by many many people if your code does not work. :clue:
All of these tutorials for LWJGL are ass backwards, half of the variables passed through methods are labeled incorrectly.
Horrible way for a beginner to start LWJGL… (Surfing through old ass tutorials with backwards variables)
‘A Lack of general programming knowledge’ lolz.
I’ve been with Java for a few years now mate.
I can decode a few ass backward parameters XD.
In my example I didn’t include ‘Display.destroy’ because it is ‘Psuedo code’.
If you want to look at the actual methods not psuedo code enjoy:
(See if you spot what you’re calling my ‘Lack of general programming knowledge’ :P)
Just because you have been with java for a few years does not mean you are pro. I am by no means pro but some of the questions you post on here are well…noobish. I agree that the tutorials for lwjgl are by no means great but you cant just blame everything else when YOUR code does not work.
Now let me get all things right. You start app and everything works. Then you end it. (No longer in processes.) But this time when you start it you don’t bind or load a texture anymore and it still shows the one from the previous app. Even if this is try this should not really be a problem as you bind your textures every time you render. Or if you are using an atlas, you bind one then give different texture coords. Also, giving Psuedo code is kinda of an ass move when trying to get people to help you as it is not ‘actual’ code which could have the problem.
I would also check your driver version as that can be the culprit for when opengl calls are not doing what they are suppose to do.
gasp
Pseudo code was commented well.
Basically the same format as the real code lolz.
Now we’re comparing personal experience in Java, never said I was a ‘pro’ D:
Just because you have more experience in a certain area of Java than I do doesn’t mean you wouldn’t be likely to come across some of the same issues / questions as me if you didn’t have experience in the area :D, anyways.
Correct.
Meh, my computer’s a dinosaur, that could be the issue here if you’re suggesting it has any relevance.
Even if your computer is super duper old it should still be able to do the glBegin and basic texturing. Still though, even if this really is not your fault and it is your drivers, it should not be an issue. Why would you start your app, close it, change code, and start it again? Just don’t do that can keep coding. Should be fine. I can’t think of anytime where you would need it to not do that.
Wow, I thought closing my IDE and booting it back up with the textures removed would fix the problem but it didn’t. :o :o :o
(Code for initializing textures via Slick-Util is still there, no binding)
Edit:
Yeah, if I remove:
texture = TextureLoader.getTexture("png", new FileInputStream(new File("res/img.png")));
and rerun the program, the issue doesn’t occur. (Should of tried this first D:)
Maybe Slick-Util is automatically binding? >.<
Man should have guessed it was that. I am lazy and use the string rending there and have run into issues with it. This is why you should probably do things yourself once or look into the documentation of what libraries you are using.
In general Slick will always call glBindTexture for you. You should never enable/disable textures or glBindTexture directly. Instead, you would do this:
//calls glBindTexture for you, enables texturing, and caches this texture to reduce redundant driver calls
tex.bind();
//glDisable textures and clears the last cached texture
TextureImpl.bindNone();
SlickUtil is pretty outdated, and as are many of the LWJGL tutorials. They might be OK for your very first “Hello, World” type of application, but generally speaking it’s better to understand what is going on rather than relying on SlickUtil (which doesn’t really allow for much control over GL state, and tries to do a lot “under the hood” for you like caching texture binds).
If you want to learn OpenGL from the lowest level, IMHO you should write your own texture loader. Then you can either learn to write your own sprite batcher, or you can use a 3rd party lib.
If you just want to learn OpenGL concepts (like textures, shaders, meshes, etc) you would probably be better off using a 3rd party library like LibGDX rather than struggling with the piss-poor documentation and tutorials of modern GL.
Nor should you bind texture “-1.” There are a number of reasons for this:
[]Texture “0” is undefined. In most cases it will be white, but on rare drivers it may contain garbage pixels or could be transparent black. And since it’s not very commonly used, it hasn’t been as thoroughly tested.
[]Texture “-1” is also undefined; maybe it points to a texture, or maybe it will cause an error with the driver, or maybe it will just point to texture unit 0. You should never assume that it’s a valid texture name.
[]If you want to disable texturing, use glDisable(GL_TEXTURE_2D)
[]If you want to texture with opaque white (i.e. for a seemingly “untextured” rectangle), then you should use a small texture region of opaque white picked from your game’s sprite sheet (explained here). This allows for more batching and does not need a state change with glBindTexture
[]As I discussed in my last post, you should not be calling glBindTexture directly if you are using SlickUtil. Instead, you should use texture.bind().
[]In modern GL we no longer need to enable/disable texturing, or worry about a “default texture”
Like I keep repeating… ditch SlickUtil and start learning OpenGL “properly.”
“Properly” would involve any method that uses modern GL (i.e. no immediate mode) and does not rely on something defunct like SlickUtil. Using BufferedImage is convenient, but some may argue PNGDecoder is superior (i.e. no dependency on AWT).
I’ve explained Textures in detail here:
The particular LWJGL wiki article you linked is good if you are looking to learn GL 3.0+. Unfortunately by using 3.0+ you are limiting your audience. The article also falls short on explaining the basics, and will probably leave you with a lot of unanswered questions (“What is a shader?”, “What is a vertex?”).
This is why I started writing my own series. You will learn things like GLSL and shaders without the complex boilerplate of OpenGL (VBOs, shader creation, etc). It is compatible with GL 2.0, which means that your shader code will also work with GL ES (iOS, Android, WebGL).
If after following the tutorials you feel comfortable with the OpenGL pipeline, you can then drop down to a lower level and start poking around the source code to get an idea of how it all comes together.
There is also plenty of other “modern GL” tutorials floating around the web. The real trick is understanding how to translate C/C++ code to Java, and understanding how to translate GL 3.0+ concepts to a 2.0 context (or GL ES).