Look, just take this code and adapt it - its not as daunting as it may seem, just make sure that SceneActionStore invokeActions is called in the update area of your game loop.
You will need to add classes that extend SceneAction, just put in what ever needs to be done in the doAction method
/**
*
* Simple caching mechanism for sceneActions requiring invocation.
*
* This is not a true singleton deliberatly to avoid object locking.
* to use this class safetly, all is needed is a call to getInstance early in the main program
* so that there is only one instance created.
*
*/
public class SceneActionStore {
// how many actions will be invoked within invokeActions()
private int iterationsPerCycle = 10;
private int iterationCount = 0;
private static final ConcurrentLinkedQueue<SceneAction> actionsQueue = new ConcurrentLinkedQueue<SceneAction>();
private static SceneActionStore instance;
public static SceneActionStore getInstance() {
if(instance == null) instance = new SceneActionStore();
return instance;
}
public void addAction(SceneAction action) {
actionsQueue.add(action);
}
/**
* @return the number of iterations per cycle
*/
public int getIterationsPerCycle() {
return iterationsPerCycle;
}
public void setIterationsPerCycle(int iterationsPerCycle) {
this.iterationsPerCycle = iterationsPerCycle;
}
}
package sceneaction;
public abstract class SceneAction {
public abstract void doAction();
}
A good example is an AddArtefact class, its good if you want to add anything to the scenegraph after the scene has been created as doAction will be called in the OpenGL thread, like wise a RemoveArtefact or a decorate Artefact.
Look, just take this code and adapt it - its not as daunting as it may seem, just make sure that SceneActionStore invokeActions is called in the update area of your game loop.
You will need to add classes that extend SceneAction, just put in what ever needs to be done in the doAction method
/**
*
* Simple caching mechanism for sceneActions requiring invocation.
*
* This is not a true singleton deliberatly to avoid object locking.
* to use this class safetly, all is needed is a call to getInstance early in the main program
* so that there is only one instance created.
*
*/
public class SceneActionStore {
// how many actions will be invoked within invokeActions()
private int iterationsPerCycle = 10;
private int iterationCount = 0;
private static final ConcurrentLinkedQueue<SceneAction> actionsQueue = new ConcurrentLinkedQueue<SceneAction>();
private static SceneActionStore instance;
public static SceneActionStore getInstance() {
if(instance == null) instance = new SceneActionStore();
return instance;
}
public void addAction(SceneAction action) {
actionsQueue.add(action);
}
/**
* @return the number of iterations per cycle
*/
public int getIterationsPerCycle() {
return iterationsPerCycle;
}
public void setIterationsPerCycle(int iterationsPerCycle) {
this.iterationsPerCycle = iterationsPerCycle;
}
}
package sceneaction;
public abstract class SceneAction {
public abstract void doAction();
}
A good example is an AddArtefact class, its good if you want to add anything to the scenegraph after the scene has been created as doAction will be called in the OpenGL thread, like wise a RemoveArtefact or a decorate Artefact.
This doesn't help me at all!, if I spread different commands over differently threads, and then just use the SceneActionStore, it will slow down so it will be slower than one thread.
I could just use the GameTaskQueueManager instead.
Renanse: "When" probably mostly depends on when we get svn setup.
—
If you've already paid the $500 to get your CVS repository then disregard this reply. Here at work I don't have access to our CVS repository but was able to pull it all down locally using "CVSSuck" (http://cvs.m17n.org/~akr/cvssuck/). It recreated the CVS repository locally then I was able to run cvs2svn on it just fine.
That's what irrisor did too… it worked pretty well. Also, suddendly java.net came to their senses and offered to assist us for free… it seems they had some serious problems routing their support requests or something.
I've been posting 2.0 development news on my blog. As for release date of the source, probably late next month or early Feb after Rikard has arrived in the states and we've nailed down a few more things in the core.
I've been posting 2.0 development news on my blog. As for release date of the source, probably late next month or early Feb after Rikard has arrived in the states and we've nailed down a few more things in the core.
omg!!! i cant believe it. in a month! u guys r awesome!!!
what about the xml importer? it seems the current collada has problems. and model/animation importing is a core feature right?
…2.0 development branch will begin being available in a pre-pre-pre-pre-pre-alpha branch that we will be throwing new ideas into I think is what Renanse meant to say. :o
2.0 for the developers means we can throw code ideas in that would previously have been far too new and strange in the 1.0, but now we can focus on new and innovative instead of catering to "being functional".
Just wondering… but would usage of version 2.0 require a complete rewrite of games that are written in 1.0? Meaning 2.0 would be a rewrite from scratch?
By the way, I found a good way to introduce enums in my projects without affecting legacy classes, maybe this could be useful for JME 2.0 too:
If you have something like this:
class TrafficLight {
public final static int RED = 0;
public final static int YELLOW = 1;
public final static int GREEN = 2;
...
public void setColor(int color) {..}
}
legacy code still runs (well, except it uses really hardcoded ints instead of TrafficLight.RED etc) when you write:
class TrafficLight {
enum Color {RED, YELLOW, GREEN}
public final static Color RED = Color.RED;
public final static Color YELLOW = Color.YELLOW;
public final static Color GREEN = Color.GREEN;
...
public void setColor(Color color) {..}
}
Even for new code I find it convenient to type TrafficLight.RED instead of TrafficLight.Color.RED, without loosing type safety.
Yeah, except that in the process of porting over to enums I was able to clean things up and add additional functionality and name clarity, so it wouldn't be quite that simple.
Any 2.0 news? I guess a lot of people (including me) would like to play around… , erm… I mean "test and give a lot of useful feedback", even in a very early stage.
Just poking: Any news about 2.0? We would really like to switch directly to 2.0 instead of merging and hacking our way from JME-August to JME-January and then soon after making the big switch to JME2.0. I think that Landai is right, a lot of people are ready for the incomplete code-base of 2.0 - many of us are }:-@-programmers - broken code does not scare us
