Inertia's picture

Wishlist

For the mentioned upcoming release, here are minor issues I came around. Nothing serious, and too small issues to create a new topic for them alone.

1) The enum GetTextureParameter doesn't contain GL_TEXTURE_COMPRESSED.

2) Glu.ErrorString expects different type as parameter, than what is returned by GL.GetError(); Unnecessary cast? Don't see any other use for these commands.

3) KeyboardDevice.cs
public bool KeyRepeat
Documentation unclear about "on", true/false might be better.

4) GL.Color could use a Vector overload, colors can be nicely stored in Vector3/4. The function was also behaving a bit weird always expecting (int) for fixed-point types. E.g. (byte)255 for RGB would result in black as it got cast to int32. Anything but byte/float is not really useful?

5) GL.Material could aswell use a Vector4 overload. I understand why this is difficult for all functions where modes can expect different types for their own parameters, but I think this is a special case where this would make sense. How about adding GL.Materialv4, which can be used for convenience with a Vector4 for specifying colors (ambient/diffuse/specular/emissive), where shininess can still be set through default GL.Material().
This is just something to consider, the current implementation is fine.

Ironically 3) was the point where I decided that it'd be quicker to implement that "keystroke manager" in a few minutes than going through documentation. All I wanted was Glut-like handling for a handful of toggles and getting other functions further, no offense/critique against your design - just a subjective decision for that small project.


Comments

Comment viewing options

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

I'm all for that. If you wish to contribute some code for the (as-of-yet inexistent) OpenTK.Utilities.dll just send me an email (com.gmail@stapostol) :)

Inertia's picture

You'll get mail from @web.de

[OpenTK.Utilities.dll]
May I suggest to place the Utilities in a more logic namespace like OpenTK.OpenGL.Util, OpenTK.OpenAL.Util etc? Basically the helpers are like a custom Glu, or not?

The separation would make sense in the long run, e.g. I doubt you will provide any .ogg file loaders with OpenTK and I will definitely write one when OpenAL is included.

the Fiddler.'s picture

OpenTK.Utilities.dll will contain several namespaces. Besides, that's a working name, the real one is still undecided. I'd probably prefer one such dll instead of having a separate one for each category.

(this site will be going down at any moment now, so don't reply right now :) )

Inertia's picture

nice update :D has nothing in common with what you showed though. The purple is a bit bright, or is it my screen? I like the drop-down menus better now, much better visible with the new layout. I'll rather write a page in the book about composition than go into detail now, but using a cooler color like #323264 will give the image more weighting and contrast (might need some adjustment, but try it out please).

Regarding the .dll name I don't care, just wanted to make sure there's not 1 big pool for all utils.
This is similar to the All-enum, how will this be done with OpenAL?

the Fiddler's picture

Hm, this reminded me to check my monitor's color profile, and sure enough I was using the wrong one (I have several ones, darker ones for coding, gamma corrected ones for graphics, etc.) It didn't help that I developed the last bits on a foreign LCD monitor, either :)

Regarding OpenAL, I haven't really delved into that yet. I don't think there are specs in the OpenGL form, but rather plain C headers. On the other hand, it is possible to write the OpenAL bindings by hand (it isn't too large), so we can get the API to look however we like (no All enum etc).

Inertia's picture

[Color]
The way I see it there's a variable for the theme's background color somewhere, should be easy.

[OpenAL]
Indeed, OpenAL 1.1 itself is quite small and very similar to GL, what will probably bloat it are the X-Ram and EFX Extensions.

Let's fix the VersionXX enums first though, I'll post a list this week (will keep editing until all VersionXX are obsolete) containing changes. I really think DX9 level hardware isn't too much to ask, which is similar hardware level as GL 2.1

Edit: This is also why Extensions like S3TC and VBO should be integrated: Microsoft made them standard with DX. What vendor builds graphic cards that don't support DirectX 9 since 2003?

I also think this is the reason why the SGI isn't really necessary and could be dropped, Sgi didn't build any Desktop graphic cards in the past 5 years, and their "legacy" is just not supported.
Are you planning to port OpenTK to Sgi's Iris at some stage? Or does Sgi provide drivers for Linux? Really don't know, my point is that Desktop PCs are 100% of what is targeted by you and your user group.

Edit2: Thanks for changing the color, maybe let Kostas take a look at the color itself again (I just made up that RGB :p), he will probably want to darken the original color used?

Imho the Logo is much better visible now tho, it stings out and is a point of focus.

the Fiddler's picture

Sounds nice.

Edit: I'll be revisiting the colors, in the future. Asking Kostas would be a good idea, too.

About SGI, do they even make hardware anymore? They've even stopped updating Performer, I'm not sure what they are doing as a company. Dropping duplicate enum members wouldn't hurt compatibility (and from a quick glance, most seem duplicate), so removing these wouldn't cause problems. I don't plan to port OpenTK to Iris any time soon, but as long as the SGI stuff doesn't cause problems, I'm happy to leave it be (for the remote chance that someone is interested in that).

Inertia's picture

[SGI]
The last thing i've read about Sgi was that they're selling real estate to avoid bankruptcy (could be a rumor).

I'm not suggesting to remove all Sgi Extensions, only the ones that have been promoted to EXT/ARB/Core (e.g. the TextureMaxLevel constant I quoted earlier in this topic).

Maybe it'll be best to // comment them out, rather than deleting. It would be nice if someone who actually uses Sgi Extensions voices his opinion here, to get a better idea what exactly has to be preserved.