Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - zammbi

Pages: 1 [2] 3 4 ... 25
16
Support / Code uses OpenGL 1.0 instead of 2.0
« on: July 11, 2012, 05:43:06 am »
I'm suck on an interesting issue.

For inputting on CricHQ we need our the 3d to load as fast as possible so I have currently moved it to OpenGL 1.0 (the shaders were slowing resume on all devices too much).
Then for viewing the data I use OpenGL 2.0 so I have AA.

But I've found that turning on OpenGL 2.0 after 1.0 crashes (though opening 1.0 after 2.0 doesn't crash).
All the OpenGL 2.0 code runs without error which makes it hard to prevent the crash.

Code: [Select]
mGLView.setEGLContextClientVersion(2);
AAConfigChooser aa = new AAConfigChooser(mGLView, true);
mGLView.setEGLConfigChooser(aa);
Quote
07-11 15:35:15.725: I/jPCT-AE(9101): onCreate
07-11 15:35:16.319: I/jPCT-AE(9101): MSAA enabled with 2 samples!
07-11 15:35:16.319: I/jPCT-AE(9101): Unable to find a matching config...using default!
07-11 15:35:16.444: I/jPCT-AE(9101): Initializing GL20 render pipeline...
07-11 15:35:16.452: I/jPCT-AE(9101): Accessing shaders via JAR!
07-11 15:35:16.460: I/jPCT-AE(9101): [ 1341977716469 ] - ERROR: Shaders are not supported when using OpenGL ES 1.x!
07-11 15:35:16.483: I/jPCT-AE(9101): [ 1341977716495 ] - ERROR: java.lang.RuntimeException: [ 1341977716469 ] - ERROR: Shaders are not supported when using OpenGL ES 1.x!
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.Logger.log(Logger.java:189)
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.GLSLShader.check20(GLSLShader.java:266)
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.GLSLShader.<init>(GLSLShader.java:217)
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.GL20.<init>(GL20.java:117)
07-11 15:35:16.483: I/jPCT-AE(9101):    at java.lang.Class.newInstanceImpl(Native Method)
07-11 15:35:16.483: I/jPCT-AE(9101):    at java.lang.Class.newInstance(Class.java:1319)
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.GLRenderer.init(GLRenderer.java:374)
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.GLRenderer.init(GLRenderer.java:364)
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.FrameBuffer.<init>(FrameBuffer.java:90)
07-11 15:35:16.483: I/jPCT-AE(9101):    at com.threed.jpct.FrameBuffer.<init>(FrameBuffer.java:115)
07-11 15:35:16.483: I/jPCT-AE(9101):    at nz.co.nuffie.android.crichq.threedimensional.World3dBase.onSurfaceChanged(World3dBase.java:468)
07-11 15:35:16.483: I/jPCT-AE(9101):    at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1456)
07-11 15:35:16.483: I/jPCT-AE(9101):    at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1217)
07-11 15:35:16.499: I/jPCT-AE(9101): [ 1341977716506 ] - ERROR: java.lang.RuntimeException: [ 1341977716495 ] - ERROR: java.lang.RuntimeException: [ 1341977716469 ] - ERROR: Shaders are not supported when using OpenGL ES 1.x!
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.Logger.log(Logger.java:189)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.GLSLShader.check20(GLSLShader.java:266)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.GLSLShader.<init>(GLSLShader.java:217)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.GL20.<init>(GL20.java:117)
07-11 15:35:16.499: I/jPCT-AE(9101):    at java.lang.Class.newInstanceImpl(Native Method)
07-11 15:35:16.499: I/jPCT-AE(9101):    at java.lang.Class.newInstance(Class.java:1319)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.GLRenderer.init(GLRenderer.java:374)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.GLRenderer.init(GLRenderer.java:364)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.FrameBuffer.<init>(FrameBuffer.java:90)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.FrameBuffer.<init>(FrameBuffer.java:115)
07-11 15:35:16.499: I/jPCT-AE(9101):    at nz.co.nuffie.android.crichq.threedimensional.World3dBase.onSurfaceChanged(World3dBase.java:468)
07-11 15:35:16.499: I/jPCT-AE(9101):    at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1456)
07-11 15:35:16.499: I/jPCT-AE(9101):    at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1217)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.Logger.log(Logger.java:189)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.Logger.log(Logger.java:136)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.GLRenderer.init(GLRenderer.java:376)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.GLRenderer.init(GLRenderer.java:364)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.FrameBuffer.<init>(FrameBuffer.java:90)
07-11 15:35:16.499: I/jPCT-AE(9101):    at com.threed.jpct.FrameBuffer.<init>(FrameBuffer.java:115)
07-11 15:35:16.499: I/jPCT-AE(9101):    at nz.co.nuffie.android.crichq.threedimensional.World3dBase.onSurfaceChanged(World3dBase.java:468)
07-11 15:35:16.499: I/jPCT-AE(9101):    at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1456)
07-11 15:35:16.499: I/jPCT-AE(9101):    at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1217)


17
Support / Re: Load normals from file
« on: July 04, 2012, 02:51:24 am »
Quote
Whoever invented the OBJ-format has to suffer endlessly

Well the closest names responsible I could come up with is the founders of Wavefront.  :P
Quote
It was founded in 1984, in Santa Barbara, California, by Bill Kovacs, Larry Barels, Mark Sylvester.
http://en.wikipedia.org/wiki/Wavefront_Technologies


18
Support / Re: Basics: Is a clustering of used GUI elements to one bitmap practicable?
« on: June 28, 2012, 11:28:40 pm »
We had some crashes with OOM with android 3(annoying android 3.X bug which uses more memory) so we turned on
Code: [Select]
android:largeHeap="true"so that will help with that.

You could also use the Virtualizer class to help with some memory issues:
http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Virtualizer.html

Quote
Is anyone familiar with blitting text. The text should have a custom font style.
There's some posts on that, just use the search.

19
Support / Re: Basics: Is a clustering of used GUI elements to one bitmap practicable?
« on: June 28, 2012, 05:41:05 am »
I would have every GUI image in there own image. Load up the main used GUI images at the start of the app. Then load up the images when you need them. Store all images in a cache(the ones that track memory usage), which will release any non used images when low on memory. If there isn't many large GUI images on screen at the same time then this would work nicely.

20
Bugs / Re: JPCT crashed while debugging
« on: June 18, 2012, 10:21:30 am »
One boolean check extra per method is going to see a drop in performance? Couldn't you could leave out sensitive methods? Some would be better then nothing.
As for slow debugging I wouldn't mind, I just want to do a test every once and a while.
But I guess if it hurts the engine too much then yeah, I can live without it.

21
Support / Re: Better texture manger
« on: June 18, 2012, 09:21:19 am »
Maybe I'll give it a go if I get spare time at work.

Quote
One problem would be that in the case of low memory, it's actually to late to solve the issue by rescaling the textures because you would get a peek in memory usage while doing so
Following like the above link I would have it using X% amount of heap which the user can set. Therefore should allow resizing without any problems. Of course it's not perfect but I believe it would minimise out of memory issues.

Quote
the application should detect the environment it's running on and use the appropriate set of textures
That's what I'm doing, a lot of work and testing was needed and its perfect enough now for the little 3d we have got. However for me lots can happen outside the JPCT code and that's where the out of memory issues are happening and freeing textures will help.

22
Bugs / Re: JPCT crashed while debugging
« on: June 18, 2012, 09:02:56 am »
If its a debug flag(default off) I don't see the problem?

23
Support / Better texture manger
« on: June 18, 2012, 04:21:37 am »
I've had a couple of out of memory issues(outside of JPCT) and doesn't help that I keep all my textures in memory for fast reloading. So was looking into this: http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

But wondering if JPCT should have more advance texture manager options built in.

-If the app runs low on memory it will use the new virtualizer class for textures.
-If it still is out of memory then resize the textures down(largest first) until there is enough free memory.
-If textures are too small and still out of memory then unload unused textures until memory enough memory free.

Extra
-Have priority options for which textures should be resized smaller first.
-No longer use virtualizer once you get enough free memory back.
-If the textures been resized to be smaller previously, resize them back up if there is enough free memory(maybe resume only).

Such options would help me so much and I believe would help everyone else too.

24
Bugs / Re: JPCT crashed while debugging
« on: June 18, 2012, 12:15:44 am »
Yeah I was filtering PolyLines on the UI thread. Now fixed, no more crashes now.

I'm wondering if you can add some kind of debug flag so these can be picked up earlier? If the app is on the wrong thread it will crash the app or give a warning.

25
Support / Re: Texture/ memory usage ?!
« on: June 16, 2012, 06:15:39 am »
How big is the heap size on the device?
If it's 16 megs 512x512 images would quickly make it run out of memory.
512x512 is about 1 meg in ram I believe.

26
Bugs / JPCT crashed while debugging
« on: June 14, 2012, 05:24:00 am »
JPCT crashed when I resumed from debugging. Using the current stable version.

Quote
06-14 15:20:35.014: ERROR/AndroidRuntime(32289): FATAL EXCEPTION: GLThread 4465
        java.lang.IndexOutOfBoundsException: Invalid index 5, size is 5
        at java.util.ArrayList.throwIndexOutOfBoundsException(ArrayList.java:251)
        at java.util.ArrayList.get(ArrayList.java:304)
        at com.threed.jpct.World.draw(World.java:1319)
        at com.threed.jpct.World.draw(World.java:1074)
        at nz.co.nuffie.android.crichq.threedimensional.World3dBase.renderWorld(World3dBase.java:678)
        at nz.co.nuffie.android.crichq.threedimensional.World3dBase.onDrawFrame(World3dBase.java:732)
        at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1463)
        at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1217)
06-14 15:20:35.022: WARN/ActivityManager(195): Force finishing activity nz.co.nuffie.android.crichq/.threedimensional.OfflineViewWorld3dActivity

Edit: Actually this might be my fault. Looks like it might be a threading issue.


27
Support / Re: Version updates!
« on: June 08, 2012, 12:50:52 am »
Quote
because at the time i implemented it, i wasn't sure if i would keep it.
Why's that?
I noticed it also slows down resuming. Seems like it compresses the images again on resume? I thought it would do it once and only use the ETC1 compressed textures. Unless I'm mistaken?

28
Support / Re: Version updates!
« on: June 07, 2012, 11:47:43 pm »
Sounds awesome. Though since I need to keep resume times fast doesn't sound like I can use it.

Isn't also ETC1 texture compression new in this version?

29
Support / Re: Version updates!
« on: June 07, 2012, 02:18:50 pm »
Could you explain a little more detail on the Virtualizer?

30
Support / Re: A lot of errors EGL_BAD_ALLOC ?
« on: June 04, 2012, 11:19:29 pm »
From which device(s)? Which OpenGL version?

If it's a driver issue probably not much can be done: http://www.jpct.net/forum2/index.php/topic,2624.0.html

Pages: 1 [2] 3 4 ... 25