Describe the bug
My game in raylib-goplus will compile successfully, the window will pop up, then immediately close. I've entered the debugger to follow the stack trace down, since all that is returned is an error code.
Process finished with exit code -1073741819 (0xC0000005)
I've been able to isolate this down to the drawing of a cube with a Shader attached. It's not a complex shader by any means, and it can be noted that it does compile just fine as per the raylib trace logs.
Upon further inspection, it's possibly related to the way in which goplus has it's Model structured. *[]Meshes Is a field that may cause runtime panics as the reference could be nil. Possible solution to this, would be to follow the style gen2brains uses by using a standard []Meshes slice. Even with a simple generated cube from raylib's own r.GenMeshCube(1.0,1.0,1.0) shows the *[]Meshes slice to have a length and capacity of:
Generate a cube mesh, load a model from that, add these shaders. An example in C can be found here
Expected behavior
Upon opening the program, it shouldn't fail, and the skybox shader should be rendered on screen. (Sorry not sure what else to put here ^^)
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Gamerfiend\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\Gamerfiend\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Gamerfiend\AppData\Local\Temp\go-build346618970=/tmp/go-build -gno-record-gcc-switches
Additional context
Add any other context about the problem here.
Describe the bug My game in raylib-goplus will compile successfully, the window will pop up, then immediately close. I've entered the debugger to follow the stack trace down, since all that is returned is an error code.
I've been able to isolate this down to the drawing of a cube with a
Shader
attached. It's not a complex shader by any means, and it can be noted that it does compile just fine as per the raylib trace logs.Upon further inspection, it's possibly related to the way in which goplus has it's
Model
structured.*[]Meshes
Is a field that may cause runtime panics as the reference could benil
. Possible solution to this, would be to follow the style gen2brains uses by using a standard[]Meshes
slice. Even with a simple generated cube from raylib's ownr.GenMeshCube(1.0,1.0,1.0)
shows the*[]Meshes
slice to have a length and capacity of:To Reproduce Steps to reproduce the behavior: Example Shader VS Example Shader FS
Generate a cube mesh, load a model from that, add these shaders. An example in C can be found here
Expected behavior Upon opening the program, it shouldn't fail, and the skybox shader should be rendered on screen. (Sorry not sure what else to put here ^^)
Screenshots The ever expanding mesh slice example
go env
ResponseAdditional context Add any other context about the problem here.