When developing with jpct-ae I noticed the following:
Also some questions:
- someFramebuffer.display() is not required for a Galaxy SIII, Tegra 3 GPUs seem to require it on the other hand
- The .display() method does not trigger a screen refresh, only after .onDrawFrame() finished the screen will refreshed, this is troublesome when blitting a loading screen that only should be blitted once because the logic behind the actual loading has to happen in the frame AFTER the blitting. This is probably because of GLSurfaceView, see http://developer.android.com/reference/android/opengl/GLSurfaceView.html for more details.
Alternativly do the loading outside the render thread, this is discouraged (see jpct documentation) - All rotation is done using radians this is nothing bad, but not noted in many places.
- According to the documentation http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#nearPlane the near clipping plane is 1 at default, may want to set this to 0.1 if you use the coordinates as meters, else clipping might happen pretty soon if you use a camera for first person view
A solution for android picture rescaling, this will spare you the time and RAM needed for resizing loaded textures, all examples on the jpct wiki use a strange way of letting Android rescale a picture then rescale it back and the convert it to textures this is unnecessary complex.
Code Select
package com.example.game.loaders;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory.Options;
/**
* Contains necessary options to load files correctly with the BitmapFactory
*/
public class BitmapLoadOptions extends Options{
/*Constructor*/
public BitmapLoadOptions(){
this.inPreferQualityOverSpeed = true; //We have the time to load the textures
this.inScaled = false; //Don't scale the textures to fit dpi, this would result in non power of 2 textures which are rejected by JPCT
this.inJustDecodeBounds = false; //Decode the actual data instead of just looking for the boundaries
this.inPreferredConfig = Bitmap.Config.ARGB_8888; //Set the format of the Bitmap
}
}
Code Select
package com.example.game.loaders;
import java.io.*;
import ai.pathfinding.Map;
import android.content.res.AssetManager;
import android.graphics.*;
import android.util.Log;
import com.threed.jpct.*;
/**
* Helper class to load textures
*/
public class DataLoader {
public static Texture loadTexture(String path, AssetManager assetManager) throws IOException{
return loadTexture(path, assetManager, false);
}
public static Texture loadTexture(String path, AssetManager assetManager, boolean hasAlpha) throws IOException{
if(path == null){ throw new IllegalArgumentException("Path given is null"); }
if(assetManager == null){ throw new IllegalArgumentException("Asset manager is null"); }
return new Texture(BitmapFactory.decodeStream(assetManager.open(path), null, new BitmapLoadOptions()), hasAlpha);
}
}
Also some questions:
- If the total number of frames in an Animation is needed a workaround is required: sum the length of all AnimationSequence-s or by call getKeyFrames().length, a separate method would be nice, or is there a better way?
- Reusing a FrameBuffer after flushing the TextureManager will introduce a memory leak (probably not a bug simply because jpct is coupled loosly together) because the references to the Textures are still in the FrameBuffer. Didn't find this in the documentation: A call to http://www.jpct.net/jpct-ae/doc/com/threed/jpct/FrameBuffer.html#freeMemory%28%29 is required, this should be noted in the documentation in TextureManager.flush() and Framebuffer.freeMemory()
- A method for getting the x/y/z rotation of a Object3D would be really, really nice, I still have no idea how to get the actual values out of the rotation matrix
- Mind open sourcing the config chooser for the Tegra chips? No idea how to do this without the SDK from NVidia. You used some constant right?
http://www.jpct.net/jpct-ae/doc/com/threed/jpct/util/NVDepthConfigChooser.html
I had to use my own config chooser but I still require the better depth buffer so I can't use yours - Probably a bug or a non documented limitation: Textures with a size of 1x1 (2^0) and 2x2 (2^1) can not be created because jpct-ae says the size is too small. Didn't test 4x4 and upwards, or should this be like that? The loader code is the same code as posted above
beim erstmaligen laden, dafür habe ich nichts im RAM, da wäre eine Referenz auf die ursprüngliche Datei noch geschickter. Einziger Vorteil ist das TextureID usw. erhalten bleiben, richtig?