george's picture

function overloads

Hello, there seem to be some issues on this forum with posts being lost. Mine just seems to have vanished.
I'll try to sumerise:

I was looking into adding some overloads for some of the gl and glu functions that would naturally take the OpenTK.Math.Vector classes as arguments. Assuming that GL.cs and Glu.cs are autogenerated, how does one go about this?

Also, having just browsed through Glu.cs, are all 64000 lines of overloaded functions strictly necessary? do you really need to cater for the case where someone wishes to call Glu.Project with the x coord given as a ref, the y coord as a pointer and the z coord as an array? 729 permutations of Glu.Project. That's quite a lot. If you wish to hang Visual Studio for a while (10 minutes on my machine) try typing "Glu.Unproject4(". Surely overloads where all arguments are pointers, or all are arrays etc, would suffice?

Right, now I must remember to copy this post to the clipboard before I click submit.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler.'s picture

I don't what's the matter with the site - the logs don't show anything abnormal, so I assume it has something to do with Sourceforge's servers getting overloaded. I'll move the site to a different host during November so this should get sorted out.

For the overloads: GL and Glu are partial classes, so you can write "public partial class GL { }" and add your functions wherever you want. I've been using the GL/GluHelper.cs files for this job (they reside in Source/OpenTK/OpenGL).

Regarding Glu, the situation is downright ridiculous right now - Glu's 80odd functions take more space than GL's 1528. Even then, 10 minutes is far from normal - I've only seen pauses up to 3-4 seconds which are annoying but manageable. If you are using Visual Studio, do you have the Service Pack for Visual Studio installed? It solves some issues like this.

The problem is that it's not *that* simple to solve (there are void pointers that must be treated differently (object/IntPtr overloads), special cases for some functions etc). I'll have to play with the generator to see what can be done.

george's picture

I'm using express 2005, don't know if the service pack applies to that or not. It might be a memory thing, I've only got 512M on this machine. Anyway, it's not a huge issue for me, luckily I don't actually need to call Glu.Unproject4.
I guess treating x,y,z args in the same manner (all pointers, all refs etc), and just permutating the other arguments would cut down on the number of overloads quite a lot.
Speaking for my own personal preference, I'd be quite happy if any function that takes x,y or x,y,z coords had only one overload which was to use the Vector classes. If you sometimes have to call it like so:
GL.SomeFunction(new Vector3(x,y,z));
then that's fine with me, these generally aren't functions one should be calling many times a frame. I guess that's a slightly separate issue though.

Right, I'll set to adding some vector versions of gluLookat and things. If all goes well I'll send you a patch.

the Fiddler.'s picture

Nice, thanks!

george's picture

Right, initial patch is ready, how would you like it delivered?

george's picture

Right, initial patch is ready, how would you like it delivered?

the Fiddler.'s picture

Please email it to stapostol at gmail com.

I've modified the generator to cut down on the generated permutations, and Glu.cs now weights at only 43KB. I'm thinking whether this is a good idea for GL.cs, since the savings aren't quite so impressive there (from 2.5MB down 1.6MB), and it can be useful sometimes to have all the permutations available. What do you think?

george's picture

I agree the permutations can sometimes be useful, but there's a lot to be said for simplicity in my opinion. Also, some of the functions are so rarely (if ever) used, that it's not really helping anyone (anybody used glColor4ubVertex2fvSUN recently?). Still if they're just sitting inside GL.cs not hurting anyone then there's no real problem including them I guess.

Inertia's picture

Maybe let the generator split it into multiple files, so it would output 1 partial class file that only accepts IntPtr parameter, another file with object[] overloads, one file with overloads for Vector3 etc.
The user could then exlude what isn't required and build the library as desired.

Tbh the function overloads produced by the generator aren't that much of a headache for me since Intellisense lets you navigate through them rather easy and I like having the choice not to pin every single object manually. What annoys me is the amount of tokens and that every token has a _EXT and _ARB mutation, worst is that you cannot simply assume that _ARB is the latest and reliable. (e.g. my PC cannot create a PBO with the ARB functions/tokens, but it works fine with _EXT. Using rather new drivers, but Geforce FX 5600) I'm really looking forward to OpenGL 3.0, that should clean up most of those legacy problems.

Edit: Sorry for going a little offtopic, just intended to write down my perspective of what is confusing when working with OpenGL.

the Fiddler.'s picture

Yeah, this is one of the most important reasons why we need OpenGL 3.0 (and working drivers). Problem is, it's been more than a month late (release was to happen during September at first), and noone really knows what is going on.

On the multiple files issue, I don't think this fits with the current build system. The user would have to physically delete the files from disk in order to make a custom build (ok, maybe the generator could emit #if/#endif directives for conditional compilation, but it doesn't seem to be worth the effort). Right now, you can control the generator with commandline options (not documented yet, but flexible enough to support both the Tao and the OpenTK bindings), for example, you can set a custom output namespace/class or control the use of unsafe code etc. It still needs a compile->generate bindings->compile cycle, but it's better than nothing and it works.

With this in mind, I've decided to leave the simplified overloads as the default. It is extremely unlikely that existing code will be broken (since they mostly affect functions of the glColor4ubVertex2fvSUN caliber), and even if it is you can always change to the ref overloads (passing "ref array[0]" behaves exactly the same as passing "array" directly) or regenerate the old bindings by running the generator with the -legacy:overloads switch. As an added benefit, compilation times are now 10x faster (on Mono) and the OpenTK.dll is 1MB smaller.