compile

[raft]

i know compile() method is removed because all objects are compiled in AE but it may still make sense to put it back. it's is useful as a preperation before game begins. if i dont miss something, at the moment we are forced to serialize even the simplest objects like particles. particles are typically cloned from a master and at each cloning a compile occurs

[EgonOlsen]

  You don't have to serialize particles...at least i don't. I create a particle pool, pre-fill it with, let's say, 50 instances all cloned from the master. They all share the same mesh and the same compiled data (Object3d.shareCompiledData(<Object3D>); ).
If you want to make sure that everything is compiled before the game begins, just call World.compileAllObjects(). However, that doesn't include the actual filling of the native structures at runtime, which i can't push up to an earlier stage. It's pretty cheap anyway.

[raft]

mm, i tried sharedCompileData thingy but couldn't manage to work, i must have messed something that time

now it works in desktop version. i create my master particle in a static initializer block (like in Robombs). it works in desktop since i can compile it there. no such option for AE. so you do create master for each level ?

is compileAllObjects() thread safe ?

[EgonOlsen]

The master object needs no explicit compile even if you use shareCompiledData() on it. The object compiler will compile it if needed once it encouters an object that shares data with it.

compileAllObjects() isn't thread safe, but i can easily make it if that does any good!?

[raft]

i was getting this exception in AE when trying to share:

Code Select Expand

E/AndroidRuntime(10098): Caused by: java.lang.RuntimeException: [ 1282329180107 ] - ERROR: Can't enable data sharing after calling compile on object object28!
E/AndroidRuntime(10098): at com.threed.jpct.Logger.log(Logger.java:159)
E/AndroidRuntime(10098): at com.threed.jpct.Object3D.shareCompiledData(Object3D.java:837)


i was calling shareCompiledData() after build(). after your post i reversed the order and now it works. i suppose build is not even necessary there.
but the thing is, same code is now broken in desktop version. if it won't be trouble, adding compile to AE may really help.

for compileAllObjects(), it doesnt really matter. i can live both way.

[EgonOlsen]

I don't like adding compile() to AE, because it's now done in build() anyway. Making it an extra method again forces one to call two methods where one would be sufficient. Instead, i've removed the check from shareCompiledData(). To be honest, i can't see any reason why i disallowed calling compile() before shareCompiledData()...might be that it was needed that way in former versions but i can't see why it's needed in the current implementation. Not in AE and not in the desktop version.

I've uploaded the fixed jar for AE.

[EgonOlsen]

but the thing is, same code is now broken in desktop version.

Why is that? What happens on the desktop version when reversing the order?

[raft]

thanks but this doesnt solve my situation. maybe i miss it something

i cannot call compile() on master object because there is no compile on AE. sharing data with it works on AE but desktop version complains saying "Can't set an uncompiled object was a source for compiled data!"

Making it an extra method again forces one to call two methods where one would be sufficient.

this may not be necessary, build() can still compile if object is not compiled yet. not sure this fits you..

[EgonOlsen]

But doesn't the same problem apply to the cloned object? You can't call compile() on them either in AE, but you would have to in desktop version!?

[raft]

yes it does. but i couldnt get your point. if you add compile to AE, i will call it on master of cloned objects too.
possibly you are talking about something else

[EgonOlsen]

yes it does. but i couldnt get your point. if you add compile to AE, i will call it on master of cloned objects too.
possibly you are talking about something else

No, its the same thing. I just wanted to make sure that there isn't any other way to solve this than to put compile() back in...which i stil don't like, but i guess i have to...i've uploaded another jar that does this. Please give it a try and see if it helps.

[raft]

thanks, it's ok now sorry for the trouble

[EgonOlsen]

No problem. BTW: This doesn't replace compileAllObjects() in World, which really does the compilation. The call to compile() in Object3D only does some preparational work.

[raft]

Egon, i got the following exception, you may wanna know.

Code Select Expand

I/jPCT-AE (10652): Object 'object111' shares compiled data with object 'object110'
W/System.err(10652): java.lang.RuntimeException
W/System.err(10652): at com.threed.jpct.CompiledInstance.render(CompiledInstance.java:171)
W/System.err(10652): at com.threed.jpct.GLRenderer.drawVertexArray(GLRenderer.java:2027)
W/System.err(10652): at com.threed.jpct.World.draw(World.java:1310)
W/System.err(10652): at com.threed.jpct.World.draw(World.java:1092)
W/System.err(10652): at raft.jumpy.android.JumpyActivity$MyRenderer.onDrawFrame(JumpyActivity.java:539)
W/System.err(10652): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1116)
W/System.err(10652): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:975)
I/jPCT-AE (10652): [ 1282343088183 ] - ERROR: Internal error, please report: render() called on an uncompiled object (object111)!


after some digging i've found the reason: i call build(false) on an object and then call shareCompiledData(..) on it. i know it makes no sense, i've corrected my code..

[EgonOlsen]

This can only happen if rendering interleaves with the build()...shareCompiledData()-sequence somehow. This might be the reason why i formerly insisted on calling share... before calling compile(). Anyway, with the latest changes, this can happen now and even if it's not nice, it's maybe nothing that should cause a crash anymore. I've changed the state of the message to a warning and return from rendering afterwards.