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 - AeroShark333

Pages: 1 2 [3] 4 5 ... 12
31
Support / Crash (native)
« on: July 10, 2017, 07:29:06 pm »
Hello,


There are some issues with my app on some devices and I don't really know what's causing it...
Code: [Select]
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'motorola/surnia_retbr_dstv/surnia_udstv:6.0/MPI24.65-39-4/3:user/release-keys'
Revision: 'p30d'
ABI: 'arm'
pid: 4182, tid: 4448, name: GLThread 17896  >>> com.aeroshark333.artofearthify <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa336f000
    r0 a336dab0  r1 a336dd10  r2 00000190  r3 a336efec
    r4 00000654  r5 9daa3d00  r6 a336e9b8  r7 a336e364
    r8 00000208  r9 00000000  sl 00000004  fp 00000000
    ip 00000020  sp a1c05528  lr a336edac  pc ac7a5396  cpsr 200f0030

backtrace:
    #00 pc 000bc396  /system/vendor/lib/egl/libRBGLESv2_adreno.so (oxili_tile_texture+637)
    #01 pc 000917a3  /system/vendor/lib/egl/libRBGLESv2_adreno.so
    #02 pc 000935c9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_update_hw_subimage+4204)
    #03 pc 000949d7  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_loadimage+224)
    #04 pc 0006e6b9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (TexImageLoad+216)
    #05 pc 0006e933  /system/vendor/lib/egl/libRBGLESv2_adreno.so (core_glTexImage2D+234)
    #06 pc 0004cd3b  /system/vendor/lib/egl/libRBGLESv2_adreno.so (glTexImage2D+50)
    #07 pc 0006b5cf  /system/lib/libandroid_runtime.so
    #08 pc 02d6f84d  /system/framework/arm/boot.oat (offset 0x1feb000)
Code: [Select]
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'motorola/surnia_retbr_dstv/surnia_udstv:6.0/MPI24.65-39-4/3:user/release-keys'
Revision: 'p30d'
ABI: 'arm'
pid: 3892, tid: 4136, name: GLThread 17925  >>> com.aeroshark333.artofearthify <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x9fa331a8
    r0 9fa32500  r1 9fa32520  r2 00000190  r3 9fa337fc
    r4 00000654  r5 9f386e00  r6 9fa331a8  r7 9fa32b74
    r8 0000014c  r9 00000000  sl 00000004  fp 00000000
    ip 00000032  sp a02ff528  lr 9fa337fc  pc ac7a538e  cpsr 800f0030

backtrace:
    #00 pc 000bc38e  /system/vendor/lib/egl/libRBGLESv2_adreno.so (oxili_tile_texture+629)
    #01 pc 000917a3  /system/vendor/lib/egl/libRBGLESv2_adreno.so
    #02 pc 000935c9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_update_hw_subimage+4204)
    #03 pc 000949d7  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_loadimage+224)
    #04 pc 0006e6b9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (TexImageLoad+216)
    #05 pc 0006e933  /system/vendor/lib/egl/libRBGLESv2_adreno.so (core_glTexImage2D+234)
    #06 pc 0004cd3b  /system/vendor/lib/egl/libRBGLESv2_adreno.so (glTexImage2D+50)
    #07 pc 0006b5cf  /system/lib/libandroid_runtime.so
    #08 pc 02d6f84d  /system/framework/arm/boot.oat (offset 0x1feb000)

The device is a Motorola Moto E with 4G (2nd Gen) running Android 6.0.
I can't reproduce this crash myself on any of my devices.

32
Support / Re: render order of opaque objects?
« on: June 27, 2017, 02:18:37 pm »
I don't think it works that way... I thought there would be some depth checking for the Object3D's when it comes to rendering order

33
I was just wondering about this multipass rendering thing...
Is it not possible to use one single rendertarget for multipass rendering? (so with every pass the rendertarget is used for blitting)
I wonder why in this thread at least 2 rendertarget textures were needed.

In this thread:
Render world into rendertarget1.
Blit rendertarget1 into rendertarget2 (with blit shader 1)
Blit rendertarget2 into the normal framebuffer (with blit shader 2)

But why not just this?:
Render world into rendertarget1.
Blit rendertarget1 into rendertarget1 (with blit shader 1)
Blit rendertarget1 into the normal framebuffer (with blit shader 2)

I kind of tried the second method but it didn't really work...
Though I wonder why it didn't work

34
Projects / Re: Art of Earthify (3D live wallpaper)
« on: June 02, 2017, 08:43:01 pm »
Hmmm, I see... it's probably because of the other error then in my previous post...
It might not seem like it's crashing but I think it does (and it automatically reports it to the Google Play Developer Console)
(Google changed some things that bugs get reported automatically sometimes.
But it's nice to hear that it's still functional nonetheless :)

35
Projects / Re: Art of Earthify (3D live wallpaper)
« on: June 01, 2017, 12:56:04 pm »
Thanks a lot!
I guess I solved it for the live clouds (silly mistake really...  ::) haha)

I got another crashreport though (I think from your device)
However, I have nooo idea how to solve this one...  :-\
Though when looking at the stacktrace, it looks like some kind of crash I used to have earlier on my current phone and previous phone...
Which I kind of solved then by having 'Config.blittingMode = 8'...
I added an option in the live wallpaper settings for that mode: Settings -> Renderer -> Blit compatibility mode

Stacktrace:
Code: [Select]
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR)

backtrace:
  native: pc 0000000000016a3c  /system/lib/libc.so (__memcpy_base+92)
  native: pc 000000000002070d  /system/vendor/lib/libgsl.so (ioctl_kgsl_sharedmem_write+108)
  native: pc 0000000000096095  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_vbo_cache_vertex_attrib+348)
  native: pc 0000000000059fc1  /system/vendor/lib/egl/libRBGLESv2_adreno.so (cache_vertex_array+566)
  native: pc 000000000005a34d  /system/vendor/lib/egl/libRBGLESv2_adreno.so (cache_vertex_elements+792)
  native: pc 000000000005d891  /system/vendor/lib/egl/libRBGLESv2_adreno.so (core_glDrawElementsInstancedXXX+332)
  native: pc 000000000005da39  /system/vendor/lib/egl/libRBGLESv2_adreno.so (core_glDrawElements+10)
  native: pc 000000000004c55d  /system/vendor/lib/egl/libRBGLESv2_adreno.so (glDrawElements+28)
  native: pc 0000000002235c05  /system/framework/arm/boot.oat

36
Projects / Re: Art of Earthify (3D live wallpaper)
« on: May 31, 2017, 12:26:12 am »
Thank you for the positive feedback! :)

About the app not responding things... Is it possible to press 'Report' when the dialog pops up?
So I can know from the Google Play Developer Console where exactly the app hangs because I'm not really experiencing what you have myself with all the devices I got... :/

37
Support / Re: Camera rotation
« on: May 30, 2017, 08:01:51 am »
Hmmm, perhaps it would work to keep a variable of the total rotation in X and Y.
And in onDraw clear the camera rotation everytime and apply the total (cumulative) X and Y rotations... (I think that should avoid getting a rotation in Z). (Clearing the rotation here means resetting te camera to the default rotation)

I don't really know how to do this otherwise, sorry.

38
Projects / Art of Earthify (3D live wallpaper)
« on: May 28, 2017, 02:34:19 am »
Hey everyone,

I wanted to share my newest live wallpaper I made using this library! :)
The live wallpaper is actually based on a previous live wallpaper I made but I was not really satisfied with the result there.
I didn't work on this project too much due to studies but when I had some free time I'd be working on this.
Anyhow, I am really satisfied with the outcome of how it is now. :D

Original project: http://www.jpct.net/forum2/index.php/topic,4784.0.html (I just noticed all these dead links but I blame DropBox for that... ::) )

Screenshot 1: https://www.dropbox.com/s/a5onfgj9xufh3x2/Screenshot_20170527-035027.png?dl=0
Screenshot 2: https://www.dropbox.com/s/0abyljwul7aq5iv/Screenshot_20170527-035152.png?dl=0
Screenshot 3: https://www.dropbox.com/s/67hxhxzgsvsdgwu/Screenshot_20170527-035235.png?dl=0
Screenshot 4: https://www.dropbox.com/s/es5p07x921ikldl/Screenshot_20170527-035940.png?dl=0
Screenshot 5: https://www.dropbox.com/s/acfh1fc2leio64o/Screenshot_20170527-202014.png?dl=0
Screenshot 6: https://www.dropbox.com/s/xpi7taolx8xxl2d/Screenshot_20170527-040223.png?dl=0

Download link: https://play.google.com/store/apps/details?id=com.aeroshark333.artofearthify

I'd like to thank 'Egon Olsen' as always for the amazing library :)

Feel free to comment :)

Cheers,
AeroShark333

39
Support / Re: Camera rotation
« on: May 28, 2017, 02:11:46 am »
Ah... I used to have an issue similar to yours, this is how I fixed it.
I avoid using the Camera.lookAt method because I think that's where the vertical twitching you described happens.

Anyway, my fix:

Create 2 variables for touch input:
private float touchX;
private float touchY;

In your touch listener:
touchX += some calculation for a dragging single finger;
touchY += some calculation for a dragging single finger;

In OnDraw:
camera.rotateX(touchY);
touchY = 0.0f;
camera.rotateY(touchX);
touchX = 0.0f;
camera.setPosition(someObjectYouWantToRotateAround.getTransformedCenter());
camera.moveCamera(Camera.MOVEOUT, someRadiusYouWantToRotateAroundTheObject);

Maybe not the neatest way but it worked for me :)

40
Support / Re: add/reduce texture stages at runtime?
« on: May 20, 2017, 10:25:51 am »
I think you could write something that generates noise in the fragment shader (which you can make dependant on the camera distance).

http://byteblacksmith.com/improvements-to-the-canonical-one-liner-glsl-rand-for-opengl-es-2-0/
I tried this one myself and it works fine on most devices (not all devices output the same though...)

41
Support / Re: Could not link shader program error
« on: May 06, 2017, 09:24:30 pm »
A small question about the default shaders...
I took a look at the default vertex shader you made for Vivante and the regular default vertex shaders...
Though, I don't really see much of a difference than that addColor method/function that replaces the regular color adding lines in the main method/function.
How is this a fix for Vivante chips? It does the exact same thing...

EDIT:
Well I fixed the issue I guess but it was really annoying to fix this...
But basically, I just moved some variables to the vertex shader as varying variables that would otherwise have been calculated in the fragment shader...

What wouldn't work is this for example (not my actual code but for example...):
#vertex shader
Code: [Select]
varying float angle;
varying float variable1;
varying float variable2;

void main(){
   angle = 0.5;
   variable1 = 0.1;
   variable2 = 0.2;
}

#fragment shader
Code: [Select]
varying float angle;
varying float variable1;
varying float variable2;

const vec4 col1 = vec4(1.0);
const vec4 col2 = vec4(0.75);
const vec4 col3 = vec4(0.5);

void main(){
   if(angle<0.0){
      col = mix(col1,mix(col2,mix(col3,col4,-angle),variable1),variable2);
   }else{
      col = col1;
   }
}

So my fix would basically have been this...:
#vertex shader
Code: [Select]
varying float angle;
varying float anglePos;
varying float variable1;
varying float variable2;

void main(){
   angle = 0.5;
   anglePos = -angle;
   variable1 = 0.1;
   variable2 = 0.2;
}

#fragment shader
Code: [Select]
varying float angle;
varying float anglePos;
varying float variable1;
varying float variable2;

const vec4 col1 = vec4(1.0);
const vec4 col2 = vec4(0.75);
const vec4 col3 = vec4(0.5);

void main(){
   if(angle<0.0){
      col = mix(col1,mix(col2,mix(col3,col4,anglePos),variable1),variable2);
   }else{
      col = col1;
   }
}

Something like that...

Anyway, thanks for the help!
I guess it's all sorted now

I can extend the limit to 16384 or 32768 in the next version...no problem with that.
And thanks for this too if it will happen :)

42
Support / Re: Could not link shader program error
« on: May 06, 2017, 11:22:13 am »
Still couldn't solve the issue... :/

But I found something interesting maybe (which I suppose is the GPU/driver output)... (And yes, I'm catching the RuntimeException in onDrawFrame)
Code: [Select]
05-06 11:11:33.501: I/jPCT-AE(18608): Compiling shader program!
05-06 11:11:33.666: D/v_gal(18608): [tid=18725] gcmONERROR: status=-16(gcvSTATUS_OUT_OF_RESOURCES) @ gcLINKTREE_GenerateStates(11559)
05-06 11:11:33.666: D/v_gal(18608): [tid=18725] gcmERR_BREAK: status=-16(gcvSTATUS_OUT_OF_RESOURCES) @ gcLinkShaders(7848)
05-06 11:11:33.666: E/jPCT-AE(18608): [ 1494061893674 ] - ERROR: Could not link shader program:
05-06 11:11:33.666: W/System.err(18608): java.lang.RuntimeException: [ 1494061893674 ] - ERROR: Could not link shader program:
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.Logger.log(Logger.java:206)
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.GLSLShader.createProgram(GLSLShader.java:1131)
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.GLSLShader.loadProgram(GLSLShader.java:1113)
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.GLSLShader.preInit(GLSLShader.java:301)
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.GL20.setShader(GL20.java:388)
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.GLRenderer.setShader(GLRenderer.java:567)
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.CompiledInstance.render(CompiledInstance.java:191)
05-06 11:11:33.666: W/System.err(18608): at com.threed.jpct.GLRenderer.drawVertexArray(GLRenderer.java:2472)
05-06 11:11:33.673: W/System.err(18608): at com.threed.jpct.World.draw(World.java:1426)
05-06 11:11:33.673: W/System.err(18608): at com.threed.jpct.World.draw(World.java:1109)
05-06 11:11:33.673: W/System.err(18608): at com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame(LiveWallpaperRenderer.java:1155)
05-06 11:11:33.673: W/System.err(18608): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1524)
05-06 11:11:33.673: W/System.err(18608): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1248)

Fragment shader variables:
Code: [Select]
precision highp float;
precision highp int;
precision highp sampler2D;


uniform sampler2D textureUnit0;
uniform sampler2D textureUnit1;
uniform sampler2D textureUnit2;

uniform int textureCount;

uniform float visualizer;
uniform vec2 transparencies;
uniform float random;
uniform vec2 location;

varying vec2 texCoord[3];
varying vec2 eyeVec;
varying vec4 sunEyeData;

const vec4 BLACK = vec4(0,0,0,1);
const vec4 WHITE = vec4(1,1,1,1);
const vec3 SATURATIONFORMULA = vec3(0.2125, 0.7154, 0.0721);
const float RANDA = 12.9898;
const float RANDB = 78.233;
const float RANDC = 43758.5453;

const vec3 SATURATION = vec3(0.60,1.0,1.0);
const float ATMOSPHERE = 0.18;
const vec4 ATMOSPHEREPRIMARY = vec4(0.318, 0.341,0.741,1.0);
const vec4 ATMOSPHERESECONDARY = vec4(1.0, 1.0,1.0 ,1.0);
const vec4 ATMOSPHERETERTIARY = vec4(0.0,1.0,1.0,1.0);
const float CLOUDSSHADOW = 0.00018333;
const float SHADOW = 0.66;
const vec3 LIGHTS1 = vec3(1,1,1);
const vec3 LIGHTS2 = vec3(1,1,1);
const vec3 LOCATIONCOLOR = vec3(1.0,0.0,0.0);
const vec4 REFLECTIONCOLOR = vec4(1.0,1.0,1.0,1.0);

Any ideas?
This shader does work just fine on most devices so I don't really know... (well the only case I found it not working was with my brother's phone which has a Vivante chip)

43
Support / Re: Could not link shader program error
« on: May 04, 2017, 12:49:37 pm »
But how should I know how many varying your shader uses? I would have to parse the shader for that. If a shader fails to compile, jPCT-AE will print out the error reported by the driver. Actually, this error should indicate the problem. If your driver doesn't provide such a message...well, that's another story. These Vivante chips are a piece of junk anyway. The latest jPCT-AE version provides an additional set of shaders for Vivante only, because the normal default shaders just refused to work on these chips. Make sure to use 1.31.

About the limit of 8192...it's just an artifical limit caused by some constants. I could easily extend it to 16384 or higher. But a 16384*16384 textures uses 1 GB of texture memory (without mipmaps)...what's the point of that on a mobile device?
A 16384*8192 texture would use 512MB I guess then... which high-end phones are able to support... (at least my Axon 7 can have a VM heap up to 1 GB) While it maybe has no real purpose (yet) it could be enabled for future-proofing reasons I guess :)
Or... Are there plans for a OpenGLES 3.0 (or higher) version of jPCT-AE?

44
Is using an shader for an Overlay-Object3D here better than using a blitshader?
I think effectively you can reach the same goals..? But what would be faster here?
It shouldn't really matter. Which one is better is merely a matter of taste. Blitting into render targets can require some coordinate adjustments, so using an Overlay might be more intuitive for some though.
And performance-wise?

45
Is using an shader for an Overlay-Object3D here better than using a blitshader?
I think effectively you can reach the same goals..? But what would be faster here?

Pages: 1 2 [3] 4 5 ... 12