go-gl-legacy/gl

Go bindings for OpenGL

gl | OpenGL Bindings for golang

You will need GLEW at least version 1.5.4.

Once GLEW is installed, you can install this package with go get:

go get github.com/go-gl-legacy/gl

Contact / discussion mailing list

The discussion is hosted on google groups. We can also be found periodically on IRC, #go-gl on freenode.

Documentation and examples

Autogenerated documentation can be found on godoc.org, and the more thorough official GL SDK documentation applies.

Examples can be found in our examples repository.

More libraries: Easy windowing, meshes, text rendering, etc:

• GLFW bindings for easy windowing, input etc.
• gltext a native go library for glyph packing and text rendering
• glu GLU bindings
• glchart a go chart OpenGL backend
• gldebug graphical timing and memory debugging utilities

Problems and contributing

If you encounter any problems please file an issue. Pull requests are welcome. We're looking for contributors!

Setting your GOPATH

For the above go get to work without without requiring admin privileges, please refer to go documentation or this five minute go screencast.

Operating System Specific advice

The go-gl/gl authors primarily develop on Linux-based machines. The package should work on other operating systems, if you encounter problems after following the instructions below, please file an issue.

Linux / OSX

This package uses cgo and therefore you will need a C compiler such as GCC. On Debian, you can install build-essential to get this.

You need to install the GLEW development libraries the appropriate package manager for your Linux distribution or by downloading the sources from the GLEW website.

For non-standard GLEW install locations, after go get cd to $GOPATH/src/github.com/go-gl-legacy/gl and run:

CGO_CFLAGS="-I/path/to/includes" CGO_LDFLAGS="-L/path/to/libs" go install

You may be able to determine the appropriate flags using:

pkg-config glew --libs --cflags

Note that we import from GL/glew.h, so if pkg-config --cflags reports /opt/include/GL, you may need to remove /GL so that CGO_CFLAGS=-I/opt/include.

OSX

The following instructions are currently a best guess. If you develop on OSX please get in contact and let us know if this works, or not!

GLEW from Homebrew / Macports

These can be used to install GLEW. Beware that you may need to set CGO_CFLAGS and CGO_LDFLAGS - the Linux instructions above are relevant.

Windows

Windows support is currently unknown. gl uses cgo, and therefore you will need a C compiler. If you install the GLEW to your compiler's include and lib directories, things should work. If they do not, please contact us.

OpenGL 4.*

The glew-1.10 branch is available for those that need newer OpenGL 4.* functionality. To use it, manually clone the repository and checkout the branch. As the branchname implies, it's using GLEW 1.10.

Forward compatibility

It is the intent of the go-gl authors to keep gl and related packages forward-compatible at both the API/ABI levels per go release so that you can continue to import from this github repository. Development requiring breakage will occur on the glew-1.10 branch, and will be merged with master when a new go version is released.

gl's Issues

GenFramebuffer calls glGenRenderbuffers

Which does the wrong thing. Instead, it should be calling glGenFramebuffers; GenFramebuffers does the right thing.
Trivial fix is to change the call at gl.go:2457 to C.glGenFramebuffers

Bring constants in line with go-gl/glfw

Right now all of the OpenGL constants are of the form gl.ALL_CAPS_WITH_UNDERSCORES. In the C code, all of the GLFW constants are like this as well, but in the go-gl port, they've been changed to glfw.CamelCase. This makes it a little jarring when using both in tandem (and you probably are).

So either:

1. Switch glfw's constants to ALL_CAPS_WITH_UNDERSCORES
2. Switch gl's constants to CamelCase

or

A. Both packages have enough users that this will break too many people's builds.
B. There's a HUGE amount of constants, and the time it would take to change it isn't worth it

Whatever is decided (whether it be what to change, or if we do/don't change) is fine, but I thought I'd bring it up as food for thought since I encountered it when porting some OpenGL tutorials over to Go.

(Sidenote: where is gl.GLEW_OK? I can't find it anywhere. How does one check if Init() worked without it? I notice most of the example code never even calls Init() to initialize GLEW, is there a reason for that?)

Add CompressedTexImage2D

Is there any reason we don't have glCompressedTexImage2D? I was trying to make a .dds loader, but it looks like that function isn't implemented here (at least, I can't find it).

Here's the documentation for it:

http://www.opengl.org/sdk/docs/man3/xhtml/glCompressedTexImage2D.xml

godefs doesn't exist anymore

Related to #64.

Example programs segfault when linked against nvidia libGL

Just did a fresh build and install of your libSDL and libGL bindings for Go. After building, I get the example programs, but some strange behaviour with them. Attempting to run them directly fails, they both segfault, but if I run them under gdb (ie, "gdb ./draw"), then they succeed.

Any thoughts as to why this is? I'm building on Ubuntu 10.10 with the latest NVidia binary drivers, so perhaps there's some unexpected interaction there between your wrapper and the NVidia libGL?

Shader.GetSource() should be like GetInfoLog()

GetInfoLog() is better written
https://github.com/go-gl/gl/blob/master/shader.go#L32

I also suggest replacing variable "len" with "length" since "len" is a built-in Go function.

Support glGenerateMipmap

Currently, glGenerateMipmap is not supported. This can be worked around with the gl.GENERATE_MIPMAP texture parameter, but that is deprecated in GL3.

Add documentation

Documentation should be added to all functions.

Or at least, a link to the relevant man pages somewhere on the web.
Docs for each GL function can be quite large. Which may not be ideal for listing in the actual source code.

This should only be done after issue #79 is dealt with.

`go test` gives nil pointer dereference

go-gl/gl $ go test
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x438 pc=0x7ffb09005ac9]

goroutine 1 [chan receive]:
testing.RunTests(0x400c00, 0x642370, 0x1400000014, 0x635301, 0x200000002, ...)
    /home/pwaller/Projects/External/go/src/pkg/testing/testing.go:374 +0x7ee
testing.Main(0x400c00, 0x642370, 0x1400000014, 0x644e38, 0x0, ...)
    /home/pwaller/Projects/External/go/src/pkg/testing/testing.go:309 +0x80
main.main()
    github.com/go-gl/gl/_test/_testmain.go:81 +0x91

goroutine 2 [syscall]:
created by runtime.main
    /home/pwaller/Projects/External/go/src/pkg/runtime/proc.c:220

goroutine 3 [syscall]:
github.com/go-gl/gl._Cfunc_glTexImage1D(0xde0, 0x1000001908)
    github.com/go-gl/gl/_test/_cgo_defun.c:3010 +0x2f
github.com/go-gl/gl.TexImage1D(0xde0, 0x1000001908, 0x190800000000, 0x1404, 0x4b7628, ...)
    github.com/go-gl/gl/_test/gl.cgo1.go:456 +0x77
github.com/go-gl/gl.TestTexImage1D(0xf84008f100, 0x222921e8)
    /home/pwaller/.local/src/github.com/go-gl/gl/gl_test.go:36 +0x77
testing.tRunner(0xf84008f100, 0x642370, 0x0, 0x0)
    /home/pwaller/Projects/External/go/src/pkg/testing/testing.go:297 +0x6f
created by testing.RunTests
    /home/pwaller/Projects/External/go/src/pkg/testing/testing.go:373 +0x7cb
exit status 2
FAIL    github.com/go-gl/gl 0.099s

compilation failure (linux)

draw.go:19: out of fixed registers
draw.go:19: internal compiler error: regfree: reg not allocated

fix:
< distanceTo

func (p0 Point) distanceTo(p1 Point) float64 {
hook := (p0.x-p1.x)(p0.x-p1.x)
return math.Sqrt(float64(hook + (p0.y-p1.y)(p0.y-p1.y)))
}

Go 1 support?

The package is tantalizingly close to supporting Go 1 right now; is there any interest in getting it there? I have a local changeset I could contribute, though it's pretty trivial. I'd like to avoid having to fork the package to support "go get" installation.

No texture load example

I think this would be helpful

Problem compiling Go-OpenGL with libGLEW.1.7.0

When trying to compile Go-OpenGL using libGLEW.1.7.0 the system give this output:

gl.go: In function ‘_cgo_0ca662427903_Cfunc_glShaderSource’:
gl.go:241: 2: warning: passing argument 3 of ‘__glewShaderSource’ from incompatible pointer type
gl.go:241: 2: note: expected ‘const GLchar *_’ but argument is of type ‘GLchar *_’
gl.go: In function ‘_cgo_0ca662427903_Cfunc_glTransformFeedbackVaryings’:
gl.go:619: 2: warning: passing argument 3 of ‘__glewTransformFeedbackVaryings’ from incompatible pointer type
gl.go:619: 2: note: expected ‘const GLchar *_’ but argument is of type ‘GLchar *_’

The libGLEW version is 1.7.0

lrwxrwxrwx 1 root root 16 2012-02-27 11:45 /usr/lib/libGLEW.so -> libGLEW.so.1.7.0

Go version:

go version weekly.2012-02-22 +96bd78e7d35e

Call to gl.GenTextures

Currently, GenTextures takes *GLuint as argument for textures, but the API documentation states that this is actually used to assign more than one "name", depending on the first argument.
Ideally, i wouldn't want to worry about things like this, so I propose that GenTextures returns an array instead of modifying an external one.
Since I'm not very familiar with the typical use-cases of this function, are there any issues with that approach?

Also, i tried modifying the function so it passes the pointer like this:

// void glGenTextures (GLsizei n, GLuint *textures)
func GenTextures(n GLsizei) []*GLuint {
  textures := make([]*GLuint, n)
  C.glGenTextures(C.GLsizei(n), (*C.GLuint)(unsafe.Pointer(&textures[0])))
  return textures
}

The result of gl.GenTextures(4) is [0x200000001 0x400000003 <nil> <nil>]

First of all, this seems like it tries to output [1 2 3 4], but for some reason it ends up combining at high and low bit, might be a side-effect of how Go keeps the array in memory?
And second, I still don't know what it actually returns in C, and how it's used there, so my proposal is flawed and needs more thought.

OK, I think i just fixed it, instead of *GLuint I should've used actual GLuint:

// void glGenTextures (GLsizei n, GLuint *textures)
func GenTextures(n GLsizei) []GLuint {
  textures := make([]GLuint, n)
  C.glGenTextures(C.GLsizei(n), (*C.GLuint)(unsafe.Pointer(&textures[0])))
  return textures
}

This actually returns [1 2 3 4] as I predicted.
Go still keeps confusing me with the behavior of pointers in relation to arrays.

Get runtime error when attempting creation of VBO

I get a runtime error when I attempt to create a VBO using gl.GenBuffer(). This error occurs on an Ubuntu computer with openGL version 4.1.0. I used GLFW to set up the context and the latest release of 6g to compile the program.

I'm lost as to the reason for the crash. Any help would be appreciated!

Example code in question (drawing function):

gl.Clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT)
gl.LoadIdentity()

var points []gl.GLfloat
for point := gl.GLfloat(-4.0); point < 5.0; point += 0.5 {
    points = append(points, point, 0.0, 0.0)
}

buf := gl.GenBuffer()
buf.Bind(gl.ARRAY_BUFFER)
gl.BufferData(gl.ARRAY_BUFFER, len(points), points, gl.STATIC_DRAW)
var pointSize float32 = 0.5
for i := 0; i < len(points)/3; i++ {
    gl.PointSize(pointSize)
    gl.DrawArrays(gl.POINTS, i, 1)
    pointSize += 1.0
}
buf.Delete()
glfw.SwapBuffers()

Stack trace of error below:

panic: runtime error: invalid memory address or nil pointer dereference

[signal 0xb code=0x1 addr=0x0 pc=0x0]

runtime.panic+0xac /home/user/go/src/pkg/runtime/proc.c:1254
runtime.panic(0x46ada8, 0xf8400023f0)
runtime.panicstring+0xa3 /home/user/go/src/pkg/runtime/runtime.c:125
runtime.panicstring(0x4df9b3, 0x7fc61ef8efd3)
runtime.sigpanic+0x144 /home/user/go/src/pkg/runtime/linux/thread.c:307
runtime.sigpanic()
runtime.asmcgocall+0x5f /home/user/go/src/pkg/runtime/amd64/asm.s:461
runtime.asmcgocall(0x7fc621ee3e60, 0xf840004000, 0x20a000000000, 0x4021f3)

goroutine 1 [3]:
return /home/user/go/src/pkg/runtime/amd64/asm.s:424
return()
runtime.cgocall+0x110 /home/user/go/src/pkg/runtime/cgocall.c:135
runtime.cgocall(0x4237cb, 0x7fc621ee3eb8, 0x33, 0x422a42)
gl._Cfunc_glGenBuffers+0x2f /home/user/go_libs/Go-OpenGL/gl/_obj/_cgo_defun.c:362
gl._Cfunc_glGenBuffers(0x1, 0xf8400001f8)
gl.GenBuffer+0x3e /home/user/go_libs/Go-OpenGL/gl/_obj/gl.cgo1.go:-1572
gl.GenBuffer(0x44c6f8, 0xf840020f00)
main.drawScene+0x66 /home/user/go_sandbox/ch3/points.go:94
main.drawScene()
main.main+0x2d2 /home/user/go_sandbox/ch3/points.go:50
main.main()
runtime.mainstart+0xf /home/user/go/src/pkg/runtime/amd64/asm.s:78
runtime.mainstart()
runtime.goexit /home/user/go/src/pkg/runtime/proc.c:246
runtime.goexit()
----- goroutine created by -----
_rt0_amd64+0xc9 /home/user/go/src/pkg/runtime/amd64/asm.s:65

Arguments require unsafe.Pointer

A couple of functions require an unsafe.Pointer argument, I think they shouldn't require that but take normal Go pointers.

Unable to compile on Mac OSX

Due to Mac OSX having different paths and the concept of "frameworks", the bindings can't be compiled. On Mac OSX you generally compile OpenGL sources like:

gcc -framework OpenGL foo.c

With foo.c including OpenGL/gl.h, not GL/gl.h. These frameworks are just bundled libraries and headers so you could also pass in -I and -L to gcc, but the #includes still need to be modified.

The error that occurred:

$ make
make -C gl install
CGOPKGPATH= /Users/sebastian/local/bin/cgo  gl.go
gcc failed:
<stdin>:12:19: error: GL/gl.h: No such file or directory
<stdin>:13:22: error: GL/glext.h: No such file or directory
[SNIP: bunch of "undeclared" errors]

The headers are actually in /System/Library/Frameworks/OpenGL.framework/Headers (although alternate SDKs are available), so a few changes to the gl/Makefile and Go files are required.

Mac OSX "integer constant is too large"

When installing or importing the go-gl package on Mac OSX Lion, I get three warnings that say:

"gl_defs.go:linenum: warning: integer constant is too large for 'long' type"

The line numbers in each warning are different each time you try to install/import the package, making it difficult to pinpoint exactly what is wrong.

gl.Init() panics cause of glewExperimental

gl.Init() panics cause of C.glewExperimental = C.GLboolean(1) on windows 7 64bit glew 1.9.0.

Or is it a go bug? I'm using go 1.1beta2 386

runtime error: invalid memory address or nil pointer dereference panic.c:487, os_windows.c:303, attriblocation.cgo1.go:2339, ....

Adding gluPerspective

Yet another function that would be nice to have is gluPerspective.

func Perspective(fovy, aspect, zNear, zFar gl.GLdouble) {
  C.gluPerspective(
    C.GLdouble(fovy),
    C.GLdouble(aspect),
    C.GLdouble(zNear),
    C.GLdouble(zFar),
  )
}

error while linking a program with gl20

while linking my test program with the gl20 lib i got this error

cgocall: type.gl.GLdouble: not defined
cgocall: type.gl.GLint: not defined
cgocall: type.gl.GLsizei: not defined

i was able to solve it using this patch on gl20, thought i don't understand why it came up in the first place.

diff --git a/gl20/gl.go b/gl20/gl.go
index f7be9dd..c6e0e1d 100644
--- a/gl20/gl.go
+++ b/gl20/gl.go
@@ -22,6 +22,10 @@ type GLbitfield C.GLbitfield
type GLclampf C.GLclampf
type GLclampd C.GLclampd

+type GLint C.GLint
+type GLdouble C.GLdouble
+type GLsizei C.GLsizei
+
type Pointer unsafe.Pointer

// helpers

Mixing GL code with goroutines causes crashes in GL libs.

The Problem

My program has a parser which makes use of goroutines. No GL calls are made from any goroutine other than the main/original goroutine. As soon as I start using goroutines, my GL calls start segfaulting deep in the OpenGL drivers (based on disassembly, I know that a lookup table contains NULL where it should contain a function pointer). The same program without the use of goroutines works perfectly. Here is an overview of the facts:

1. My goroutines never touch GL code or cgo of any kind (other than burried in the standard libs)
2. The code works flawlessly if it runs without goroutines used anywhere in the program
3. As soon as a goroutine other than the main goroutine makes a GL call (I did this in a test) or a system call, all GL functions are instantly broken
   • Any glcall results in a segfault
   • The segfault occurs at some sort of table lookup deep in the graphics vendor's GL implementation
   • The results are the same on Intel, NVidia, and ATI chips (I have at least one of each in the lab I'm working in)
4. Debugging and disassembly reveal that the arguments passed to the GL calls that cause the crash are 100% perfect. The problem is unrelated to GLEW, I make it to the actual GL function.
5. The same problem occurs if I call C.gl*() directly, it is not specific to Go-OpenGL

A Solution

The whole problem goes away if I

1. Call runtime.LockOSThread() in the same goroutine that I call gl.Init() from.
2. Never make GL calls from any other thread

I discovered this solution based on a lot of tracing and guessing, I don't know if I'm really fixing the problem or just covering it up. If anyone knows what is actually happening it might help us find a good universal solution.

A Guess At The Cause

I don't know very much about the subject, but it seems like perhaps the OpenGL implementation is using Thread Local Storage. Then maybe the following would happen:

• Program starts on Goroutine 0 on OS thread 0
• Program launches goroutine 1
• Goroutine 1 gets scheduled in on OS thread 0
• Goroutine 1 makes a system call, Go scheduler locks it to OS thread 0.
• Go scheduler spawns OS thread 1 so that goroutine 0 can keep working
• GL call happens from goroutine 0 on OS thread 1, where thread local storage is no longer properly initialized
• SIGSEGV

Even if it isn't the thread local storage thing, I am relatively sure it has something to do with GL calls being made from a thread other than that where OpenGL was initialized.

As a disclaimer, I don't fully understand all of the topics I've discussed here, at least not enough to preach about them. What I know is based on a few days of debugging. I read through all sorts of the go runtime's source code and the generated cgo code, and I disassembled and walked through a lot of library code. If anyone has more detailed knowledge of all of this stuff, I would be very grateful to hear it.

Cannot build on ubuntu

$ sudo add-apt-repository ppa:niemeyer/ppa
$ sudo apt-get update
$ sudo apt-get install libglew1.5-dev golang
$ git clone https://github.com/banthar/Go-OpenGL.git
$ cd Go-OpenGL
$ gomake
gomake -C gl
make[1]: Entering directory /home/lucio/src/go/Go-OpenGL/gl' CGOPKGPATH= cgo -- gl.go 1: error: 'glPauseTransformFeedback' undeclared (first use in this function) 1: note: each undeclared identifier is reported only once for each function it appears in 1: error: 'glIsTransformFeedback' undeclared (first use in this function) 1: error: 'glDrawTransformFeedback' undeclared (first use in this function) 1: error: 'glBindTransformFeedback' undeclared (first use in this function) 1: error: 'glDeleteTransformFeedbacks' undeclared (first use in this function) 1: error: 'glGenTransformFeedbacks' undeclared (first use in this function) unresolved names make[1]: *** [_obj/_cgo_run] Error 2 make[1]: Leaving directory/home/lucio/src/go/Go-OpenGL/gl'
make: *** [gl] Error 2

This was on natty (11.04) but i had the same issue on maverick (10.10). Glew headers are on /usr/include/GL. But they dont include the functions, only their *NV versions.

$ grep glPauseTransformFeedback /usr/include/GL/*
/usr/include/GL/glew.h:#define glPauseTransformFeedbackNV GLEW_GET_FUN(__glewPauseTransformFeedbackNV)
/usr/include/GL/glext.h:GLAPI void APIENTRY glPauseTransformFeedback (void);
/usr/include/GL/glext.h:GLAPI void APIENTRY glPauseTransformFeedbackNV (void);
/usr/include/GL/gl_mangle.h:#define glPauseTransformFeedback MANGLE(PauseTransformFeedback)
/usr/include/GL/gl_mangle.h:#define glPauseTransformFeedbackNV MANGLE(PauseTransformFeedbackNV)

Can't Unbind Textures

I can't work out how todo this now. I used to call gl.BindTexture(gl.TEXTURE_2D, 0) but it has been removed.

Tests are passing when they should not

Adding nice GetErrorString

I've spent some time debugging the segfault in combination with Go-SDL and wanted to get errors from Go-OpenGL, but that was impossible with GetError.
So i whipped up this hack: https://gist.github.com/d7fb620403c46eb55ab5
I'm not sure what's up with the GLhalfARB and GLhalfNV types, but maybe nothing critical?

Support for VBOs

VBO functions like glGenBuffers, glDeleteBuffers, ... are missing.

Build failure (Ubuntu)

this is the error I'm getting when I try to build:

$ gomake
gomake -C gl
make[1]: Entering directory /home/gregg/workspace/Go-OpenGL/gl' CGOPKGPATH= cgo -- gl.go 1: error: 'glIsTransformFeedback' undeclared (first use in this function) 1: note: each undeclared identifier is reported only once for each function it appears in 1: error: 'glPauseTransformFeedback' undeclared (first use in this function) 1: error: 'glGenTransformFeedbacks' undeclared (first use in this function) 1: error: 'glDrawTransformFeedback' undeclared (first use in this function) 1: error: 'glBindTransformFeedback' undeclared (first use in this function) 1: error: 'glDeleteTransformFeedbacks' undeclared (first use in this function) unresolved names make[1]: *** [_obj/_cgo_run] Error 2 make[1]: Leaving directory/home/gregg/workspace/Go-OpenGL/gl'
make: *** [gl] Error 2

VertexAttribPointer usage

I believe there is a bug in the wrapper implementation of glVertexAttribPointer().

Looking at "gl.go", I can see that an unsafe pointer is being passed as the final parameter to glVertexAttribPointer() by way of the value returned from GetGLenumType(). So basically your wrapper accepts a slice of some type and uses that to determine both the data/enum type and a pointer to the start of my buffer (right?)

From the GL Spec, the final parameter to glVertexAttribPointer() should be a pointer to the OFFSET within the buffer that my attribute data begins. Typically this value is 0 because the attribute data starts at the beginning of the buffer. So I'm not sure what we should change the value to be, but I do know that the current implementation will crash at draw time. I can edit "gl.go" to use 'nil' as the final parameter (equivalent to a zero offset) and the program draws correctly.

I should also let you know that my tests were all done using a modified version of your Go-SDL package that was made to work with SDL 1.3. This "port" was the barest minimum I needed to use OpenGL 3.x but I'm curious if other people would want my changes. I'm new to github and the open source community in general so I am unsure how to go about creating a proper fork so that I can give back.

Return something useful from gl.Init()

Currently, gl.Init() passes value returned from glewInit().
This doesn't make any sense, since we don't define GLEW_OK.
It should return something different. For example:

1. true/false
2. 0/non-zero
3. nil/error with meaningful message

Problem with installing Go-OpenGL

Hi guys. I'm fairly new to the Go programming language, and I was wondering what was going on with this statement:

gomake -C gl
make[1]: Entering directory $HOME/banthar-Go-OpenGL-068c350/gl' CGOPKGPATH= cgo -- gl.go gl_notdarwin.go touch _obj/_cgo_run 8g -o _go_.8 gl_defs.go _obj/gl.cgo1.go _obj/gl_notdarwin.cgo1.go _obj/_cgo_gotypes.go gl.go:44[_obj/gl.cgo1.go:47]: undefined: reflect.NewValue gl.go:81[_obj/gl.cgo1.go:84]: undefined: reflect.Typeof make[1]: *** [_go_.8] Error 1 make[1]: Leaving directory$HOME/banthar-Go-OpenGL-068c350/gl'
make: *** [gl] Error 2

This is what I got after trying to use the command make. Could anyone please tell me what's going on here? I tried using Git, downloading as a tar, etc. and I still got the same dreadful results. Thanks!

API breaking changes to accept arrays of fixed length

The plan is to modify functions which accept slices of fixed length to instead perform the "check" at compile time by using types such as *[16]float32.

If you plan to tackle this issue, please assign yourself to it.

LoadMatrixd and GetDoublev issue

m := new([16]float64)
setIdentity(m)

gl.LoadMatrixd((_gl.GLdouble)(&m[0]))
gl.Rotated(90, 0, 1, 0)
gl.GetDoublev(gl.MODELVIEW_MATRIX, (_gl.GLdouble)(&m[0]))
gl.PopMatrix()

fmt.Printf("%f", m[0])
// m[0] == forward.x

GetDoublev doesn't seem to be affecting the matrix

Problems compiling on ubuntu 10.10

I'm trying to compile Go-OpenGL on ubuntu 10.10 with the latest version of Go but it gives me the following error:

gomake -C gl
make[1]: Entering directory `/home/luka/Desktop/Go-OpenGL/gl'
CGOPKGPATH= cgo --  gl.go
touch _obj/_cgo_run
8g  -o _go_.8 gl_defs.go _obj/gl.cgo1.go _obj/_cgo_gotypes.go
gl.go:122[_obj/gl.cgo1.go:125]: cannot use _Ctypedef_GLuint(shader) (type _Ctypedef_GLuint) as type _Ctypedef_GLint in function argument
make[1]: *** [_go_.8] Error 1
make[1]: Leaving directory `/home/luka/Desktop/Go-OpenGL/gl'
make: *** [gl] Fehler 2

Also, I don't really see what could be wrong with gl.go:122. I just got into Go and don't understand this so could anyone please tell me whats wrong?

No function to pass matrices via uniform

http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml

Like glUniformMatrix4fv.

Fix links in README.md : More Libraries

The links of the "More Libraries" section of README.md are broken when looking at the readme from www.github.com/go-gl/gl (The links work fine inside the Windows github app)

e.g. url from webpage:
https://github.com/go-gl/gl/blob/master/go-gl/glfw

wanted url:
https://github.com/go-gl/glfw

eg markdown:
* [GLFW bindings](/go-gl/glfw) for easy windowing, input etc.

There are multiple ways to solve this, I suggest absolute links:
* [GLFW bindings](https://www.github.com/go-gl/glfw) for easy windowing, input etc.

Or you could use relative links, adjusting for how the github webpage handles them:
* [GLFW bindings](../../../../go-gl/glfw) for easy windowing, input etc.

Both options work with the github webpage and the github app

Problems with output of vertex buffers

There seems to be a problem somewhere with the usage of vertex buffers.
I can't for the life of me get it to output anything. And I don't appear to be the only one.

Here is the simplest example program I could come up with to demonstrate the issue:
https://gist.github.com/3936014

This displays only the manually drawn quad. The one the VBO should be drawing is nowhere to be found.

Someone on the Go Mailing List posted the same problem a few days ago
He is including shaders in the mix, which makes the problem only that much harder to track down. This is why I omitted them from my gist example.

Another one posted the same problem on Stackoverflow a few months ago.

I suspect there is something going on with one of the following functions:

• gl.BufferData.
• gl.AttribLocation.AttribPointer.
• gl.DrawElements
• gl.DrawArrays

Specifically the way the vertex data sent to- or access by the opengl driver.
At this point I am grasping at straws though.

It should be noted that the result is the same when using either DrawElements with an index buffer, or using DrawArrays without any indices.

What are the chances of this working on windows/MinGW?

go-gtk now can be built (with lots of effort) on windows. How difficult do you think it will be to get this library to work there (I have not yet looked at it or tried)?

Thanks,

David

glu.go in gl package?

I cannot import gl and glu like this: import("gl"; "glu"), it has to be import("gl"; glu "glu"), because the glu.go says it's the gl package, is that intentional or a typo?

Windows (MinGW) GlewInit not defined

With glew32.dll in C:\MinGW\bin, libglew32.dll.a in C:\MinGW\lib, and the .h files in C:\MinGW\include I finally got go-gl/gl to install (my initial problem was that you have to build GLEW from source for MinGW, the binaries they give are for VC++). I also built and installed glfw and installed go-gl/glfw without issue.

Now, however, when I try to build the test program from go-gl/examples/glfw/draw I get the problem:

C:\Users\Jsor\AppData\Local\Temp\go-build141226707/github.com/go-gl/gl.a(gl.cgo2.o)(.text): glewInit: not defined
glewInit(0): not defined

I was thinking this was a static vs dynamic linking problem. I tried altering gl.h to define GLEW_STATIC like the GLEW website recommended for Windows (since it seems to imply that Windows doesn't like dynamically linking GLEW for whatever weird reason), but no dice.

Doesn't build after opengl upgrade

On archlinux:

# github.com/go-gl/gl
In file included from attriblocation.go:7:0:
gl.h:5:25: error: enumerator value for '__cgo_enum__5' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1895:36: note: in expansion of macro 'GLEW_GET_FUN'
 #define glDisableVertexAttribArray GLEW_GET_FUN(__glewDisableVertexAttribArray)
                                    ^
gl.h:5:25: error: enumerator value for '__cgo_enum__6' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1957:27: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib3fv GLEW_GET_FUN(__glewVertexAttrib3fv)
                           ^
gl.h:5:25: error: enumerator value for '__cgo_enum__7' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1950:26: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib2f GLEW_GET_FUN(__glewVertexAttrib2f)
                          ^
gl.h:5:25: error: enumerator value for '__cgo_enum__8' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1956:26: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib3f GLEW_GET_FUN(__glewVertexAttrib3f)
                          ^
gl.h:5:25: error: enumerator value for '__cgo_enum__9' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1944:26: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib1f GLEW_GET_FUN(__glewVertexAttrib1f)
                          ^
gl.h:5:25: error: enumerator value for '__cgo_enum__10' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1978:31: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttribPointer GLEW_GET_FUN(__glewVertexAttribPointer)
                               ^
gl.h:5:25: error: enumerator value for '__cgo_enum__11' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1945:27: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib1fv GLEW_GET_FUN(__glewVertexAttrib1fv)
                           ^
gl.h:5:25: error: enumerator value for '__cgo_enum__12' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1971:27: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib4fv GLEW_GET_FUN(__glewVertexAttrib4fv)
                           ^
gl.h:5:25: error: enumerator value for '__cgo_enum__13' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1970:26: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib4f GLEW_GET_FUN(__glewVertexAttrib4f)
                          ^
gl.h:5:25: error: enumerator value for '__cgo_enum__14' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1951:27: note: in expansion of macro 'GLEW_GET_FUN'
 #define glVertexAttrib2fv GLEW_GET_FUN(__glewVertexAttrib2fv)
                           ^
gl.h:5:25: error: enumerator value for '__cgo_enum__15' is not an integer constant
 #define GLEW_GET_FUN(x) (*x)
                         ^
/usr/include/GL/glew.h:1897:35: note: in expansion of macro 'GLEW_GET_FUN'
 #define glEnableVertexAttribArray GLEW_GET_FUN(__glewEnableVertexAttribArray)
                                   ^
attriblocation.go:42:2: error: initializer element is not constant
 func (indx AttribLocation) Attrib4fv(values *[4]float32) {
  ^
attriblocation.go:42:2: error: (near initialization for '__cgodebug_data[5]')
attriblocation.go:43:2: error: initializer element is not constant
  C.glVertexAttrib4fv(C.GLuint(indx), (*C.GLfloat)(&values[0]))
  ^
attriblocation.go:43:2: error: (near initialization for '__cgodebug_data[6]')
attriblocation.go:44:2: error: initializer element is not constant
 }
  ^
attriblocation.go:44:2: error: (near initialization for '__cgodebug_data[7]')
attriblocation.go:45:2: error: initializer element is not constant

  ^
attriblocation.go:45:2: error: (near initialization for '__cgodebug_data[8]')
attriblocation.go:46:2: error: initializer element is not constant
 func (indx AttribLocation) AttribPointer(size uint, typ GLenum, normalized bool, stride int, pointer interface{}) {
  ^
attriblocation.go:46:2: error: (near initialization for '__cgodebug_data[9]')
attriblocation.go:47:2: error: initializer element is not constant
  C.glVertexAttribPointer(C.GLuint(indx), C.GLint(size), C.GLenum(typ),
  ^
attriblocation.go:47:2: error: (near initialization for '__cgodebug_data[10]')
attriblocation.go:48:2: error: initializer element is not constant
   glBool(normalized), C.GLsizei(stride), ptr(pointer))
  ^
attriblocation.go:48:2: error: (near initialization for '__cgodebug_data[11]')
attriblocation.go:49:2: error: initializer element is not constant
 }
  ^
attriblocation.go:49:2: error: (near initialization for '__cgodebug_data[12]')
attriblocation.go:50:2: error: initializer element is not constant

  ^
attriblocation.go:50:2: error: (near initialization for '__cgodebug_data[13]')
attriblocation.go:51:2: error: initializer element is not constant
 func (indx AttribLocation) EnableArray() {
  ^
attriblocation.go:51:2: error: (near initialization for '__cgodebug_data[14]')
attriblocation.go:52:2: error: initializer element is not constant
  C.glEnableVertexAttribArray(C.GLuint(indx))
  ^
attriblocation.go:52:2: error: (near initialization for '__cgodebug_data[15]')

draw.go could just check for Escape (with patch)

I often move windows by holding down "alt".
Pressing "alt" makes the draw.go window close.

Here's a patch (created with "git diff draw.go"):

diff --git a/examples/draw.go b/examples/draw.go
index ea3e8f3..f183916 100644
--- a/examples/draw.go
+++ b/examples/draw.go
@@ -6,9 +6,11 @@ package main
 
 */
 
-import "sdl"
-import "gl"
-import "math"
+import (
+   "sdl"
+   "gl"
+   "math"
+)
 
 type Point struct {
    x int
@@ -97,10 +99,11 @@ func main() {
            switch e.Type {
            case sdl.QUIT:
                running = false
-               break
            case sdl.KEYDOWN:
-               running = false
-               break
+               ke := e.Keyboard()
+               if ke.Keysym.Sym == sdl.K_ESCAPE {
+                   running = false
+               }
            case sdl.MOUSEMOTION:
                me := e.MouseMotion()
                if me.State != 0 {
@@ -108,7 +111,6 @@ func main() {
                } else {
                    pen.moveTo(Point{int(me.X), int(me.Y)})
                }
-               break
            }
        }
 

Note that I also removed "break" as it's not needed, and gathered the imports.

Thanks!

CLIENT_ALL_ATTRIB_BITS: constant -1 overflows gl.GLbitfield

CLIENT_ALL_ATTRIB_BITS                        = -0x1

This is not compatible with a function call to gl.PushClientAttrib.

# gl.PushClientAttrib(gl.CLIENT_ALL_ATTRIB_BITS)
experiment.go:32: constant -1 overflows gl.GLbitfield

Open-GL example issue

Well, it's really confusing. I managed to bind Go to Open-GL, thanks to some help from banthar; however when I ran make, when it got to 8g draw.go, it said this:

draw.go:10: import /$HOME/go/pkg/linux_386/sdl.a: object is [linux 386 release.r57.1 8355] expected [linux 386 release.r57.1 8294]

If anyone uses Ubuntu, can you help me please?

Thank you.

Missing function for gluBuild2DMipmaps

While working on the tutorials, I've found this function is missing: https://gist.github.com/ff54033030229b1eeb75
There are a couple of other glu* functions that would be convenient to have, but I'm not sure if I should add them as well, is that within the scope of Go-OpenGL?

Unable to run demos

$ sudo go install -a -v github.com/banthar/gl
runtime

runtime

/usr/lib/go/src/pkg/runtime/extern.go:121: undefined: defaultGoroot
/usr/lib/go/src/pkg/runtime/extern.go:130: undefined: theVersion
/usr/lib/go/src/pkg/runtime/extern.go:135: undefined: theGoos
/usr/lib/go/src/pkg/runtime/extern.go:135: cannot use theGoos as type string in const initializer
/usr/lib/go/src/pkg/runtime/extern.go:139: undefined: theGoarch
/usr/lib/go/src/pkg/runtime/extern.go:139: cannot use theGoarch as type string in const initializer

And then if I try to do go run or go build on draw.go:

$ go build draw.go

command-line-arguments

./draw.go:11: import /usr/lib/go/pkg/linux_amd64/github.com/banthar/gl.a: not a package file

Also, this is after editing the import from "sdl" to "github.com/banthar/Go-SDL/sdl" (otherwise, it would not find the package sdl)

This error is for all code that use the gl package.

Functions that should return a string return an *uint8 instead

The port would be much easier to use if it returned proper go strings when appropriate or at least byte-slices/uint8-slices.

Example: glGetString

Examples crash using MacPorts glew

I installed glew (and SDL) using MacPorts (a prevalent package manager) on OSX 10.6, which places libglew.{a,dylib} into /opt/local/lib and the headers into /opt/local/include. I was able to compile Go-OpenGL (and the sdl package of Go-SDL) by:

(1) export C_INCLUDE_PATH=/opt/local/include
(2) adding -L/opt/local/lib to CGO_LDFLAGS in various Makefiles (for some reason setting environment variables LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, and LD_FLAGS didn't work)
(3) changing "include <OpenGL/glew.h>" => "include <GL/glew.h>" in gl10/gl.go

However, running the examples generated no graphical output and crashed with the following trace, which I can't interpret. I'm totally new to OpenGL and a recent Go adopter (~1k lines written), so please forgive any naivete. I suspect that using MacPorts to install glew is something that many others will try. Your help is much appreciated!

$ ./draw
objc[62685]: Class SDLTranslatorResponder is implemented in both /opt/local/lib/libSDL-1.2.0.dylib and /Users/denero/Documents/workspace/go/pkg/darwin_amd64/sdl.so. One of the two will be used. Which one is undefined.
objc[62685]: Class SDL_QuartzView is implemented in both /opt/local/lib/libSDL-1.2.0.dylib and /Users/denero/Documents/workspace/go/pkg/darwin_amd64/sdl.so. One of the two will be used. Which one is undefined.
objc[62685]: Class SDL_QuartzWindowDelegate is implemented in both /opt/local/lib/libSDL-1.2.0.dylib and /Users/denero/Documents/workspace/go/pkg/darwin_amd64/sdl.so. One of the two will be used. Which one is undefined.
objc[62685]: Class SDL_QuartzWindow is implemented in both /opt/local/lib/libSDL-1.2.0.dylib and /Users/denero/Documents/workspace/go/pkg/darwin_amd64/sdl.so. One of the two will be used. Which one is undefined.
2010-07-01 08:03:04.723 draw[62685:903] *** __NSAutoreleaseNoPool(): Object 0x1606ec0 of class NSCFNumber autoreleased with no pool in place - just leaking
...[around 100 identical errors]...
2010-07-01 08:03:05.142 draw[62685:903] *** __NSAutoreleaseNoPool(): Object 0x160ce50 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
2010-07-01 08:03:05.142 draw[62685:903] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff867bcd24 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff80e210f3 objc_exception_throw + 45
2 CoreFoundation 0x00007fff867bcb47 +[NSException raise:format:arguments:] + 103
3 CoreFoundation 0x00007fff867bcad4 +[NSException raise:format:] + 148
4 AppKit 0x00007fff82427ace _NSCreateWindowWithOpaqueShape2 + 473
5 AppKit 0x00007fff823bc069 -[NSWindow _commonAwake] + 1214
6 AppKit 0x00007fff823b8d56 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1501
7 AppKit 0x00007fff823b79e2 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1396
8 AppKit 0x00007fff823b746b -[NSWindow initWithContentRect:styleMask:backing:defer:] + 42
9 sdl.so 0x0000000000280abd -[SDL_QuartzWindow initWithContentRect:styleMask:backing:defer:] + 285
10 sdl.so 0x000000000027df94 QZ_SetVideoMode + 1076
11 sdl.so 0x000000000027510f SDL_SetVideoMode + 527
12 sdl.so 0x000000000024d59c _cgo_SDL_SetVideoMode + 28
13 draw 0x0000000000006273 0x0 + 25203
)
terminate called after throwing an instance of 'NSException'

Makefiles need updating?

In order to build the Go-OpenGL bindings, I had to update the makefiles in the subdirectories (gl10, gl20, glu, examples) from:

include $(GOROOT)/src/Make.$(GOARCH)

to:

include $(GOROOT)/src/Make.inc

I assume this is because of the last update to the Go language?

Separate package for gl20/gl.go

It would be nice to build this by default, maybe as a separate package that can be used alongside gl similar to the way io and io/ioutils are structured.