Hi,

I saw the "hook into the ceiling" but I was not able to fix it on time, is probably the worst bug we have out there. Thanks for the report anyway, I never saw it hook into an obstacle like that one before, this means is easier to replicate and also worst than what I thought. That's the problem of implementing the physics yourself ;-)

There is a "dead" animation, the cat lowering the head and putting a sad face. In earlier versions the cat was "dead" but our beta testers  said that it made them feel too sad, so we changed it. Probably the animation is not as noticeable as we thought, I'll let the designer know about it.

QuoteI'll add it to the projects page, if you don't mind.

Please do.

Thanks!

Thanks! We are working in some improvements now.

I wrote the physics myself, but they are quite simple, and very primitive, I use the spherical collisions of jPCT as the basis for it, so it is not much to do.

I have not much gaming background, just 6 months (we did Chalk Ball before) but more than 7 years in development (which always helps)

Hi,

I was just checking out other project and I found this, which I had downloaded previously. I think I saw it in the trending apps.

You made a very good work with the graphics, but when I played it I found it too frustrating (maybe it is just me sucking at this type of games) but it took me ages to go through the 3rd screen.

Nice work!

Hi,

I am proud of presenting "SpaceCat" a mix between a lander and a platform game where you play with cats in flying saucers. Of course, the engine is jPCT (that's why it is here)

Just take a look at it in the market: https://market.android.com/details?id=com.thepilltree.spacecat

Ok, so not flushing the TextureManager and reusing the texture solved the degradation problem, I guess doing a proper unload will fix it as well, but I have to test it.

Thanks

This is just the smallest test I could put together showing the problem. I need to unload the textures because we change from one scenario to the other and they don't share the textures, if we keep them in memory it is a waste.

Maybe the Nexus S has a better implementation of OpenGl, or just more memory or a faster processor. In my Nexus one each time I press the button I can see a drop in t he fps or 1-2, so iin 12 clicks it can easily be at 45 fps in my phone.

I'll try your tips and let you know if they worked. Thanks!

I am uploading the apk for the test, basically it has a button to reload the scene, and a FPS counter. It is here: http://android.shalafi.net/PerformanceTest.apk

The scene is a room with a sphere in the middle, the camera is going around it. There are 4 overlays on the top

Each time you clean the scene, there is a drop in the fps rate. For me it starts in 55-60 and after a few clicks it goes to 30-35, and visually it is very laggy while it is smooth at the beginning.

In addition to that, the overlays blink a lot, but that is a separate problem.

Also, if I remove the overlays, the performance suffers but a lot less.

Maybe I am doing something wrong. The code for the click on the button is as follows

public void onClick(View arg0) {
synchronized (mWorld) {
mWorld.removeAllObjects();
for (int i=0; i< mOverlays.length; i++) {
if (mOverlays[i] != null) {
mOverlays[i].dispose();
}
}
TextureManager.getInstance().flush();

Texture texture = new Texture(getResources().openRawResource(R.raw.texture), true);
TextureManager.getInstance().addTexture(TEXTURE_NAME, texture);
TextureManager.getInstance().addTexture(OVERLAY_TEXTURE);

Object3D [] model = Loader.load3DS(getResources().openRawResource(R.raw.model), 1);
for (int i=0; i<model.length; i++) {
model[i].setTexture(TEXTURE_NAME);
mWorld.addObject(model[i]);
}
for (int i=0; i<mOverlays.length; i++) {
mOverlays[i] = new Overlay(mWorld, i*60, 0, i*60+50, 50, OVERLAY_TEXTURE);
}
mCurrentTime = 0;
}
}


I will try to create a simple example. I am using the version of the library you uploaded on this thread (in case it makes any difference)

http://www.jpct.net/forum2/index.php/topic,1907.0.html

Anyway, there should be something else, because on the long run it still shows some performance degradation without the overlay but it takes much longer to notice.

With the overlays in 3-4 iterations it was unplayable, now it takes around 10-12 to make it noticeable.

I'll come back to you later with a simplified example. Thanks a lot!

This may be a hint, but I removed the Overlays completely and this degradation has disappeared almost completely.

It does not make a lot of sense since I was calling dispose every time the overlay was no longer used.

In addition to that, the Overlay is "supposed" to be linked to the World, so changing worlds should not impact it, or at least I don't see a reason why it should.

So, I suspect the Overlay dispose method is not working as expected, and eventually a lot of overlays were drawn on screen slowing everything down.

Hi again,

I have a very strange situation in which I am getting a serious performance degradation, from the game being smooth to almost unplayable in terms of FPS.

I have multiple scenarios that can be loaded and played, then unloaded. For convenience each one of those uses a World object and also takes care of loading textures and objects3D.

The first time I load a scenario, it works fine, but if I keep loading scenarios the performance is seriously impacted, and I can not see why.

On the unload of each scenario I am flushing the textures and removing all the objects from the world, the memory footprint does not grow over time, so I assume there are no leaks or lost object.

Can you give me a hint on what can be causing it?

Thanks a lot.

Quote from: EgonOlsen on May 18, 2011, 11:26:45 AM
The last code snippet can't work, because when calling build() before assigning the animation, the object will be compiled for static mode.
In the second snippet, calling animate(0) before calling build() is also questionable. Have you tried to swap those calls?

I was just pointing that I tried several combinations, I know calling build() before assigning the animation should not work, and that's what it does.

Edit:

if I swap animate & build It actually works,

I was sure I had tried all possible combinations, thanks!

The strange thing is, it works with the other version of the library.

Oh, and animation is loaded like this:

Object3D [] animationFrames = Loader.load3DS(res.openRawResource(R.raw.animation), 1);

for (int i=0; i<animationFrames.length; i++) {
animationFrames[i].build();
}
animation = new Animation(animationFrames.length);
animation.createSubSequence("animation_1");
for (int i=1; i<animationFrames.length; i+=5) {
animation.addKeyFrame(animationFrames[i].getMesh());
}
animation.setClampingMode(Animation.USE_WRAPPING);
animation.setInterpolationMethod(Animation.LINEAR);


I was writing this when you answered.

Just to be clear, I want an object on screen that when you click something starts animating.

What I have found so far is

if I do:

world.addObject(object);
object.build();

The object is displayed fine without animation (animation is not set)

If I do:

world.addObject(object);
object.setAnimationSequence(animation);
object.animate(0);
object.build();

The object is not displayed until the animation starts. This worked fine with the version of the library that does not have the Overlays patch.

If I do:

world.addObject(object);
object.build();
object.setAnimationSequence(animation);
object.animate(0);

The object is displayed but the animation does not work:

Now, something strange.

If I use this library, which makes Overlays work, animations are messed up.

I have an object in which I set an animation. With the previous version of the library it was displayed fine. With this version it does not display until I modify the animation.

This should not be a problem if I could set the animation to a default frame when adding the object to the world, but that does not work.

If I don't set the animation, it renders properly.

Any idea of what can I do to solve this or why is it happening?

Thanks for the info, I was having the exact same problem and the new library worked straight away.

AFAIK the latest version on the web still has this problem.