Comments (12)
We should probably solve glsl versions first. Probably most intuitive would be to:
- Create a structure of environment files, sorted by glsl version and purpose (vertex/fragment/...)
- Check all files by default, unless
#version
directive is present. If it is, check all as well, but warn when using features unavailable in current version.
Using this philosophy, extensions could be handled as well.
However, this will create a lot of redundancy, because most of the functions stay the same between versions. Alternatives would be:
- Have only delta changes in all but first version
- Annotate (somehow) all functions/variables with their relation to glsl versions
Question also is, how to recognize and account for GLES shaders in this system.
from glsl4idea.
I've added more files to this in the environment
branch. I think once we have better preprocessing it makes more sense to just use one file with preprocessor directives to handle this. Alternatively, if we supported annotations (eg. GCC-like __attribute__((version(410))
or via #pragma somethingorother
) that'd then give an easy way of specifying them all in one file and having information about the functions not in the current version.
GLES SL versions are 100
, 300
and 310
, which conveniently have never been used for GLSL versions (which started at 110
and skipped from 150
to 330
). This may not always be the case, but Khronos will have to think about it as much as we will. Of course, this does mean that you can't assume that the version numbers form a single monotonic line, as I have done in the environment
branch.
from glsl4idea.
(See #40 which is a prerequisite for this.)
from glsl4idea.
I'd like to keep the ability to recognise the function even if doesn't exist in the current version, but I think that the preprocessor support would have to be very advanced to be able to do that reliably. I don't know, maybe it will be easier then it seems, but so far I'm in favor of annotating somehow. Since these annotations will be supported only in environment files, we can make up our own syntax that is readable and comfortable.
Making the tag up isn't trivial though, but if we assume that GLES versions will be always different to GL versions, something like <110,120,300> float cos(float x);
(for denoting that cos is available in GL 110, 120 and GLES 300 (only those versions)) might be enough. Something like <versions>{ function1; function2; ...}
might help with resulting verbosity and still be easy to parse. (Maybe even easier)
from glsl4idea.
C++11 attributes ([[version(110, 300)]]
) might be nice - they look clean and minimal like your angle-bracket suggestion, but are also supported as standard in other languages (ie. C++11) so there's some precedence for it. Double opening square brackets aren't currently valid anywhere in the language, but you can make something that's syntactically well-formed with something like 100<110,120,300>330
.
Supporting attributes for things other than versions would be hypothetically useful for adding other annotations to the standard library - possibly something like [[minimum(8)]]
for the implementation-defined limits that are defined in the shader environment?
from glsl4idea.
It can also be used for error highlighting based on expression analysis, as well as feeding more info back into the analysis:
float [[contract(x >= 0 && sqrt(x) >= 0)]] sqrt(float x);
from glsl4idea.
First, very nice plugin!
Does this issue include the missing deduction of return values for build-in functions, or should I create a new one?
For example:
float unpackFloat(vec4 v) {
return dot(v, vec4(1.0, 1.0 / 255.0, 1.0 / 65025.0, 1.0 / 160581375.0));
}
It is able to deduce the types of the arguments to dot
but unable to deduce it's return type and shows a warning.
from glsl4idea.
@Fox32 Thanks!
It does, support for methods here means that the plugin will know which methods there are, what arguments do they take and what type they return.
More thoughts on the issue:
What if the importing wasn't done by annotated source file, but through something directly in Java? There could be an object which would allow specifying and searching for methods/etc., let's call it FunctionRepository
which would allow doing something like this:
class GLSLFunctionRepository extends FunctionRepository {
//function(name, returnType, argTypes...);
function("sin", GEN_TYPE, GEN_TYPE);
function("cos", GEN_TYPE, GEN_TYPE);
function("doMagic", FLOAT, GEN_TYPE, GEN_TYPE).since(130).sinceES(150);
...
}
FunctionRepository fr;
FunctionType ft = fr.findFunction("doMagic", VEC2, VEC2);
ft.returnType == FLOAT
Similar "Repository" for variables and types or it could be integrated into one.
I am seriously considering this, because it will be less work, faster, more flexible, predictable, and we will have tools to deal with it (refactoring java is easier than glsl with custom annotations).
from glsl4idea.
Having had a further look at how function lookups and parameter info is handled, I suspect building the function list in Java would be easier. (Specifically, a ResolveResult
can be either a PsiElementResolveResult
or a custom implementation that can be used to resolve to built-in functions.)
from glsl4idea.
In my game engine I support importing shaders using #pragma import filename
. I've been thinking of a way to allow plugin user to specify what kind of syntax their imports use and then add support for file imports to glsl4idea. Haven't had any good ideas about that yet but the same concept could be used for built in functions.
The built-in functions are conveniently stored in files as is, so if built-in function loading was implemented by implicitly (without explicit annotations or directives) importing the resource files, it would solve a few problems:
- User shader code would directly benefit from changes to built-in function documentation parsing code and vice versa (code to fetch documentation for function would only have to be implemented once!)
- If the user shader glsl file specifies glsl version with
#version
and the builtin functions are loaded after this, only the correct functions would remain without any additional processing needed (this needs #40) - It would be trivial to implement custom shader import directives later
While Java function repository idea would definitely be faster, I think it would also be less flexible. I will maybe look more into the idea later.
Also sorry about messy text flow, it's late.
from glsl4idea.
Hello. Thanks for plugin. What is the status of the issue now? When can we expect this enhancement to be implemented?
from glsl4idea.
I don't currently have much time to work on my OSS, so don't expect this to be done anytime soon.
from glsl4idea.
Related Issues (20)
- Code Scheme Darcula (CLion like) HOT 2
- How to turn off error checking? HOT 3
- Error in CLion IntelliJ and basically all IDEs HOT 1
- NoSuchFieldError: LINE_COMMENT_ADD_SPACE HOT 4
- Preprocessor concat operator
- Scalar constructor does not accept non-scalars
- CLion hangs when editing glsl file HOT 2
- No support for GL_EXT_shader_explicit_arithmetic_types causing errors on primitive type conversions and functions HOT 1
- min/max not recognized for i64/u64 HOT 1
- Error when attempting to assign result of texture() call to uint when sampler is a usampler2D HOT 1
- com.intellij.diagnostic.PluginException: Element: class glslplugin.lang.parser.GLSLFile #GLSL because: different providers HOT 1
- Error when using Kotlin String variables inside the GLSL String
- Support for GL_EXT_ray_tracing HOT 1
- Incorrect typechecking when preprocessors are used HOT 1
- "left PSI inconsistent" exception thrown when typing ";"
- Support SKSL
- Support for GL_NV_shader_buffer_load
- Unable to correctly trigger highlighted code block in layout uniform variables. HOT 1
- Unable to correctly trigger highlighted code block in layout uniform variables. HOT 1
- Exception in IJ 241: need to specify ActionUpdateThread for actions
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from glsl4idea.