Space Shift

Hi all,

I’m developing a MMO RPG-Action on this engine. Many thanks to the developer of this remarkable engine.

[video]SpaceShift: Battle 2 - YouTube

15 Likes

This game looks amazing and also remarkable.
Love it!!!
Good job so far.

Looks really nice. Wow.

Awesome work =)

Looks great!!!

Purdy!

Very nice results!

[video]SpaceShift: Battle - YouTube
=D

1 Like

Wow, looks cool,
That large ship is that a homeworld one?

@Empire Phoenix said: Wow, looks cool, That large ship is that a homeworld one?
Yes, it is a model of homeworld, but soon it will be replaced by my model

Really cool!

@javasabr I like the engine flare. how did you achieve that effect?

[java]WARNING 07:41:09:283 Game: IllegalStateException : Scene graph is not properly updated for rendering.
State was changed after rootNode.updateGeometricState() call.
Make sure you do not modify the scene from another thread!
Problem spatial name: Root Node : stack trace:
com.jme3.scene.Spatial.checkCulling(Spatial.java:260)
com.jme3.renderer.RenderManager.renderSubScene(RenderManager.java:647)
com.jme3.renderer.RenderManager.renderScene(RenderManager.java:640)
com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:974)
com.jme3.renderer.RenderManager.render(RenderManager.java:1029)
com.jme3.app.SimpleApplication.update(SimpleApplication.java:252)
com.ss.client.Game.update(Game.java:376)
com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
java.lang.Thread.run(Thread.java:744)[/java]

how to find the problem areas in the code?

@javasabr said: [java]WARNING 07:41:09:283 Game: IllegalStateException : Scene graph is not properly updated for rendering. State was changed after rootNode.updateGeometricState() call. Make sure you do not modify the scene from another thread! Problem spatial name: Root Node : stack trace: com.jme3.scene.Spatial.checkCulling(Spatial.java:260) com.jme3.renderer.RenderManager.renderSubScene(RenderManager.java:647) com.jme3.renderer.RenderManager.renderScene(RenderManager.java:640) com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:974) com.jme3.renderer.RenderManager.render(RenderManager.java:1029) com.jme3.app.SimpleApplication.update(SimpleApplication.java:252) com.ss.client.Game.update(Game.java:376) com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151) com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185) com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228) java.lang.Thread.run(Thread.java:744)[/java]

how to find the problem areas in the code?

Track down where you are modifying the scene graph outside the normal update loop.

@pspeed said: Track down where you are modifying the scene graph outside the normal update loop.
Such places very much, because the client multithreading :)
@javasabr said: Such places very much, because the client multithreading :)

Yes, well, you will need to fix those to use proper scene graph multithreading and make the scene changes on the render thread. See docs on “advanced threading”.

@pspeed said: Yes, well, you will need to fix those to use proper scene graph multithreading and make the scene changes on the render thread. See docs on "advanced threading".
my implement [java]@Override public void update() {
	AtomicInteger waitUpdateGeometrySync = getWaitUpdateGeometrySync();
	AtomicInteger waitUpdateUISync = getWaitUpdateUISync();
	AtomicInteger waitState = getWaitState();

	synchronized(waitState) {

		ConcurrentUtils.notifyAllInSynchronize(waitState);

		if(waitUpdateGeometrySync.get() > 0) {
			ConcurrentUtils.notifyAll(waitUpdateGeometrySync);
			waitUpdateGeometrySync.set(0);
			ConcurrentUtils.waitInSynchronize(waitState);
		}

		CameraController controller = CameraController.getInstance();
		controller.update(LocalObjects.get(), System.currentTimeMillis());

		if(waitUpdateUISync.get() > 0) {
			ConcurrentUtils.notifyAll(waitUpdateUISync);
			waitUpdateUISync.set(0);
			ConcurrentUtils.waitInSynchronize(waitState);
		}
	}

	syncLock();
	try {
		super.update();
	} catch(NullPointerException npe) {
		LOGGER.warning(npe);
		System.exit(1);
	} catch(IllegalStateException e) {
		LOGGER.warning(e);
	} finally {
		syncUnlock();
	}
}[/java]

This implementation works very well, I just need to track down some problem areas

1 Like

A simple tip:

At start in simpleInit (or similar) do a openglThread = Thread.currentThread();
Then addd everywhere where you are setting changign attaching ect a

assert Thread.currentThread() == MyApp.openglThread:"False Thread captured " + Thread.currentThread.getName();

Start the VM with th -ea argument to enable the assertions
(Why assertions, you can disable them once everything works for performance gain, the jit will just compile them out without the -ea argument)
Now the only thing left to do is, to name all Threads you create Properly.

Edit: note… my comment is regarding OP’s code. Empire’s suggestion is spot on for debugging these issues.

Oh my! That’s a lot of code to do something very simple.

Why not just queue up your updates to be run on the render thread like normal?

@pspeed said: Edit: note... my comment is regarding OP's code. Empire's suggestion is spot on for debugging these issues.

Oh my! That’s a lot of code to do something very simple.

Why not just queue up your updates to be run on the render thread like normal?


asynchronous update geometry and UI based lock-free gives the best result

@javasabr said: asynchronous update geometry and UI based lock-free gives the best result

Yes… but your code is the opposite of lock-free. Heaving synchronization and waiting everywhere.

Where as ConcurrentLinkedQueue or ConcurrentLinkedQueue is essentially lock free. Moreover, JME already has a queue for you to add Callables to. It’s in the threading docs.

1 Like
@pspeed said: Yes... but your code is the opposite of lock-free. Heaving synchronization and waiting everywhere.

Where as ConcurrentLinkedQueue<SomeCommand> or ConcurrentLinkedQueue<Callable> is essentially lock free. Moreover, JME already has a queue for you to add Callables to. It’s in the threading docs.


Where is the code hard sync? :slight_smile: