Beta release 2.0.1b

[VilleK]

I wrote a tool to convert the OpenGL-header files to ZGE. It's called HeaderGen and is added to the Google Code repository. The GL-specification xml-file that is used by the tool can be downloaded here.

I've added the converted GL-headers to the ZGE beta. Since they became quite large (267kb) I wanted to avoid including all of that in every zgeproj-file. The solution I chose was to add a new property to ZExternalLibrary: DefinitionsFile. Set this to a file name and when ZGE is compiling your project it will look into the .\Lib folder for that file. If the DefinitionsFile property is set then the Source property is not used.

The Lib-folder comes with two definition files by default: opengl and Rado1's zgebullet library.

Note:
- The gl-definitions includes most GL 4.0 functions but I've skipped those that use double parameters (becase ZGE does not support them). If you see other functions missing or are converted incorrectly let me know.
- It is a noticeable delay when compiling projects that use the GL-lib. I'm guessing this is because of a bottleneck in the ZGE script compiler when it needs to parse the large definition file. I should be able to optimize that.
- I've added gl-headers and ZGEbullet to the Library menu so that is the easiest way to add the external library component to your projects.

http://www.zgameeditor.org/files/ZGameEditor_beta.zip

[Kjell]

Hej Ville,

Was expecting OpenGL functions that require extensions to not work ( they didn't before ), but noticed you slipped "if Result=nil then Result := Platform_GLLoadProc(P);" into "TZExternalLibrary.LoadFunction". Won't give you the best performance obviously ( compared to caching the function pointers ) .. but definitely better then not being able to call those functions at all

K

[VilleK]

The problem with all OpenGL functions that are newer than 1.4 or so require loading through the extension mechanism because the standard opengl32.dll that ships with Windows is outdated. On OSX and Linux these functions can be loaded directly just like other functions which is the way it should be.

The extra comparison won't hurt much performance because TExpExternalFuncCall cache the result of LoadFunction call. So it will only be the first call that executes a few nanoseconds slower

Btw Kjell, I've been trying to put together an example project that passes data from a DefineArray as extra vertex attributes to a vertex shader but haven't been successful so far. I'd appreciate some help with that if you have time. Basically I just want to add "in float mydata;" at the top of the Vertex shader but the GL-calls required to map this up correctly to an array of data seems to be tricky, at least that's my experience so far.

[Kjell]

Hej,

The extra comparison won't hurt much performance because TExpExternalFuncCall cache the result of LoadFunction call. So it will only be the first call that executes a few nanoseconds slower

Ah, never mind then .. didn't know you where already caching

Btw Kjell, I've been trying to put together an example project that passes data from a DefineArray as extra vertex attributes to a vertex shader but haven't been successful so far. I'd appreciate some help with that if you have time. Basically I just want to add "in float mydata;" at the top of the Vertex shader but the GL-calls required to map this up correctly to an array of data seems to be tricky, at least that's my experience so far.

Are you trying to use the fixed-function pipeline for this example? In case you are, most implementations only allow 16 attributes per vertex .. of which a couple are usually unused, but you can always sacrifice some of the 8 MultiTexCoord's.

By the way, it's not possible to do a example of this in ZGE at the moment. Since you need the shader handle you can't use a Shader component .. and glShaderSource takes a "const GLchar **Â string" argument, which isn't supported ( Cannot get address of expression ).

K

[VilleK]

glShaderSource is tricky because both the two last arguments are "ref" which means you need to send variables instead of literal values. This compiles ok:

Code: Select all

string s="hello";
int i=1;
glShaderSource(42,1,s,i);

And I can change it so that the Shader handle is visible. Which gl-call do you need it for? If it is related to the name of the attribute then maybe something can be added to the ShaderVariable component instead.

[Kjell]

Ah,

glShaderSource is tricky because both the two last arguments are "ref" which means you need to send variables instead of literal values.

Shouldn't have inline'd the arguments then The functions work now, but I can't get a simple shader to work .. can you check if I made any mistakes?

K

[VilleK]

Cool . It works here, I get a red sprite. Not sure why it doesn't work for you.

You don't need to append chr(0) because ZGE strings are zero-terminated already.

Check that the glCreate-call return non-zero values.

Running ZGE via gDEBugger will tell you details of any gl-errors.

[Kjell]

Only glLinkProgram fails ( 3 times, seems to be called internally when using glCompileShader ), but that's probably because both Shaders are completely empty and thus don't compile. This is the information gDEBugger gives me.

Reason: Detected Error
Occurred-in: glLinkProgram
Error-Code: AP_PROGRAM_LINK_FAILED_ERROR
Error-Description: Program 3 link failed

When I inspect either of the two shaders, the following is listed in the properties.

Source-Code-Length: 0
Is-Successfully-Compiled: No

K

[VilleK]

Apparently it is driver-dependent whether it is allowed to send zero as the last parameter. Try this instead:

Code: Select all

//

int sLength = 0;

//

string VertexSource = "void main(){gl_Position = ftransform();}";

VertexShader = glCreateShader(0x8B31);
sLength=length(VertexSource);
glShaderSource(VertexShader,1,VertexSource,sLength);
glCompileShader(VertexShader);

string FragmentSource = "void main(){gl_FragColor = vec4(1.0f, 0.0f, 0.0f, 0.0f);}";

FragmentShader = glCreateShader(0x8B30);
sLength=length(FragmentSource);
glShaderSource(FragmentShader,1,FragmentSource,sLength);
glCompileShader(FragmentShader);

//

ShaderProgram = glCreateProgram();

glAttachShader(ShaderProgram,VertexShader);
glAttachShader(ShaderProgram,FragmentShader);

glLinkProgram(ShaderProgram);
glUseProgram(ShaderProgram);

Notice I had to rename the local var from Length to sLength otherwise the variable would hide the length() function because names are not case-sensitive.

[Kjell]

Hej Ville,

Apparently it is driver-dependent whether it is allowed to send zero as the last parameter. Try this instead:

Hmm, I don't see any differences with my source ( apart from the variable name ). But you were right about the culprit .. the following works.

Code: Select all

int VertexLength = 40;
glShaderSource(VertexShader, 1, VertexSource, VertexLength);

int FragmentLength = 57;
glShaderSource(FragmentShader, 1, FragmentSource, FragmentLength);

Hopefully this was the only roadblock towards a attribute example

K

[Kjell]

Couldn't get it to work properly. Attributes appear to bind properly, but when querying for their location, OpenGL doesn't return the correct value. When i set the location manually ( which is a big no-no ), it does work in ZGE / as standalone .. but not in gDEBugger.

K

[VilleK]

Do you have an zgeproj file that demonstrates the weird behavior of querying attribute locations? It would save time for me trying to debug the problem.

[VilleK]

Is the technique of assuming an attribute location really not recommended? This forum thread suggests that GetAttribLocation might return -1 for shaders that are so simple that the glsl-compiler probably removes the name. Perhaps you could try a more advanced shader? You should be able to use a string type DefineConstant to hold the shader source so you don't have to remove all linefeeds manually (but copy to a local string variable from the constant before calling glShadeSource).

[Kjell]

Hej Ville,

Is the technique of assuming an attribute location really not recommended?

Well, I guess if you're a engine developer, you could choose to reserve attribute locations for specific features of your engine. But this also means that you don't open up space for other things when you're not using some of these features. In fact, if you take this route, there will only be 3 ( vec4 ) attribute locations free to start with ( assuming you don't want to conflict with any build-in OGL functionality )

What are you planning to use this for anyway? A general purpose extension of the Mesh format / component? If it's for shadow-map texture coordinates I'd just use glMultiTexCoord.

K

[VilleK]

Updated today:
- Rewrote symbol table to use faster collection types.
- Reduced size of GlobalNames by changing ownership of TZcOpArgumentVar (for compilation speed).
- Syntax completion show argument names.
- Updated internal MatrixMultiply function with optimization from Kjell.
- Updated strToInt script function to handle negative numbers.
- OnStart new property on AnimatorGroup component.
- Built using Delphi XE2 update 4

Btw, today is exactly five years since first 1.0 release

http://www.zgameeditor.org/files/ZGameEditor_beta.zip