Aeroglass features

[DrakkLord]

Hi @DiegoGomezDeck !

We decided to not make pull requests on the aeroglass branch, instead we will make pull requests from individual feature branches, so here is branch with out current feature changes.

---

• fixed an invalid character in the iOS C++ source which causes a compile error with the generated java code in Android Studio under Windows 10
• added Android Studio and Gradle specific things to .gitignore
• added a feature to turn off FPS reduction for the android widget because we do the FPS reduction in our own code
• reverted test commits made only to test the java converter
• added a feature for android specific code to allow storing large files within the downlaod cache by saving them next to the database file, this is due to a problem coming from android's SQLite which crashes around 1-2Mb of blob size, this is a workaround by storing a the file name reference instead and saving the file externally
• added a new GL feature which allows using custom opengl shader names and allows setting uniforms and attributes from that feature, also added code that makes sure that G3M does not try to set unrecognized attributes and/or uniforms
• added feature to distinguish between shaders loaded by name and uniform / attribute keys

---

[DiegoGomezDeck]

Hi @DrakkLord

This PR is a bit too big. There features that we think can be merged, but mixed with other changes we need to discuss before merging.

Specifically I don't think I like the changes on the shaders mechanism, specially the GPUAttributeKey.UNRECOGNIZED_ATTRIBUTE and related stuff.

One of the goals in the shaders subsystem is that the attributes/uniforms have to much 1to1 between the C++ code and the shaders, it means: there must be NO unrecognized things at all.

Also I'd like to hear what @amazingsmash think about this.

[DrakkLord]

Hi @DiegoGomezDeck

The shader system is made like this to avoid what you described as making custom shaders requires changing G3M source code which one might not want to do.
For example if I would like to just use G3M and not modify its source then I cannot use custom graphics via shaders only the ones built in.
With this modification G3M allows the custom stuff by adding your own shader source into the widget builder and using it from your own GL feature and by doing this you are responsible handling the shader attributes / uniforms that G3M flags as UNRECOGNIZED.

Sorry about the big PR this happened on our end we won't make such big PR's in the future.

[amazingsmash]

In general, I agree with @DiegoGomezDeck . The system should allow you to select any specific shader based on a unique set of entries. One of the main purposes of the whole shader mechanism is to ensure the consistency between the shader used and the provided information. Taking a look at the PR the GPUAttributeKey.UNRECOGNIZED_ATTRIBUTE seems to break that feature.

On the other hand, I agree with @DrakkLord that the system, at this moment, does not allow new shaders to be used. IG3MBuilder lacks a method to include new shaders, and the new variables of those shaders should be recognized properly via GPUVariable.

[DrakkLord]

Thanks for your input @amazingsmash, we've seen this was the goal of the GPUKeying however this creates a closed system where you must make new keys and most importantly you have to modify the shader selection because they are based on keys so for example if I want to do two different visual styles that use the same keys I can't do that because based on keys one shader would override the other same goes for completely new shaders.

However I agree that this could be done better, the main focus with this feature was to make G3M allow us to use shaders more flexibly so essentially if you introduce a new mechanism to handle say "unknown attribute for G3M" you would do the same as it is right now since G3M does nothing with unrecognized variables, and like I mentioned on top of this, the shader selection is hard-wired which disallows making any custom visuals.

@DiegoGomezDeck seeing that the focus is on the custom shader feature, should we extract this feature move it to another branch and discuss how it can be implemented and then remaining things in this branch can be merged?

[DiegoGomezDeck]

Hi @DrakkLord

Let's split this PR into different branches. The features not related to the shaders mechanism looks good to me, and I think we can merge them soon.

Related to the other important part, let cal lit "custom shaders"... let's open an issue/PR and move the discussion there.

We agree with you we need a way to add custom-shaders, let's find out the way.