2byte character may causes a bug with GL.ShaderSource .

OK .
I attached a program which is based on HelloGL3.cs .
This has "vertexShaderSource" which includes 2byte character at line 3 .

....
        string vertexShaderSource = @"
#version 130
 
precision highp float;//2バイト文字 2byte Character
 
uniform mat4 projection_matrix;
uniform mat4 modelview_matrix;
 
in vec3 in_position;
in vec3 in_normal;
....

Unfortunately, the only solution as far as I can see is to replace the .Net string marshaling code with our own. ShaderSource takes an array of strings and the framework doesn't allow us to alter the marshaling behavior in this case (it always treats them as an array of LPStr, that is "A pointer to a null-terminated array of ANSI characters.")

The manual marshaling solution would look like this:

• change signatures of all string-receiving methods to byte*
• provide string and string[] overloads that match the current signatures
• use System.Text.Encoding inside those overloads to convert the strings into byte arrays with the correct encoding

This is too complex a change to implement inside the 1.0 timeframe but it can be implemented in time for 1.1. As a temporary workaround, you can use this code to remove multibyte characters from shaders:

        /// <summary>
        /// Converts the specified string to ASCII. Characters that cannot be represented in ASCII
        /// are converted to '?'.
        /// </summary>
        /// <param name="s">The string to convert.</param>
        /// <returns>A new string instance, containing only ASCII characters.</returns>
        public static string ConvertToAscii(string s)
        {
            return new string(Encoding.ASCII.GetChars(Encoding.ASCII.GetBytes(s)));
        }

This is a destructive change because you cannot get the original string back from the converted one. However, it allows you to use multibyte characters in comments - but not as variable names!

Edit: fixed html tags.

Even if you replaced the marshaling code you'd still hit this issue as the OpenGL string format isn't defined to support other languages, just ANSI GLchar* to a null-terminated string.

I've seen some issues in older nVidia drivers with the newline characters being required to be the platform's newline characters and if it
wasn't you'd get some strange tokenization errors.

As a rule, all OpenGL input should be in the servers' preferred format.

So on x86 Windows it's little endian (LE), ANSI null terminated (cstr) with CR+LF (U+000D, U+000A) for newlines
On x86 Linux its LE, cstr, CR
On x86 Mac it's LE, cstr, CR
On PPC Mac it's BE, cstr, CR