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?

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?

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. :/

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.

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.]

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

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.

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?

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

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.

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.

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

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.

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.

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...

... 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!