Bug: PVRUniSCoEditor gives false GLSL error

This topic contains 6 replies, has 2 voices, and was last updated by  Arron 6 years ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #30614

    Hi. I’m using PVRUniSCoEditor v1.5 (SDK build 2.08.28.0607)
    with the following GLSL ES Compiler: OGLESWindows_x86_32PVRUniSCo_SGX53x.exe

    My apologies if this has been brought up before but

    the compiler incorrectly gives the following error message with the following code samples:

    ‘”‘ is an invalid character in GLSL.

    I also get the same error when running my PC GLES program using the PVR provided GLES libraries.

    Sample 1:
    #if 0
    #include “file.h”
    #endif

    Sample 2:
    #ifndef GL_ES
    #include “file.h”
    #endif

    The same code compiles successfully on iOS.

    Could a fix be included for the next SDK release?
    In the meantime, is there a workaround, quickfix, etc that I can use?
    Thanks in advance.

    #35075

    Arron
    Member

    Hi.

    Apologies for the time taken to reply. I can verify the issue you’re having and I’ve logged the bug in our tracker system with ID BRN34644.

    Thanks.

    #35076

    Thanks for the follow up Arron! 
    Out of curiosity, is the bug tracker database publicly viewable? I couldn’t find a link to it on Imagination Technologies’ site.

    #35077

    Arron
    Member

    Unfortunately not: the tracker system is internal. I posted the BRN number so that you can use it for reference against future SDK releases as we post a list of fixed BRNs.

    Best regards.Arron2011-10-13 10:58:00

    #35078

    Arron
    Member

    Hi.

    I’ve just received an update regarding this issue.

    The GLSL specification states that quotation marks are invalid characters outside of comment blocks even inside pre-processor blocks that will not be processed. This is detailed in section 3.1 here: http://www.opengl.org/registry/doc/GLSLangSpec.4.20.8.clean.pdf

    Moreover, the #include directive you are using in your preprocessor block is also not part of the specification (hence why the quotation marks is not supported). This is detailed in section 3.3.

    The above specification also applies to GLSL:ES.

    Best regards.Arron2011-10-19 12:42:32

    #35079

    Hi Arron.  Thanks for posting the update!
    I’m not expert but there are a few observations I’d like to share.

    1. There happens to be a separate specification for ES version of GLSL which can be found here:
    http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf
    If that link ever breaks in the future, a link to the latest version of the GLSL ES specification should be found on this webpage http://www.khronos.org/registry/gles/

    2. If you look at the appropriate section for “Prepocessor” commands in the GLSL ES document that I linked to (3.4) and GLSL document that you linked to (3.3), they both more or less say that “#if, #ifdef, #ifndef, #else, #elif, and #endif are defined to operate as (is standard) for C++”  (The exclusions that the GLSL ES doc then goes on to mention don’t seem relevant for this conversation.)

    In C++ I can write the following code in one of my files and still compile it successfully.
    #if 0
    4this is not valid code
    #include
    #endif

    I assume this works because before the compiler runs and checks what characters are valid against the “Character Set” section of the specification, and before other preprocessor commands are evaluated, the #if and related preprocesser commands have been evaluated and any characters inbetween #if 0 and #endif have been removed.  Thus the compiler never even knows they were there.  Hopefully that made sense and you can still see the validity of my original bug report.

    Thanks again for taking the time to share an update!
    WhatsInAName2011-10-19 13:35:33

    #35080

    Arron
    Member

    1. Sorry, I didn’t mean to imply that the GLSL spec is also the GLSL:ES spec. I just linked to the GLSL spec as it’s slightly more verbose the relevant sections.

    2. Indeed I can see the validity of your original report (hence why I filed it against our compiler), alas the preprocessor checks for valid characters just as the compiler does – hence why your examples don’t compile.

    As a workaround you could easily strip out the offending line/characters before passing it to GL – simple pre-processors are easy to write :).

    Best regards/

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.