Only geometry must be change in thread or controls too?
Controls cannot be used from another thread unless the features in the control are properly designed for concurrent access (synchronized, volatile, concurrent collections or atomics, etc). Also, you cannot add or remove controls from other threads. In general, unless somebody has said “this method is safe to use from multiple threads” then it is unsafe and you should never use it across threads. This is true not just for jME but for all Java (and really, any language) code.
Other thread = other class?
I think always thread
Thread thread = new Thread();
thread.start();
only main game thread can change 3d controlls capsule…
No. Other thread = other thread.
It would be incredibly stupid if you could only modify the scene graph from one CLASS.
I make game class singleton
public static GameLevel getInstance() {
if (instance == null) {
return null;
}
return instance;
}
public static GameLevel getInstance(String levelJson) {
if (instance == null) {
instance = new GameLevel(levelJson);
}
return instance;
}
And add tasks and futures.
I need use mainApp.enqueue();
or make executor pull?
If you are running from a thread that is different than the render thread then: yes. I’m trying really hard to understand why this is so hard for you to understand.
IF YOU ARE RUNNING FROM A DIFFERENT THREAD THAN THE RENDER THREAD THEN YOU CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
CANNOT MODIFY THE SCENE GRAPH.
You must use some other means.
-
class player - not different thread
-
if i have one player it works, not work if i have 1 > players.
-
If need modify scene graph only in update method. (3d)
-
capsule and controls (animation) need setup in update method too.
What better create executor pool or use mainApp.enqueue();
Oh my god…
Make this:
for(String key : players.keySet()){
updatePlayer(players.get(key),tpf);
//players.get(key).tpfUpdate();
}
}
}
public void updatePlayer(final Player player, final float tpf) {
enqueue(new Callable<Void>() {
public Void call() throws Exception {
player.update(tpf);
player.tpfUpdate();
return null;
}
});
}
//
public static void updatePlayerPosition(JInMessages in){
if(in.json.get("error") == null){
JSONObject player = (JSONObject)in.json.get("player");
String id = (String) player.get("id");
System.out.println("game level update localID " + localPlayerId + " update id " + id);
instance.players.get(id).setJsonKeys(player);
}
}
Work for one player
Look… if you are handling your networking on a separate thread then you have stuff on a separate thread. Period. You will need to deal with it.
If you don’t have your networking on a separate thread then you might as well quit now… because your game is going to suck giant elephant balls.
I pack all work with scene graph to futures.
It works for one player.
Now try multiplayer
Don’t have more errors with scene graph… Thanks.
Lmao a use case and sequence diagram? Do you have a 20 person team working on this?
I been programming for 10+ years
And…?
I can do all one
Long but I can
Well yes I assumed as much, but there’s hardly a point to make these diagrams if you don’t have a team larger than like 5 people.
For documentation and visual understanding.
Work in team with 5 people:
day 1: every go to board and talk about own task.
day 7: git merger.
…
day 1: every go to board and talk about own task.
day 7: git merger.
repeat.
Yeah, doing everything by the book is a valid way of learning, just might be too long one for one’s lifetime. Nothing wrong with reference to Fowler, too. I guess, what @MoffKalast mentioned, that it looks like kinda overkill for a single developer’s project. What I wanted to add is that UML was kinda overestimated as a tool being introduced - and, as it was initially designed with really monstrous workflows such as RUP in mind - especially for small-to-mid sized projects. It was still too technical for managers (and they now have BPML to play with, lol) and not that much quicker to read for coders than the code itself, so…
I mean, sometimes a quick-and-simple focused picture might just suit better than something bigger, but approved by ISO.