Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Android crash from precision qualifiers in GLSLCompat.glsllib #2381

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yaRnMcDonuts
Copy link
Member

Addresses this issue: #2329 (comment)

Feedback and review is appreciated, as I only just delved into learning about these precision qualifiers and I also don't do any jme dev on android to test this myself.

Addresses this issue: #2329 (comment)

Feedback and review is appreciated, as I only just delved into learning about these precision qualifiers and I also don't do any jme dev on android to test this myself.
@pavly-gerges
Copy link
Contributor

Thanks for working on it, I am willing to take the initiative to test this. However, first I want to understand what the issue was (Because I am not very familiar with GLSL). It seems to me to be a compilation issue due to using semi-colons? But that was not addressed in this PR?

@yaRnMcDonuts
Copy link
Member Author

yaRnMcDonuts commented Feb 25, 2025

It seems to me to be a compilation issue due to using semi-colons?

I thought so too at first glance, however semicolons are perfectly fine in that context in shaders.

The only time semicolons shouldn't be used in shader code is on lines that are setting defines or in pre-processor context (for example, things like #ifdef checks or jme's custom #for preprocessor that don't have semicolons at the end of the line. any line starting with a # typically doesn't end in a semiciolon). Aside from that, standard shader code in fragment and vertex shaders should always have lines ending with a semicolon.

But shader errors/exceptions can be particularly bad at pointing directly to the issue in some cases. It isn't uncommon for shader errors to throw a seemingly nonsensical error where the only useful information is the line number (similar to how java error reporting can be nonsense and underline your whole class in red if you try running an app with something like mis matched brackets. But shader compilers are much more sensitive and much less forgiving than java)

So in this case, the comment from @nickidebruyn (where he said that the error went away when he deleted those new lines of code that set precision for each shader variable type) made me guess that the issue was likely the usage of highp. Then I googled if thats supported on android, and thats when I found out that setting precision on non-numerical types (such as sampler2d, sampler2darray, etc etc... pretty much anything but float and int) can cause crashes on android, and it is essentially useless on desktop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants