Version updates!

[EgonOlsen]

Another update that adds the option to create Textures out of Drawables instead of Bitmaps, improves loading speed of serialized objects and reduces memory usage during the deserialization process. I've also updated the JavaDOCs.

[EgonOlsen]

And another small update that reduces memory usage of deserialized instances of Animation and that is more aggressive when calling Object3D.strip(), i.e. it frees more memory.

Edit: And working with lights is a bit cheaper now due to some internal instance recycling, i.e. less gc occurs. There still seems to be some part that creates some garbage related to lights, but i still have to find it...

[Darkflame]

Nice work

[dl.zerocool]

Hi, with the last JPCT I've out of memory errors on magic & spica.

Does it consume more memory ?

[EgonOlsen]

No, actually it consumes much less than before. When exactly do the errors occur?

[dl.zerocool]

When I compile the model  -> call of -> WORLD.compileAllObjects

The objects are really small.
~2,4ko the first 3ds file and another of 2,8ko

but I do clone the first one 7 times and the other one 23times.
Perhaps it comes from there.

[EgonOlsen]

If the models share the same mesh, you should also do a Object.shareCompiledData(<Object3D>); on all the clones to make them use the same compiled data. That will increase compilation time and decreases memory usage. However, i don't see why this should take more memory than before. Actually it should require less to compile them now. I'll look into it anyway to make sure that i haven't introduced something that may cause this problem.

[EgonOlsen]

Maybe you were calling strip() after calling compileAllObjects()? In that case, the stripping doesn't happen. I've uploaded a new version that fixes this. In addition, it reduces object creation for bill boarded objects and reduces memory usage of compiled object by a negligible amount. Apart from that, i don't see any change that i've made that could cause the compile to fail where it formerly succeeded...quite the contrary.

Edit: Decreased memory usage while compiling some more....

[dl.zerocool]

Okay thank you

I'm going to test it on emulator for now and on magic tomorrow, It's a friend phone
so I don't always have it.

Oh I forgot to mention, you can search on market for " ARescue " It's my application.

I'm not sure it will run properly, sounds are deactivated at moment.
It's quite slow, and collisions make the game freeze (FC) sometimes so don't flood the bees or the superBees.

[EgonOlsen]

It crashes from time to time at startup on my Galaxy. I can't tell the reason, i've no access to the logs right now. Maybe that's that memory thing? When it runs, it's really really slow. Why is it so slow? Is the time spend in the engine or in your code?

[zammbi]

I can't tell the reason, i've no access to the logs right now.

The application "Android System Info" has a nice log function. Its free.

[EgonOlsen]

Cool little app!

One issue with the game seems to be that you are not using the

Code Select Expand


mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
// Ensure that we get a 16bit framebuffer. Otherwise, we'll fall
// back to Pixelflinger on some device (read: Samsung I7500)
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});


part like the demo code does. This means, that it runs in software emulation on my phone, which it obviously does (judging from the log its using Pixelflinger, which is Androids software renderer).
In addition, it spams the log with "superbee0died" or similar albeit i haven't done anything except moving the phone. I'm not sure if this is an issue, i was just wondering about it.

Haven't got the crash yet...

[EgonOlsen]

Ok, it's out of memory indeed...try to convert your files to OBJ-format instead. The 3DS loader is pretty stupid and consumes too much memory while parsing. I have to work on this. Until then, please give the obj-format a try if possible.

[dl.zerocool]

Cool, I'm going to test all the things you told me.

But I can't use this init (see the attached file):

Code Select Expand


mGLView.setEGLConfigChooser(new GLSurfaceView.EGLConfigChooser() {
public EGLConfig chooseConfig(EGL10 egl, EGLDisplay display) {
// Ensure that we get a 16bit framebuffer. Otherwise, we'll fall
// back to Pixelflinger on some device (read: Samsung I7500)
int[] attributes = new int[] { EGL10.EGL_DEPTH_SIZE, 16, EGL10.EGL_NONE };
EGLConfig[] configs = new EGLConfig[1];
int[] result = new int[1];
egl.eglChooseConfig(display, attributes, configs, 1, result);
return configs[0];
}
});


Because it show something very odd, I attached a screenshot to this

[attachment deleted by admin]

[EgonOlsen]

Looks strange indeed. Does it happen without using the camera too? If this init code isn't there, you'll never get hardware acceleration on the Galaxy...might not be much of an issue though, because it's not very popular.