Boder's picture

Awesome, I'm running not walking

I was worried for no reason.

I got the SVN for the new FBO stuff, got confused with nant and realized I didn't need it for "build vs." Compiling was easy.

Started with my new project codenamed "Quick Start" (I expect many have the same codename). I had to change some things, but was simple with C# intellisense. I still hope for an updated Quick Start. Pseudo fullscreen works nicely and is the default (cool).

The only thing is the mouse cursor stays on the "loading" icon until I move it off the client area (very minor).

Now I'm on to figure out FBOs and GLSL, which I never got under C++, but should be easier now.


Comments

Comment viewing options

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

Sorry, misread.

This doesn't protect you from:

GL.TexParameteri(TextureTarget.Texture2D, TextureParameterName.TextureMagFilter, TextureMinFilter.Linear);

You also don't need the 'i' (a plain overload would do). Which brings us back to the "too many overloads to write by hand" problem.

Update: just checked and you cannot use enums for generic constraints. Which means there's no easy solution to this problem.

By the way, the more I use generics in C#, the more I dislike them. The strange decisions in the constraint system weaken them too much (you cannot use System.Array, enums, or any primitive type as constraint).

objarni's picture

I thought the bulk of OpenTK was auto-generated..? Then such overloads would not be such a problem? Or is there some reason this has been avoided?

the Fiddler's picture

These overloads cannot be autogenerated, because the specs don't specify the allowed types.

For example, TexParameteri defines the last parameter as int, when in fact it could be TextureMinFilter, TextureMagFilter or many other things. There's no way to infer the latter from the former.

objarni's picture

OK, I see now ... The second parameter decides which "enum" should be used in the third.

Inherently bad situation ... not much to do, unless OpenTK steps further away from OpenGL with something like named methods for each second parameter:

GL.TexParameterMagFilter(TextureTarget.Texture2D, TextureMagFilter.Linear);
GL.TexParameterMinFilter(TextureTarget.Texture2D, TextureMinFilter.Linear);

etc.

Inertia's picture

Exactly, this is the price tag. I assume when this design would be executed consequently, we'd easily get above 5000 functions for the GL class - not to mention the requirement to document all those changes and the intellisense chaos.

Even if we do this with 2 instead of 3 parameters, there would still be the problem that you may pass a mipmap filter to a TextureTarget.TextureRectangle (which cannot have mipmaps). The only "safe" solution would be:
void TexParameterRectangleMinFilter( TextureRectangleMinFilter f );
Madness.

objarni's picture

If only C# were typeless, we would not have to worry about all this type-centric issues ;)

Irony aside - I guess the current API is a good balance!