First alpha version released

[EgonOlsen]

I'm studying software engineer at the moment in Switzerland, and I would like to use jPCT-AE inside a school project.
But at moment I'm quite annoyed, I tried by many ways to run the demo (compiled from source) in my nexus one
but I only get a black screen. I tried with a friend spica samsung who's based on 1.5 and I did not success either.

So I decided to rewrite it a little bit to understand how things work and I got stuck in the same place... A black screen at start.
(It does work inside the emulator)

I attached my modified version of your demo.

Looks like as if it stops before being able to do anything...no idea why. Maybe this line in the log: "03-17 23:05:58.742: ERROR/AndroidRuntime(1125): ERROR: thread attach failed" is an indicator of some problem, but i have no idea what this should be (I've never seen this message on my phone, which is a Samsung i7500 running 1.5). I'm not claiming that my way of creating the Activity is the right way. It's just something that i took from some example and modified it to work with jPCT-AE. Maybe i'm doing something really stupid!? Then again, some people already tried it on an actual phone and it worked fine for them. I suggest to put some logging in all these start/stop/pause/resume/create/...-methods to see what actually happens and post the results. Maybe that will help.

But what I would like to say is that all member of a class are set to null if they are pointers to object,
0 if they are primitive types like int,float etc. and all booleans are set to false.
If you do it by yourself, the vm will do twice the work settings all the members to your settings.
exemple  private boolean abool = false;
will be set 2 times, a default to false then false again forced by the =.

It's a matter of taste IMHO. Maybe it's more work for the vm (i'm not even sure about this, because it would be very stupid of the compiler to create code that does redundant settings to false, but then again, the java compiler is pretty stupid), but even on Android's slow Dalvik-VM, this won't hurt in any way. Change it to the way you like, i don't mind which way one uses. I'm using both ways myself, i have to real preference here.

I saw that you use floats and arrays in your demo.
I'm not an expert but what I read is that float operations are not well managed by this kind of devices.
-> http://developer.android.com/guide/practices/design/performance.html#avoidfloat

You can't avoid float in a 3D engine. Back in the "good old days" of 386-CPUs, people (including myself) were writing this 3D stuff in assembler and used fixed-point instead, because there was no fpu. But the engines and the graphics were a whole lot simpler in the old days. You can't do what a modern engine does in fixed-point without going mad and asking for trouble (accuracy problems, overflows,...). Apart from that, fixed-point isn't really that much faster on Android...i did some tests. Actually, the fpu-emulation code seems to be pretty good. And more recent chipsets will (i *think* the Nexus one already does...) include a fpu anyway.

I saw that you are having trouble with animations (low framerate)
I don't know how you register/store all the informations but perhaps hashmaps,
arraylist or linkedlist.
Do a better work than simple arrays, for example to search something in an array if you have not the exact position
you can have a search algorithm in O(n²) which is not great hashmaps will find the information in O(n) or very close too which is really faster.

Very bad idea for storing geometry data. An ArrayList for example is nothing more than a wrapper around an array (hence the name....), which can never be faster than the direct array access. HashMaps are used in jPCT for calculating normals and texture coordinates and stuff and it really helps there, but it's not a good place to store geometry in. And you don't have to, because you simply don't need to search this data. The best idea is to keep your data structures as close as possible to what OpenGL uses, which are plain float buffers in direct memory. And animations are as fast as it gets now. The time is spend mostly in the process that copies the data from VM memory into native buffers...and you can't avoid this step.

Here is some tips from android to improve performance : http://developer.android.com/guide/practices/design/performance.html

Did almost everything that is mentioned there. Were applicable of course.

[zammbi]

And more recent chipsets will (i *think* the Nexus one already does...) include a fpu anyway.

I believe the snapdragon cpu has a fpu which the latest phones seem to use. The Milestone I believe I read that it also has an fpu cpu.

[EgonOlsen]

I believe the snapdragon cpu has a fpu which the latest phones seem to use. The Milestone I believe I read that it also has an fpu cpu.

I think so too, which is why i'm very interested in some results from one of those devices.

[dl.zerocool]

Hi !

I wasn't hopping that you answered all my questions, thank you !

I understand your choice about floating point and yes I was thinking on fixed points (I worked on Nintendo DS system, where most of the time included in 3D rendering I used fixed points)
Of course it's not comparable to Android hardware.

Nexus one does include an FPU, I would be proud to provide you more informations, just ask me and I'll try to answer all of your questions and make the corresponding tests.
As I said I'm doing a project with 2 other people in my classroom, it's a school project that we have to make in the next 12weeks, so I'm really interested in this project.

Depending on my classmates I'll share the project or parts of the project here, if you wish to.

Back to my problem, what I found strange is that on the  emulator it does run slowly but fine.
I will take a look and try to put some logs like you said.

Anyway I'll keep you informed.

Best regards,

dl.zerocool

ps: about your activity, I don't think there's any mistake.
All android code I've seen, use the same way to do it.
Perhaps that I miss something, I've no idea at moment, but be sure that I'll keep you informed as soon as I find.
Right now I'm pretty busy and not working on project (we have other classes to follow, project is a small part of my school).

And about your question concerning class members, yes it's quite stupid but is how it works.
Last 6 months I followed a "POO" sounds strange in English,it's (Object Oriented Development) in Java and C++.
And this was mentioned few times, of course I think it does not make any real performance problems even on Dalvik, like you said.

[dl.zerocool]

Hi,
I just wanted to say that I tried running your jpct-ae example apk with the nexus one and the Samsung spica, but the result was the same. A single black screen, so perhaps it does come from the engine.

Tell me what you think or if you have another apk that I can test.
Best greetings.

[EgonOlsen]

More likely from the Activity. The engine's core should be fine IMHO. I'll create a version with more logging in the Activity to be able to see what is going on here.

[dl.zerocool]

Thanks for the fast reply.

I'll be working on project tomorrow morning (here, Tue 8:28am now). If you post an apk, I'll try and give you feedbacks today but I'll not have time to dev anything today.

I already tried to log and see what's happening but didn't find anything interesting, except that everything seems to load correctly, models etc. Plus apparently the engine seems to be running as all methods OnDraw OnSurfaceChanged etc.. are all called correctly.
I could get fps in log so there's something running in the background.

[EgonOlsen]

I could get fps in log so there's something running in the background.

I'm confused now. How can you get fps in the log if the demo doesn't log any? It only blits them on screen, it doesn't print them into the log!? Are we actually talking about the same thing here?
Anyway, i've update the apk of the demo with a version that includes more logging and that doesn't clear the screen to black but to some shade of blue or purple or whatever. So it should be possible to see if it actually paints something (i.e. at least applies the new color) and if the scene isn't all black by accident.

If it still doesn't work, the complete log output might be helpful.

[dl.zerocool]

Good news I see something !
And it works pretty well (50fps)~

Here is the DDMS logcat with your new apk.

Code Select Expand

03-24 00:31:42.307: INFO/ActivityManager(128): Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.threed.jpct/.example.Demo }
03-24 00:31:42.347: INFO/jPCT-AE(3979): onCreate
03-24 00:31:42.347: INFO/jPCT-AE(3979): onResume
03-24 00:31:42.407: INFO/jPCT-AE(3979): onSurfaceCreated
03-24 00:31:42.427: INFO/jPCT-AE(3979): Loading Texture...
03-24 00:31:42.437: INFO/jPCT-AE(3979): Loading Texture...
03-24 00:31:42.457: INFO/jPCT-AE(3979): Loading Texture...
03-24 00:31:42.507: INFO/jPCT-AE(3979): Loading Texture...
03-24 00:31:42.527: INFO/jPCT-AE(3979): Loading Texture...
03-24 00:31:42.557: INFO/jPCT-AE(3979): Loading Texture...
03-24 00:31:42.637: INFO/jPCT-AE(3979): Adding Lightsource: 0
03-24 00:31:42.637: INFO/jPCT-AE(3979): OpenGL vendor:     Qualcomm
03-24 00:31:42.637: INFO/jPCT-AE(3979): OpenGL renderer:   Adreno
03-24 00:31:42.637: INFO/jPCT-AE(3979): OpenGL version:    OpenGL ES-CM 1.1
03-24 00:31:42.637: INFO/jPCT-AE(3979): OpenGL renderer initialized (using 2 texture stages)
03-24 00:31:42.637: INFO/jPCT-AE(3979): onSurfaceChanged/320/483
03-24 00:31:42.717: INFO/jPCT-AE(3979): Subobject of object 35/plane compiled using 2400 vertices in 54ms!
03-24 00:31:42.717: INFO/jPCT-AE(3979): Object 35/plane compiled to 1 subobjects in 76ms!
03-24 00:31:42.737: INFO/jPCT-AE(3979): Subobject of object 37/tree1 compiled using 690 vertices in 17ms!
03-24 00:31:42.737: INFO/jPCT-AE(3979): Object 37/tree1 compiled to 1 subobjects in 23ms!
03-24 00:31:42.757: INFO/jPCT-AE(3979): Subobject of object 38/tree2 compiled using 690 vertices in 16ms!
03-24 00:31:42.757: INFO/jPCT-AE(3979): Object 38/tree2 compiled to 1 subobjects in 23ms!
03-24 00:31:42.777: INFO/jPCT-AE(3979): Subobject of object 39/grass compiled using 264 vertices in 5ms!
03-24 00:31:42.777: INFO/jPCT-AE(3979): Object 39/grass compiled to 1 subobjects in 10ms!
03-24 00:31:42.777: INFO/jPCT-AE(3979): Subobject of object 36/rock compiled using 84 vertices in 2ms!
03-24 00:31:42.777: INFO/jPCT-AE(3979): Object 36/rock compiled to 1 subobjects in 3ms!
03-24 00:31:43.357: INFO/ActivityManager(128): Displayed activity com.threed.jpct/.example.Demo: 1025 ms (total 1025 ms)


I attached two screenshots, hope it will help you.


I could get fps using "Logger.log" with my modified version not with your apk.
and verify that everything was running fine by doing logs in every function in interesting code parts, to be sure that everything was done correctly and apparently it was.

[attachment deleted by admin]

[dl.zerocool]

another screenshot.

[attachment deleted by admin]

[EgonOlsen]

So there is some rendering going on, but colors are ignored completely. And that affects both, calculated vertex colors and colors given by a dedicated color array (for the fps blitting). Plus the blitting somehow looks garbled...strange. Can you take the example's source code (it doesn't include my latest changes though) and remove this part at the beginning:

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];
}
});


....maybe that helps. And whether it helps or not, can you please tell me what the log says about OpenGL vendor, renderer and such if removing that part?

[dl.zerocool]

I had already tried to remove this part before, and sorry, no it does not help .

opengl vendor is :

03-24 08:46:10.569: INFO/jPCT-AE(4838): OpenGL vendor:     Qualcomm
03-24 08:46:10.569: INFO/jPCT-AE(4838): OpenGL renderer:   Adreno
03-24 08:46:10.569: INFO/jPCT-AE(4838): OpenGL version:    OpenGL ES-CM 1.1
03-24 08:46:10.569: INFO/jPCT-AE(4838): OpenGL renderer initialized (using 2 texture stages)

So nothing changed, but Samsung spica (i5700) has another opengl vendor and it doesn't work either.

Perhaps is something wrong with the way you clear the buffer ?

[EgonOlsen]

No, you can't do anything wrong with a glClear. Something is wrong with either vertex colors (most likely) or texture upload (unlikely, because the alpha channel on the trees' leaves looks fine). I just have no idea what this should be ATM. The code works fine on my phone, in the emulator, on the G1 and finally the desktop version of jPCT uses it too and it works fine on a variety of GPUs.

So something on your phones has to be different...i just have no idea how to figure this out without an actual phone of that kind...

[dl.zerocool]

Well, I know that you can't do anything wrong with glclear, except calling it in the wrong place.
But it is really strange because I tested a lot of things, included basic 3d rendering and array colors do work like they have to.

Example a simple 3D Cube with colors work really fine. What is strange is that other 3D apps don't have any problem.

[dl.zerocool]

I'm unable to help you since the source code is closed, I already read about it on the forum, so don't worry I do understand.
If you want me to help in any way, let me know.
I would be proud to help, I'll continue searching by my side.