chsc / gogl Goto Github PK

View Code? Open in Web Editor NEW

138.0 138.0 16.0 1.36 MB

OpenGL binding generator for Go

License: Other

Go 100.00%

gogl's People

Contributors

Stargazers

Watchers

Forkers

mobrulesgames rwesterteiger mewbak asig lloeki hazzen flyingliang tleyden ericls123 jasonrpowers sparkymat nathanielc influx6 freason go-graphics

gogl's Issues

OS X support

What is the current status of OS X support. Is it trivial to implement?
(I like the fact that gogl doesn't depend on GLEW, that is why I would like to try it out, but I need it to work on OS X)

Hmm, after browsing some source files I do see things that have to do with OS X. Maybe the comment in the readme that OS X support is TODO is outdated?

The gopher.go sample needs a depth buffer

The gopher sample needs a depth buffer, or else it renders incorrectly. The following patch fixes the problem by passing 16 as the value of OpenWindow's depth argument:

diff --git a/examples/gopher/gopher.go b/examples/gopher/gopher.go
index c28358b..e45be79 100644
--- a/examples/gopher/gopher.go
+++ b/examples/gopher/gopher.go
@@ -35,7 +35,7 @@ func main() {

    glfw.OpenWindowHint(glfw.WindowNoResize, 1)

-       if err := glfw.OpenWindow(Width, Height, 0, 0, 0, 0, 0, 0, glfw.Windowed); err != nil {
+       if err := glfw.OpenWindow(Width, Height, 0, 0, 0, 0, 16, 0, glfw.Windowed); err != nil {
            fmt.Fprintf(os.Stderr, "glfw: %s\n", err)
            return
    }

Missing glVertexAttrib variants?

The OpenGL reference appears to have functions that are not present in gl43. For example, glVertexAttrib1f().
https://www.opengl.org/sdk/docs/man4/xhtml/glVertexAttrib.xml

wgl.go does not compile

The generator attempts to generate a return when the function has no return type. For example the following code is generated for DeleteBufferRegionARB which has no return type.

func DeleteBufferRegionARB(hRegion Pointer) {
return ()(C.goglDeleteBufferRegionARB((C.HANDLE)(hRegion)))
}

Build error

It seem that you may need to update the OpenGL specification website:

>> make bindings
...
...
WARNING: Unable to parse line: '<script type="text/javascript">window.NREUM||(NREUM={});NREUM.info={"beacon":"beacon-4.newrelic.com","queueTime":0,"licenseKey":"a2cef8c3d3","agent":"js-agent.newrelic.com/nr-476.min.js","transactionName":"Z11RZxdWW0cEVkYLDV4XdUYLVEFdClsdAAtEWkZQDlJBGgRFQhFMVUpBXBdEG0IMUEURWFhZXVcJUkcAVQE=","userAttributes":"SxpaQDpWQEANUFwWC1NZR1YBFQ9SBFlBB04SUUBsBEdcFl9TUw4RVRQRRhZSR2sLVF8HQAoacl0KWUxZCkBBQB8=","applicationID":"1841284","errorBeacon":"bam.nr-data.net","applicationTime":56}</script></body>' (Ignoring)
WARNING: Unable to parse line: '</html>' (Ignoring)
Parsing [gl.tm wgl.tm] files ...
Unable to parse line: '<!DOCTYPE html>'
make install_bindings
#go install ./gl21
#go install ./gl31
#go install ./gl42
go install ./gl43
can't load package: package github.com/chsc/gogl/gl43: no buildable Go source files in /Users/ragnarok/GoWorkspace/src/github.com/chsc/gogl/gl43
make[1]: *** [install_bindings] Error 1
make: *** [bindings] Error 2

in the glspecs directory, the content of gl.tm is some html indicate that this page is not exist in Bitbucket

so please update the download url in download.go:

AlfonseSpecsBaseURL    = "https://bitbucket.org/alfonse/gl-xml-specs/raw/tip/glspecs"

this url currently is not exist in Bitbucket

Add OpenGL 4.4

Please add OpenGL 4.4 spec as this has now been released:

Documentation improvement suggestion for *Ubyte to string

I encountered a problem while using the the gl bindings. I used GetString and could not figure out how to properly make a string out of it.
http://stackoverflow.com/questions/21370390/read-a-c-type-string-from-go

The answerer on stackoverflow provided this solution:

gl.GoStringUb( gl.GetString(gl.RENDERER) )

I just didn't find the GoStringUb function in the documentation, you probably should put a hint in the doc for each function that returns a *Ubyte ( or just convert it to a go string in this function it that would make more sense to you)

Thank you for your consideration.

gl21.go missing constants

With the last commit the constants in gl21.go are missing (~ at line 3762).

gl.Clear() causes Access Violation (0xc0000005) in Windows 64

Take a look at this super-simple small test-case OpenGL program written in Go:

package main

import (
    "runtime"
    "./glfw"
    gl "github.com/chsc/gogl/gl21"
)

func onExit (err error) {
    glfw.Terminate()
    if err != nil { panic(err) }
}

func main () {
    runtime.LockOSThread()
    err := glfw.Init()
    if err != nil { panic(err) }
    err = glfw.OpenWindow(1280, 720, 0, 0, 0, 0, 0, 0, glfw.Windowed)
    if err != nil { onExit(err) }
    err = gl.Init()
    if err != nil || gl.GetError() != 0 { onExit(err) }
    for glfw.WindowParam(glfw.Opened) == 1 {
        gl.Viewport(0, 0, 1280, 720)
        gl.ClearColor(1, 0, 0, 1)
        gl.Clear(gl.COLOR_BUFFER_BIT) // THE CRASH
        gl.Begin(gl.TRIANGLES)
        gl.Color3f(1, 0, 0)
        gl.Vertex3f(-1, -1, 0)
        gl.Color3f(0, 1, 0)
        gl.Vertex3f(0, 1, 0)
        gl.Color3f(0, 0, 1)
        gl.Vertex3f(1, -1, 0)
        gl.End()
        glfw.SwapBuffers()
        if glfw.Key(glfw.KeyEsc) == 1 {
            glfw.CloseWindow()
        }
    }
    onExit(nil)
}

This builds fine under Windows 7 64-bit with Go 1.0.1 64-bit.

It also works fine (OpenGL draws a single rainbow-colored 2D triangle until the Windows is closed) if you take out (or comment-out) the gl.Clear(gl.COLOR_BUFFER_BIT) line.

As soon as gl.Clear is called however (no matter what arguments are passed), it crashes, Windows informs me that "glfw-win.exe has stopped working..." and the Windows Event Viewer has the following error log for me:

Faulting application name: glfw-win.exe, version: 0.0.0.0, time stamp: 0x4f9f5ec5
Faulting module name: glfw-win.exe, version: 0.0.0.0, time stamp: 0x4f9f5ec5
Exception code: 0xc0000005
Fault offset: 0x0000000000012883
Faulting process id: 0xd4c
Faulting application start time: 0x01cd274e4c69a3d3
Faulting application path: C:\mytmp\glfw-win\glfw-win.exe
Faulting module path: C:\mytmp\glfw-win\glfw-win.exe
Report Id: 8a5bacc0-9341-11e1-911a-d067e544ad7f

Now, a couple of noteworthy points...

The glfw package is simply a custom package exposing the exact same API as github.com/jteeuwen/glfw but internally using LoadLibrary/GetProcAddress for using glfw.dll rather than compile-time CGO/GCC/LD linking -- since the latter cannot be made to work in 64-bit Windows sadly, not sure whether mingw64 or gcc or cgo is to blame. With LoadLibrary/GetProcAddress calling my custom 64-bit build of glfw.dll is working mighty fine. Clearly the issue here is with a call to the gl package, not glfw.
The gl package is indeed simply this one, unmodified. I experimented with a few LDFLAGS modifications such as -m64 -lmingw32 -Wl,/windows/opengl32.dll etc. but no difference, the original works just as fine as the modified ones as long as gl.Clear() is not called, so I reverted back to the original. Of course later on I'll move on to OpenGL 4.2.
Using Process Explorer, I can see my process is 64-bit and all loaded DLLs are 64-bit images too (including opengl32.dll and glfw.dll).
"could it be that the gl21 package could not obtain a valid address for the glClear() function exported by opengl32.dll?" -- unlikely: according to line 2926, my call to gl.Init() would fail if this were the case.
GPU driver issues? Even more unlikely. The very newest official nVidia Quadro 5010M driver 296.35 is installed. Also tried the "performance driver" but seems to be exactly the same driver anyway. Full OpenGL 4.2 support according to nVidia Control Panel (although opengl32.dll is dated 2009 -- anyway, plenty for 2.1 I'm currently targeting). Plus, the OpenGL shaders in "Geeks3D GPU Caps Viewer" and "Shader Toy Mark" run, as does the GLFW example program particles.exe -- all of them use glClear() as well.
Exact same issue happens when using gl42 instead of gl21, so that's not the cause either.

Do note how all other gl.SomeExportedFunc() calls do NOT crash in this example and run as expected...

What to do, how to proceed?

I could live with this if this only happens with gl.Clear() and no other funcs ever -- I'm only ever rendering full-screen quads with custom content anyway -- but I'm fairly early in testing Win64 here (got a lot of gl42 code working just fine under Linux64, now about to "port" to Win64) and I fear that additional further calls later on will expose the same problem so I'm reporting this now. I will soon find out which other calls are affected by this.

gl.ShaderSource() throws "unexpected fault address" in Windows 64

Or am I doing it wrong? The following helper function of mine works fine with gl42 under Linux:

func glSetShaderSource (shader gl.Uint, source string) {
    var src = gl.GLStringArray(source)
    defer gl.GLStringArrayFree(src)
    gl.ShaderSource(shader, gl.Sizei(len(src)), &src[0], nil)
}

From previous threads here I understand that this is essentially the clean way to pass a Go string to the GLSL shader compiler, and indeed under Linux it works well.

Under Windows 64-bit, Go 1.0.1 64-bit, the last line (not the deferred GLStringArrayFree but the gl.ShaderSource call) crashes the program with the following console output:

unexpected fault address 0x100000001
throw: fault
[signal 0xc0000005 code=0x8 addr=0x100000001 pc=0x100000001]

goroutine 1 [syscall]:

goroutine 2 [syscall]:
created by runtime.main
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist269497170/go/src/pkg/runtime/proc.c:221

Happens for both gogl42 and gogl33.

how to create pointer for array in glBufferData

I notice that BufferData requires a pointer to the array. Can someone please list some examples of passing pointers to this. Thanks!

Cannot get this VBO example working

So I'm using Go GL and trying to get a simple VBO example to display but not having any luck. The equivalent code seems to be working in C. If anyone could help it would be greatly appreciated!

    // calls glortho2d , init etc glfw calls etc
w := Window.NewWindowedWindow("test", 800, 600)

w.Open()

    // simiply sets glclear with white color
w.Clear()

    // wraps glfw swap buffers
w.Refresh()

ID := make([]gl.Uint, 1)
data := make([]float32, 6)
data[0] = 50
data[1] = 50
data[2] = 100
data[3] = 50
data[4] = 74
data[5] = 100
gl.GenBuffers(1, &ID[0])
gl.BindBuffer(gl.ARRAY_BUFFER, ID[0])
gl.BufferData(gl.ARRAY_BUFFER, gl.Sizeiptr(4*len(data)), gl.Pointer(&data), gl.STATIC_DRAW)

gl.Clear(gl.COLOR_BUFFER_BIT)
gl.Color3f(0.0, 0.0, 0.0)
gl.BindBuffer(gl.ARRAY_BUFFER, ID[0])
// 4 is size of our float, but 2 objects each
gl.VertexPointer(2, gl.FLOAT, 2*4, gl.Offset(nil, 0))
gl.DrawArrays(gl.POLYGON, 0, 3)
gl.Flush()
w.Refresh()
time.Sleep(3 * 10e8)

I seem to get a white window with nothing on it. I do not get any errors.

deprecated mach-o/dyld functions

On Mac OS X 10.6.8 I'm seeing
cc1: warnings being treated as errors
gl21.go: In function 'goglGetProcAddress':
gl21.go:186: warning: 'NSIsSymbolNameDefined' is deprecated (declared at /usr/include/mach-o/dyld.h:176)
gl21.go:187: warning: 'NSLookupAndBindSymbol' is deprecated (declared at /usr/include/mach-o/dyld.h:179)
gl21.go:189: warning: 'NSAddressOfSymbol' is deprecated (declared at /usr/include/mach-o/dyld.h:188)

Replacing the Apple goglGetProcAddress implementation with
return dlsym(RTLD_DEFAULT, name);
(requires dlfcn.h instead of mach-o/dyld.h)

seems to fix it, but I have no idea if this is really correct! Maybe you should pass a handle from dlopen() instead of RTLD_DEFAULT.

With manual gen of alfonse tip on Intel HD 4000: "unable to initialize VERSION_1_2"

Now, as per the other thread/issue here today I re-gen'd gogl packages with the tip download of Alfonse. My machine has 2 GPUs I can toggle between with a physical button,a GeForce and an (integrated) Intel "HD 4000".

Previously GoGL had no such issues, but since I re-gen'd it manually today with the tip of alfonse specs, gl42 (still using that one) returns from Init() with "unable to initialize VERSION_1_2" (meaning it can do 1_0 and 1_1). Before I did so, it initialized all the way to 4_0 which is exactly the GL version implemented by the newest driver release for the HD 4000.

Just a heads up for you not to re-gen the gogl packages in this repo from the alfonse tip for now, as this seems to break what previously worked.

(The GeForce has no such issues, still initializes GL up to 4_2 with gl42 package. Still, I'd be reluctant to write this off as "oh well Intel GPUs are just buggy and sucky" when it worked so fine beforehand.)

Gonna nix my local manual re-gen'd gogl packages and revert to the current gl42 from this repo for now to get back to a working setup with the Intel HD...

[Update: Intel HD 4000 works again now after reverting to the current gl42 package from this repo.]

runtime.LockOSThread() is mandatory

If you don't call runtime.LockOSThread(), then the Go runtime will occasionally move your GL goroutine to a different thread. When that happens, you'll get a stream of GL_INVALID_OPERATION errors, because all GL calls have to be made from the same thread.

It would be really great to document this and include that call in all the examples.

can not compile example in windows and mingw!

Hi, I use MingW, and try use go and OpenGL.
I try the command but it reports Error!
I dont know the OpenGL binding can work on windows or not.
Thanks for help!

C:\MinGW\go\bin>go get github.com/chsc/gogl/examples/gopher

github.com/jteeuwen/glfw

callback.go:10: error: enumerator value for `__cgo_enum__0' not integer constant

callback.go:12: error: enumerator value for `__cgo_enum__1' not integer constant

callback.go:14: error: enumerator value for `__cgo_enum__2' not integer constant

callback.go:16: error: enumerator value for `__cgo_enum__3' not integer constant

callback.go:18: error: enumerator value for `__cgo_enum__4' not integer constant

callback.go:20: error: enumerator value for `__cgo_enum__5' not integer constant

callback.go:22: error: enumerator value for `__cgo_enum__6' not integer constant

callback.go:24: error: enumerator value for `__cgo_enum__7' not integer constant

callback.go:26: error: syntax error before "int"
callback.go:28: warning: initialization makes integer from pointer without a cas
t
callback.go:28: error: initializer element is not computable at load time
callback.go:28: error: (near initialization for __cgodebug_data[0]') callback.go:29: warning: initialization makes integer from pointer without a cas t callback.go:29: error: initializer element is not computable at load time callback.go:29: error: (near initialization for__cgodebug_data[1]')
callback.go:30: warning: initialization makes integer from pointer without a cas
t
callback.go:30: error: initializer element is not computable at load time
callback.go:30: error: (near initialization for __cgodebug_data[2]') callback.go:31: warning: initialization makes integer from pointer without a cas t callback.go:31: error: initializer element is not computable at load time callback.go:31: error: (near initialization for__cgodebug_data[3]')
callback.go:32: warning: initialization makes integer from pointer without a cas
t
callback.go:32: error: initializer element is not computable at load time
callback.go:32: error: (near initialization for __cgodebug_data[4]') callback.go:33: warning: initialization makes integer from pointer without a cas t callback.go:33: error: initializer element is not computable at load time callback.go:33: error: (near initialization for__cgodebug_data[5]')
callback.go:34: warning: initialization makes integer from pointer without a cas
t
callback.go:34: error: initializer element is not computable at load time
callback.go:34: error: (near initialization for __cgodebug_data[6]') callback.go:35: warning: initialization makes integer from pointer without a cas t callback.go:35: error: initializer element is not computable at load time callback.go:35: error: (near initialization for__cgodebug_data[7]')
callback.go:36: error: syntax error before "int"

How to create an offset with Pointer

Hello,

I have a buffer structure which contains vertex and texture coordinates.
Within C I could use glVertexAttribPointer(GLuint index, GLint size, GLenum type, GLboolean normalized, GLsizei stride, const GLvoid * pointer); and pass for example a 8 as a pointer.
With Go I can't do gl.Pointer(8).
func VertexAttribPointer(index Uint, size Int, type_ Enum, normalized Boolean, stride Sizei, pointer Pointer)

How do you set an byte offset with the pointer value?

What about gl43.DebugMessageCallback()? ;)

Just a curious case really for the sake of completeness. Don't really need it at this point (though at some point it might really come in handy)...

So there's this new function in GL 4.3 core profile http://www.opengl.org/sdk/docs/man/xhtml/glDebugMessageCallback.xml

When I hacked my own (XML-based) GoGL-rip-off "binding-generator for poor people", I conveniently and lazily skipped this above GL function because I had no idea of how to make it compile with the "callback" arg of type "GLDEBUGPROC"... got some CGO error when generating code for it. As far as I can see the spec-provided passthrough code has some #ifndef typedefs for it, but no less, compiler error.

Just checked out your own newest gl43 build and noticed this functions is missing at your end as well... same reason or are you missing out on some core-profile stuff that in the spec is nonetheless categorized as extensions?

(Really confuses me, this spec stuff: for example, glDebugBlaFoo() functions such as the one above have been added into core 4.3 but spec categorizes them under extension "KHR_debug" -- I don't really grok that "category" stuff fully, for example vertex array functions have been in core since 3.0 but are nonetheless categorized as some ARB_ extension...)

How would one write to the *gl.Pointer returned by glMapBuffer()?

Specifically I wanted to try streaming texture transfers as described here:

http://ogltotd.blogspot.com/2006/12/streaming-texture-updates.html

I don't get any GL errors with implementing that, but also no pixel transfer seems to happen (black geometry instead of textured).

Now the interesting part of his snippet the author doesn't go into:

writeImage(pboMappedMemory)"

-- but I've seen this part in other tutorials typically as just a single:

memcpy(myPixPtr, pboMappedBuffer)

call. Obviously that's C and I presume in Go one would just emulate that by doing

*dstPtr = *srcPtr

Now, since in gogl the glMapBuffer returns a *gl.Pointer, all I knew to do was:

var myPicPtr gl.Pointer = getPix0Ptr(...)
var pboPtr *gl.Pointer = gl.MapBuffer(...)
*pboPtr = myPicPtr

But while not causing any errors, it does also not result in the desired pixel transfer from what I can tell...

I just wanted to ask if you (or anyone else here) has any other ideas on how to emulate memcpy here -- since you definitely know your C and its pointers way better than me....

If you don't have anything come to mind off the top of your head but would be interested in a minimal sample app for this scenario, I'll be happy to code one up for further experimentation...

[not-an-"issue"] good stuff: gogl42 even works with older GL versions

... of course, only if the version-related error returned by gl42.Init() is ignored and if no GL functions are called that the current run-time client GL version doesn't yet support.

Just wanted to say (you probably intended this but not sure) -- that's a feature, not a bug! Please keep it that way. I'd like for this behavior to remain so in future versions, so that I can continue to dynamically support both the newest GL features and remain compatible with older versions easily, without having to create different builds with different gogl imports or anything like that. The current ways of gogl are just perfect in that regard. No need to change a thing here ;)

Heads-up for other gogl users -- can put in the Wiki if you think that's applicable:

to find out the current client GL version, gl.GoStringUb(gl.GetString(gl.VERSION))
for keeping track of whether any code portions in your code-base reference any gogl functions or enum values that are "newer than a certain minimum GL version", I've written a simple tool to "parse .go source tree and GL XML spec, then print summary of GL API usage of any&all newer-than-said-minimum GL versions", details here

Feel free to close this non-"issue" as desired... & thx for creating gogl!

How to use under Windows?

Hi chsc,

I used gogl for 2 months under Linux and it worked like a charm. Now moving to a Windows dev environment and cannot get glfw to work ( https://github.com/jteeuwen/glfw/issues/9 ) -- however, I did see your screenshot of a successfully running spinning gopher gogl example program -- so somehow it must be possible to run under Windows. How did you pull this off? Did the jteeuwen/glfw package work for you right out of the box after a go-get or did you have to pull some additional tricks? The original glfw.dll was re-built and installed over here, makes no difference.

So not directly a gogl issue -- feel free to close this right away -- but I'm just so curious as to how you managed to create that Windows GLFW app. After a full day of experimenting and trials I've really run out of ideas now. :/

GetError() causes nil func value runtime error.

I'm writing a wrapper lib around gogl to make writing GL code in Go a little easier to deal with. One of them is a wrapper to turn the OpenGL error stack into a Go error:

func GLErrors() error {
errormsg := ""
for errcode := gl.GetError(); errcode != gl.NO_ERROR; errcode = gl.GetError() {
switch errcode {
case gl.INVALID_ENUM:
errormsg = errormsg + "GL_INVALID_ENUM "
case gl.INVALID_VALUE:
errormsg = errormsg + "GL_INVALID_VALUE "
case gl.INVALID_INDEX:
errormsg = errormsg + "GL_INVALID_INDEX "
case gl.INVALID_OPERATION:
errormsg = errormsg + "GL_INVALID_OPERATION "
case gl.INVALID_FRAMEBUFFER_OPERATION:
errormsg = errormsg + "GL_INVALID_FRAMEBUFFER_OPERATION "
case gl.OUT_OF_MEMORY:
errormsg = errormsg + "GL_OUT_OF_MEMORY "
default:
errormsg = errormsg + "GL_UNKNOWN_ERROR(" + string(errcode) + ")"
}
}
if len(errormsg) > 0 {
return errors.New(errormsg)
}
return nil
}

However, on a freshly installed gl33 from your repo, I get the following runtime error when calling it:

panic: runtime error: call of nil func value
[signal 0xb code=0x1 addr=0x0 pc=0x0]

goroutine 1 [syscall]:
github.com/chsc/gogl/gl33._Cfunc_goglGetError(0x100, 0x420a63)
/tmp/go-build389262905/github.com/chsc/gogl/gl33/_obj/_cgo_defun.c:234 +0x2f
github.com/chsc/gogl/gl33.GetError(0x700407306, 0x407b74)
/tmp/go-build389262905/github.com/chsc/gogl/gl33/_obj/gl33.cgo1.go:3584 +0x1c
github.com/unit3/violet.GLErrors(0x407306, 0x7f7e26f91030)
/home/graeme/code/go/src/github.com/unit3/violet/utils.go:17 +0x3b

Seems to indicate that the go gl33 lib doesn't actually point to a function for gl.GetError(). I'm on Ubuntu 12.04/x64, with latest NVidia binary drivers (v302).

examples/gopher/gopher.go couldn't load PNG

Before fix:

func initScene() (err error) {

    texture, err = createTextureFromBytes(gopher_png[:])
    return
}

Gives compile error:

hornet: gopher$ go run gopher.go
# command-line-arguments
./gopher.go:119: undefined: gopher_png

After fix:

func initScene() (err error) {

    gopher_png, err := ioutil.ReadFile("gopher.png")
    if err != nil {
        panic("Could not load png")
    }

    texture, err = createTextureFromBytes(gopher_png)
    return
}

Had to comment 'go install ./gl31' from Makefile

When running make bindings it was giving the error:

can't load package: package github.com/chsc/gogl/gl31: cannot find package "github.com/chsc/gogl/gl31" in any of:
      /usr/local/go/src/pkg/github.com/chsc/gogl/gl31 (from $GOROOT)
      /Users/tl/Development/gocode/src/github.com/chsc/gogl/gl31 (from $GOPATH)

Commenting go install ./gl31 from the Makefile fixed it.

Interested in contributing

Christoph, I am interested in helping you further develop and evolve this package. I like the things you have here: https://github.com/chsc/GoGL/wiki/Further-development-ideas

I would e-mail you to start discussion, but I can't find your address anywhere! If you wish, you can get back to me here: jay at jayschwa dot net

Go string to **gl.Char

Hello,

I am converting my OpenGL 3 wiki examples https://github.com/Agon/gl3-examples from the OpenGL binding to your generated OpenGL 3.3 binding. I run into a conversion problem with func ShaderSource(shader Uint, count Sizei, string_ *_Char, length *Int), how do I convert a Go string ([]rune) into a *_gl.Char ?

Thanks in advance.

Add support for wglSwapIntervalEXT

Would be nice to be able to turn on vsync in Windows.

Unsure how to pass a matrix via gl.UniformMatrix4fv

I'm following the Arcsynthesis tutorials and teaching myself OpenGL using this great wrapper, and it's been going swimmingly. I've reproduced all the C++ code in Go without issues, until now. I'm wondering if this is a legitimate bug or just me not understanding how to do this with Go-GL. The exact part I'm stuck on is here:

http://arcsynthesis.org/gltut/Positioning/Tut04%20The%20Matrix%20Has%20You.html

Here's my Go code reproducing it (I've omitted the fragment shader, which is trivial)
https://gist.github.com/Ysgard/5234099

This code is very similar to the one preceding it, which worked. The main difference is in passing a matrix to a uniform in the shader. I've tried using both a []gl.Float slice and an [16]gl.Float array for a matrix, but neither seem to work. This is how I'm trying to pass the matrix to the shader:

gl.UniformMatrix4fv(perspectiveMatrixUnif, 1, gl.FALSE, &theMatrix[0])

I've tried &theMatrix and simply theMatrix, but both of those raise compile-time errors having to do with the type. If I pass &theMatrix[0], it compiles, but displays a black screen.

Am I passing this array correctly in UniformMatrix4fv?

gl.Init fails in gl21 with Intel GPU on Windows

Hey,
I have a laptop with a HD3000 Intel GPU and a discrete AMD GPU both with recent drivers. AMD supports OpenGL 4.1 and Intel 3.1.
OS: Windows 7 64bit

Source: http://pastebin.com/sKxUner5

This simple example fails for me with the Intel GPU with the following error:

unable to initialize VERSION_1_2_DEPRECATEDpanic: runtime error: call of nil func value
[signal 0xc0000005 code=0x8 addr=0x0 pc=0x0]

goroutine 1 [syscall]:
github.com/chsc/gogl/gl21._Cfunc_goglCreateShader(0x8b31, 0x25800000320)
C:/Users/Manuel/AppData/Local/Temp/go-build118120071/github.com/chsc/gogl/gl21/_obj/_cgo_defun.c:786 +0x32
github.com/chsc/gogl/gl21.CreateShader(0x8b31, 0xf84004d620, 0x2b, 0x0)
C:/Users/Manuel/AppData/Local/Temp/go-build118120071/github.com/chsc/gogl/gl21/_obj/gl21.cgo1.go:4890 +0x26
main.main()
C:/Users/Manuel/Dev/go opengl test/bugrep.go:47 +0x344

I checked that all needed functions are exposed by the Intel driver with glew and everything is there.
Changing the gl version to gl33 results in the mesesage "unable to initialize VERSION_3_2" which is correct since 3.2 is not supported by the driver but the example works then.

With the AMD gpu the example works correct with gl21 and gl33.

I found the following page, maybe it helps you: http://www.opengl.org/wiki/Load_OpenGL_Functions
I would like to help you testing but I am new to Go and OpenGL and probably can not help you with code.
Thanks for the nice bindings

Move goglGetProcAddress from cgo to a Go function

Implementing wgl will introduce more files, in new packages presumably. They will need to call goglGetProcAddress as well. From what I've heard cgo functions cannot be called from a different package. Therefore goglGetProcAddress shoud be moved to be a Go function.

What do you think is a good name for the file and where should it go?

For example, github.com/chsc/win32.go and in "package win32" with "+build windows" so that it builds only on windows. Or maybe github.com/chsc/util/windows.go in "package util". There are various options. What do you think is a good one?