Home » Discussion forums » OpenTK » Development
Kosta's picture

Bug report: several OpenGL 2.1 interface bugs [resolved]

Posted Thursday, 10 July, 2008 - 14:18 by Kosta in

The following interfaces are incompatible with respect to the OpenGL spec 2.1 from OpenGL.org: http://www.opengl.org/registry/doc/glspec21.20061201.pdf

enum BlendingFactorSrc: (see Table 4.2, page 211)

  • missing: SRC_COLOR
  • missing: ONE_MINUS_SRC_COLOR

enum BlendingFactorDest: (see Table 4.2, page 211)

  • missing: DEST_COLOR
  • missing: ONE_MINUS_DEST_COLOR

function StencilFuncSeparate: (see chapter 4.1.5, page 205)

  • the OpenGL prototype is: glStencilFuncSeparate(GLenum face, GLenum func, int, uint)
  • the OpenTK prototype is: StencilFuncSeparate(StencilFunction, StencilFunction, int, uint)
  • in OpenTK the first parameter must be changed from "StencilFunction" to "All" in order ot allow "All.Front" or "All.Back" or "All.FrontAndBack" as first arguments...

Could someone please fix these bugs?

Thanks,
Kosta

‹ Scope of OpenTK.Math GLControl does not redraw in Visual Studio [resolved] ›

Comments

Comment viewing options

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

Re: Bug report: several OpenGL 2.1 interface bugs

Posted Thursday, 10 July, 2008 - 14:49 by the Fiddler

Thanks. Regarding StencilFuncSeparate, there is an error in the specs, where both parameters are specified as StencilFunction:

StencilFuncSeparate(frontfunc, backfunc, ref, mask)
	return		void
	param		frontfunc	StencilFunction in value
	param		backfunc	StencilFunction in value
	param		ref		ClampedStencilValue in value
	param		mask		MaskedStencilValue in value
	category	VERSION_2_0
        [...]

This looks like an earlier revision of the function (the parameters are different in the manpages/pdf compared to the specs).

Working on the rest.

Edit: Ok, commited the fixes to SVN. It's unfortunate that there are bugs/inconsistencies in the OpenGL specs - hopefully GL3 will be better in this regard. Do mention any other problems you happen along!

Kosta's picture

Re: Bug report: several OpenGL 2.1 interface bugs [resolved]

Posted Thursday, 10 July, 2008 - 15:34 by Kosta

see also this OpenGL.org forum post: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Numb...

Kosta's picture

Re: Bug report: several OpenGL 2.1 interface bugs [resolved]

Posted Thursday, 10 July, 2008 - 16:01 by Kosta

Thanks for your quick fixes!

One minor note: you could also use the new enum "StencilFace" in StencilOpSeparate as first paramater... :-)

Kosta's picture

Re: Bug report: several OpenGL 2.1 interface bugs [resolved]

Posted Thursday, 10 July, 2008 - 16:08 by Kosta

And another note:

You distinguish between "DepthFunction" and "StencilFunction", but both enums contain the same values. Would be possible to unify them by using "ComparisonFunction" instead...

the Fiddler's picture

Re: Bug report: several OpenGL 2.1 interface bugs [resolved]

Posted Thursday, 10 July, 2008 - 18:52 by the Fiddler

Thanks for the forum post :-)

There are many more enums that have the exact same tokens, e.g. DrawBufferMode, ColorMaterialFace etc etc. From a practical and usability standpoint, these cannot (and should not) be combined.

Practical: The master .spec files (written by ARB/Khronos) contain contain several thousand tokens. While we have edited the .specs extensively to fix bugs (like this) and improve clarity (examples), it's just not feasible to update all 1.5K functions, merge enums etc etc.

Usability: "DepthFunction", "StencilFunction" and "DrawBufferMode" may share tokens, but they are sufficiently different to warrant different enums. In any case, any IDE worth its salt should be able to suggest the correct enum, so having different types is not a real hindrance.

Now, if Khronos dedicated resources to cleaning up the specs, things would be in a better state right now. Unfortunately, these problems do not show up in the C-API (where everything is an int) and with all resources dedicated to GL3, the specs are unlikely to change. I've tried reporting bugs in opengl.org, sending PMs to the maintainers and logging bugs on the Khronos bug-tracker, all to no avail... Let's hope GL3 will be better in this regard.