看一下用Go编写的这个超级简单的小型测试用例OpenGL程序：package mainimport ( "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) 在带有Go 1.0.1 64位的Windows 7 64位下，这可以很好地构建。如果您取出（或注释掉）gl.Clear（gl.COLOR_BUFFER_BIT）行，它也可以很好地工作（OpenGL绘制一个彩虹的2D三角形，直到关闭窗口）。现在，有几点值得注意的要点...所述GLFW包是一个简单的定制包装暴露的确切相同的API github.com/jteeuwen/glfw但内部使用的LoadLibrary / GetProcAddress的用于使用glfw.dll而不是编译时CGO / GCC / LD联-因为后者不能被可悲的是，它无法在64位Windows上运行，不确定是否应该责怪mingw64或gcc或cgo。使用LoadLibrary / GetProcAddress调用我的glfw.dll的自定义64位版本时，可以正常工作。显然，这里的问题是调用gl软件包，而不是glfw。该GL包确实只是这一次，修改。我尝试了一些LDFLAGS修改，例如-m64 -lmingw32 -Wl，/ windows / opengl32.dll等。但是没有区别，只要不调用gl.Clear（），原始修改的效果就和修改的效果一样好，所以我恢复了原来的状态。当然，稍后我将继续使用OpenGL 4.2。使用Process Explorer，我可以看到我的进程是64位的，并且所有加载的DLL也是64位的映像（包括opengl32.dll和glfw.dll）。“ gl21软件包可能无法获得由opengl32.dll导出的glClear（）函数的有效地址吗？” -不太可能：根据第2926行，如果是这种情况，我对gl.Init（）的调用将失败。GPU驱动程序有问题吗？甚至更不可能。已安装最新的官方nVidia Quadro 5010M驱动程序296.35。也尝试过“性能驱动程序”，但无论如何似乎都是完全相同的驱动程序。根据nVidia控制面板提供的完全OpenGL 4.2支持（尽管opengl32.dll的日期为2009年-无论如何，我目前定位的目标是2.1）。另外，“ Geeks3D GPU Caps Viewer”和“ Shader Toy Mark”中的OpenGL着色器也可以运行，GLFW示例程序particles.exe也可以运行-它们全部也使用glClear（）。当使用gl42而不是gl21时，会发生完全相同的问题，因此也不是原因。请注意在此示例中所有其他gl.SomeExportedFunc（）调用如何不会崩溃...怎么办，如何进行？如果只发生在gl.Clear（）上并且没有其他功能，我可以忍受这一点-无论如何我都只能渲染具有自定义内容的全屏四边形-但是我在这里测试Win64相当早（很多gl42代码在Linux64下都可以正常工作，现在即将“移植”到Win64），我担心以后再进行其他调用会暴露出同样的问题，因此，我现在进行报告。我很快就会发现还有哪些其他电话受到此影响。
2 回答
- 2 回答
- 0 关注
- 715 浏览
添加回答
举报
0/150
提交
取消