It is working on my phone although it looks a bit different than on my computer: shader1 is working, shader2 seems to generate all white image. No crashes.
Can you please post the full log and I can see if I can find any clues to what is wrong?
Otherwise all I can recommend is that you try simplifying the GLSL code until it works. It could be a buggy graphics driver on your device.
Helping with GLES 2.0 shaders
Moderator: Moderators
Hi Ville, you were right. I tested the shaders on Nexus 7 and they worked, even if their performance is very bad. I thought GLSL is much faster on this device.
I also observed a problem with ZApplication's properties ViewportWidth, ViewportHeight, ScreenWidth and ScreenHeight on Android: they are all 100 in OnLoad section. Only in OnUpdate section they return correct values. That's the reason why shaders from the example do not work correctly on Android. Attached is the corrected example.
I also observed a problem with ZApplication's properties ViewportWidth, ViewportHeight, ScreenWidth and ScreenHeight on Android: they are all 100 in OnLoad section. Only in OnUpdate section they return correct values. That's the reason why shaders from the example do not work correctly on Android. Attached is the corrected example.
- Attachments
-
- shaderTest2.zgeproj
- corrected example
- (7.44 KiB) Downloaded 417 times
From the log file it can be seen that it crashes in the compileshader call (inside the driver). This is evidence of a buggy driver.
We should probably add a new kind of event, App.OnSurfaceCreated. Which would be called when the OpenGL surface is created and the dimensions are known. On Android this could be called multiple times since the surface is recreated (by the OS) in various situations (switch focus to another app and then back, turn of screen etc). For ZGE projects that make OpenGL calls from scripting this would be the place to create VBOs etc.
We should probably add a new kind of event, App.OnSurfaceCreated. Which would be called when the OpenGL surface is created and the dimensions are known. On Android this could be called multiple times since the surface is recreated (by the OS) in various situations (switch focus to another app and then back, turn of screen etc). For ZGE projects that make OpenGL calls from scripting this would be the place to create VBOs etc.
Last edited by VilleK on Thu May 30, 2013 1:41 pm, edited 1 time in total.
Hmm,
I'd go with a function that return the state* of the Android app instead. Adding a event to the primary component that's only used for Android projects which use raw OpenGL objects is not worth the additional clutter & confusion.
*So for example, when onResume is called the value is 0x2 or something.
K
I'd go with a function that return the state* of the Android app instead. Adding a event to the primary component that's only used for Android projects which use raw OpenGL objects is not worth the additional clutter & confusion.
*So for example, when onResume is called the value is 0x2 or something.
K
Hi Kjell,Kjell wrote:I'd go with a function that return the state* of the Android app instead.
but when to call the function, in OnUpdate? This would be not optimal, because it is called always during application running. In addition there's explicit application event when the OpenGL surface is created and the content of this special section is called. I see special section as more transparent solution. The rule can be: non-graphical application initialization put to OnLoaded and GUI-related things to OnSurfaceCreated...
Also CharCode 255/254 in KeyPress used for application pause and resume is not optimal from this POV. What about to change them to sections of ZApplication and AppState components? On Windows, they can be mapped to loosing focus or something similar.
Ehm,
K
One additional call ( per frame ) to a function that only returns a integer isn't going to make a dent in performance whatsoever.Rado1 wrote:but when to call the function, in OnUpdate? This would be not optimal, because it is called always during application running.
It's a event that shouldn't be there ( ideally ) in the first place. Plus, you'll only be using it in conjunction with direct OpenGL calls .. thus having it as a event node doesn't make sense in that way either ( since the only component you'll use it with is ZExpression ).Rado1 wrote:In addition there's explicit application event when the OpenGL surface is created and the content of this special section is called. I see special section as more transparent solution.
K