All Methods who call OpenGL functions, org.lwjgl.opengl.GL11.glMatrixMode() for example, need to be executed in the Main thread (the openGL thread) which StandardGame creates.
In your case CameraGameState.initCamera() is the cause for your problem.
But that call seems to be in the constructor of CameraGamesSate hmm
game.lock(); // Requests a lock on StandardGame that will pause the OpenGL thread when it starts the next update
MainMenuState menu = new MainMenuState("mainMenu"); // We can now call this in our current thread because thread-safety is no longer a concern, the OpenGL thread is paused at a safe point
game.unlock(); // Don't forget to do this as otherwise your game will be paused permanently and causes for a pretty sad gameplay experience
It is necessary to point out that the lock() and unlock() functionality though it does provide thread-safety is not useable in all scenarios because of the way the OpenGL code requires to be run in a specific thread sometimes as well (otherwise you get really bad breakages).
Like I said, it doesn't work in all scenarios. Take a look at the wiki link posted above and try putting it in GameTaskQueue instead. That will certainly resolve the issue.
Maybe a simple question but I've always wondered, without finding it out for myself, how do you know if a method calls an OpenGL function? Or does the exception message always point to the lwjgl lib whenever you're trying to do something that should be executed in the OpenGL Thread?
Im asking because I forsee myself debugging code a long time without thinking of this possibility
This is one of the problems we currently have in jME that has yet to be totally resolved. No, it's not always a nasty LWJGL exception thrown but in the majority of cases it is. In most cases you can just make educated guesses of what needs to execute in the OpenGL thread based on what you're trying to do. However, when in doubt, stick in the GameTaskQueue.
I have another question I got another problem here… when I press down on the keyboard it dispatchs a lot of events… and the options become crasy… switching the scale so many times… is there a way so the keyboard could be more slow???
public class MainMenuState extends CameraGameState {
private static final String[] msg = {"Sair","Opcoes","Iniciar"};
private static final int INICIAR = 2;
private static final int OPCOES = 1;
private static final int SAIR = 0;
private Text[] textos;
private Text selectedText;
private Text lastSelectedText;
private InputHandler input;
public MainMenuState(String string) {
super(string);
While this topic seems to be turning in a "I have a question about game states!"-topic I would like to ask another question concerning game states.
My scenario is that I currently have an arrow spatial that travels thru my jME world. Whenever I colide with a spatial I want the arrow to freeze.
However, Im using multiple game states (I suppose this can be interpretted as multiple threads) and it has occured to me that the arrow is half-way thru the targetted spatial before it freezes. Basically the gamestate that checks if there has been a colission is too slow because when I slow down the speed of the arrow it freezes at the right moment.
I'm guessing that the 60fps (= 60 updates per seconds) is too slow to accuratly freeze my arrow on the right position. But i've been thinking, what If a player has a slow computer who can only render 10fps? That means my arrow will probably go thru without ever getting checked.
This problem doesnt occur in non-gamestate games because everything is dumped in one big Update method. I would assume that throwing the colission checking in the openGL thread would perhaps solve it but that doesnt sound right to me.
You'll have to "step" or "tick" it forward along the path instead of simply updating position. Or you could find the line from where the tip was at the previous update to the place where the tip should be at the end of this update and find out if it goes through an object?
I forgot to mention that im using Physics (AddForce()) to send the arrow flying. I suppose you could interpolate it by calculating the delta travelspeed between frames and freeze the arrow but that would be more or less reinventing the Colission detection of JME I suppose.
hmm
