Differences between jPCT and jPCT-AE

Differences between jPCT and jPCT-AE

Wording

In the following sections, i'm going to use AE for jPCT-AE and jPCT for desktop jPCT.

Classes, packages and methods

The basic structure of jPCT and AE doesn't differ that much. If you are familiar with jPCT, you'll instantly find your way into AE. However, AE is smaller. It lacks some options of jPCT, because of hardware and software limitations of the underlying platform and some cleanup work. Here's a brief overview about the main differences:

• there's no procs nor threading package in AE.
• the util package is there, but it contains less classes. The Light class has moved into the main package and it's now the default way of creating lights in AE.
• the methods to work with lights in World are all gone in AE. Use the Light class instead.
• software and hybrid hardware mode are gone. AE uses compiled objects only.
• there's no need to explicitly compile an Object3D, AE does this automagically. However, there is a method in World to compile all objects in the world that desktop jPCT doesn't have.
• portal rendering has been removed. I'm not sure if it works properly in jPCT anyway, because no one ever really used it for years.
• image, texture and color handling is different, simply because Android has no AWT package or classes.
• ...

Afterall, AE looks and feels like the little brother of jPCT. While jPCT is pretty easy to use, AE is actually even simpler.

Porting

AE provides the 3D engine only. It doesn't provide any Activity example or framework for Android. You'll find some example code on the AE-homepage. So porting from jPCT to AE means to port from your native OpenGL window or AWT/Swing component with its key and mouse polling and/or listeners to an Android Activity...and vice versa. To ease porting, I suggest to use the Light class for managing lights in jPCT, not the methods in World. That way, you can simply port those sections by changing the import only (because the Light class has moved from util into the main package). It's cleaner that way anyway...

Performance and memory issues, serialized objects

On the desktop, memory and performance are to spare...at least to a degree. On Android, this isn't the case. Remember that you have to work with a max memory of 16mb on older devices...and coming close to that border isn't really fun, so you should plan to use some mb less. CPU power is limited too and some older phones don't even have a FPU, meaning that all the floating point calculations are done in software emulation mode.

Apart from the usual tips like using low polygon models and lowres textures, there's one thing that really helps: Using serialized objects! For this, desktop jPCT comes with the DeSerializer class. While it can be used within jPCT only, it's main purpose is to be used in combination with AE. The idea is to load the models in jPCT and serialize them into an optimized format that can be loaded by AE very quickly. AE has no DeSerializer class but a method to load these objects in Loader. Loading objects serialized by jPCT is the fastest way to load in AE and it's also the most memory saving way. I can only recommend it! It's a bit painful to use right now, because there comes no tool with the engine that loads the models and does the serialization for you, so you have to write your own code for this. Or, if you are using Eclipse, have a look at this plugin: Mesh serializer plugin

If you are using serialized objects in AE, remember two things:

• serialize them in reduced mode (check out the method signature of serialize(...) for this). AE will load none-reduced models too, but it's a waste of time and memory.
• call build() on them before serializing them. AE will recognize this and can optimize it's own build()-process if some of the work is already done.

If possible, use strip() on your Object3Ds after loading them in AE. It will free some of the precious memory.

For more performance tips, look at Performance tips for Android .

The wiki and AE...

Is the information in the wiki outside the AE section valid for AE? Yes, to a degree. The basic stuff like coordinate systems is the same of sources, the more advanced stuff usually isn't applicable without knowing about the differences.