Quite a number of the examples don't work (on macOS)

Question

Quite a number of the examples don't work (on macOS)

prologic opened this issue 3 years ago · comments

See:

prologic@Jamess-iMac
Sat Sep 11 13:03:29
~/tmp/oak
 (master) 130
$ go run examples/keyboard-test/main.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x40d3600]

goroutine 13 [running]:
image.(*RGBA).Bounds(0x0)
	/usr/local/Cellar/go/1.17/libexec/src/image/image.go:98
image/draw.clip({0x41ff7f0, 0x0}, 0xc00010d9a0, {0x41fe9e0, 0xc000078200}, 0xc00010d960, {0x0, 0x0}, 0xc00010d980)
	/usr/local/Cellar/go/1.17/libexec/src/image/draw/draw.go:85 +0x6f
image/draw.DrawMask({0x41ff7f0, 0x0}, {{0x0, 0x0}, {0x280, 0x1e0}}, {0x41fe9e0, 0xc000078200}, {0x0, 0x0}, ...)
	/usr/local/Cellar/go/1.17/libexec/src/image/draw/draw.go:117 +0xa5
golang.org/x/image/draw.DrawMask(...)
	/Users/prologic/go/pkg/mod/golang.org/x/image@v0.0.0-20201208152932-35266b937fa6/draw/draw.go:31
golang.org/x/image/draw.Copy({0x41ff7f0, 0x0}, {0x0, 0x0}, {0x41fe9e0, 0xc000078200}, {{0x0, 0x0}, {0x280, 0x1e0}}, ...)
	/Users/prologic/go/pkg/mod/golang.org/x/image@v0.0.0-20201208152932-35266b937fa6/draw/scale.go:28 +0x1e5
golang.org/x/image/draw.nnInterpolator.Transform({}, {0x41ff7f0, 0x0}, {0x3ff0000000000000, 0x0, 0x0, 0x0, 0x3ff0000000000000, 0x0}, {0x41fe9e0, ...}, ...)
	/Users/prologic/go/pkg/mod/golang.org/x/image@v0.0.0-20201208152932-35266b937fa6/draw/impl.go:113 +0x158
github.com/oakmound/oak/v3/shiny/driver/mtldriver.(*windowImpl).Draw(0xc0001abdd0, {0x3ff0000000000000, 0x0, 0x0, 0x0, 0x3ff0000000000000, 0x0}, {0x4200098, 0xc0000100c0}, {{0x0, ...}, ...}, ...)
	/Users/prologic/tmp/oak/shiny/driver/mtldriver/window.go:132 +0xb6
github.com/oakmound/oak/v3/shiny/driver/internal/drawer.Scale({0x4200278, 0xc0001240f0}, {{0x1, 0x0}, {0x0, 0x0}}, {0x4200098, 0xc0000100c0}, {{0x0, 0x0}, ...}, ...)
	/Users/prologic/tmp/oak/shiny/driver/internal/drawer/drawer.go:30 +0x110
github.com/oakmound/oak/v3/shiny/driver/mtldriver.(*windowImpl).Scale(0xc0001240f0, {{0x0, 0x0}, {0x280, 0x1e0}}, {0x4200098, 0xc0000100c0}, {{0x0, 0x0}, {0x280, ...}}, ...)
	/Users/prologic/tmp/oak/shiny/driver/mtldriver/window.go:144 +0x78
github.com/oakmound/oak/v3.(*Window).publish(0xc000014800)
	/Users/prologic/tmp/oak/drawLoop.go:62 +0x15c
github.com/oakmound/oak/v3.(*Window).drawLoop(0xc000014800)
	/Users/prologic/tmp/oak/drawLoop.go:22 +0x125
created by github.com/oakmound/oak/v3.(*Window).lifecycleLoop
	/Users/prologic/tmp/oak/lifecycle.go:36 +0x1c9
exit status 2

I haven't looked into why yet...

Patrick Stephen · Answer 1 · Sat Sep 11 2021 11:08:27 GMT+0800 (China Standard Time)

We have limited Mac testing, so thanks for catching this, I'll look into it tomorrow.

James Mills · Answer 2 · Sat Sep 11 2021 11:09:47 GMT+0800 (China Standard Time)

We have limited Mac testing, so thanks for catching this, I'll look into it tomorrow.

Let me know how I can help! I'm pretty good with Go, just too tired to look into it right now 😴

Patrick Stephen · Answer 3 · Sat Sep 11 2021 20:25:10 GMT+0800 (China Standard Time)

With limited checking, it seems like windowImpl.rgba is nil sometimes, and we assume it isn't in all of its draw logic. Adding a check to windowImpl.Draw in mtldriver moves the panic to windowImpl.Publish.

The logic for initializing some of the window components was only done after we got a size event back from the OS, which might not happen until after we start drawing. The commit above (on release/3.0.0-final and backported to a hotfix branch) initializes those values on window creation.

@prologic Would you mind checking that branch and confirming it works on your end as well? hotfix/mtldriver-init

James Mills · Answer 4 · Sun Sep 12 2021 07:22:13 GMT+0800 (China Standard Time)

This seems to have fixed a few cases I guess?

I was even able to run the complete playformer example (sort of) until I re-ran it and it crahsed immediately (race?):

(⎈ |local:default)
prologic@Jamess-iMac
Sun Sep 12 09:21:06
~/tmp/oak
 (master) 0
$ go run examples/platformer-tutorial/6-complete/complete.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x40e3300]

goroutine 68 [running]:
image.(*RGBA).Bounds(0x0)
	/usr/local/Cellar/go/1.17/libexec/src/image/image.go:98
image/draw.clip({0x41f6c70, 0x0}, 0xc00013d9a0, {0x41f5e20, 0xc000282040}, 0xc00013d960, {0x0, 0x0}, 0xc00013d980)
	/usr/local/Cellar/go/1.17/libexec/src/image/draw/draw.go:85 +0x6f
image/draw.DrawMask({0x41f6c70, 0x0}, {{0x0, 0x0}, {0x280, 0x1e0}}, {0x41f5e20, 0xc000282040}, {0x0, 0x0}, ...)
	/usr/local/Cellar/go/1.17/libexec/src/image/draw/draw.go:117 +0xa5
golang.org/x/image/draw.DrawMask(...)
	/Users/prologic/go/pkg/mod/golang.org/x/image@v0.0.0-20210628002857-a66eb6448b8d/draw/draw.go:31
golang.org/x/image/draw.Copy({0x41f6c70, 0x0}, {0x0, 0x0}, {0x41f5e20, 0xc000282040}, {{0x0, 0x0}, {0x280, 0x1e0}}, ...)
	/Users/prologic/go/pkg/mod/golang.org/x/image@v0.0.0-20210628002857-a66eb6448b8d/draw/scale.go:28 +0x1e5
golang.org/x/image/draw.nnInterpolator.Transform({}, {0x41f6c70, 0x0}, {0x3ff0000000000000, 0x0, 0x0, 0x0, 0x3ff0000000000000, 0x0}, {0x41f5e20, ...}, ...)
	/Users/prologic/go/pkg/mod/golang.org/x/image@v0.0.0-20210628002857-a66eb6448b8d/draw/impl.go:113 +0x158
github.com/oakmound/oak/v3/shiny/driver/mtldriver.(*windowImpl).Draw(0xc00068b5d0, {0x3ff0000000000000, 0x0, 0x0, 0x0, 0x3ff0000000000000, 0x0}, {0x41f7518, 0xc000280010}, {{0x0, ...}, ...}, ...)
	/Users/prologic/tmp/oak/shiny/driver/mtldriver/window.go:132 +0xb6
github.com/oakmound/oak/v3/shiny/driver/internal/drawer.Scale({0x41f76b0, 0xc0001160f0}, {{0x1, 0x0}, {0x0, 0x0}}, {0x41f7518, 0xc000280010}, {{0x0, 0x0}, ...}, ...)
	/Users/prologic/tmp/oak/shiny/driver/internal/drawer/drawer.go:30 +0x110
github.com/oakmound/oak/v3/shiny/driver/mtldriver.(*windowImpl).Scale(0xc0001160f0, {{0x0, 0x0}, {0x280, 0x1e0}}, {0x41f7518, 0xc000280010}, {{0x0, 0x0}, {0x280, ...}}, ...)
	/Users/prologic/tmp/oak/shiny/driver/mtldriver/window.go:144 +0x78
github.com/oakmound/oak/v3.(*Window).publish(0xc000014800)
	/Users/prologic/tmp/oak/drawLoop.go:62 +0x15c
github.com/oakmound/oak/v3.(*Window).drawLoop(0xc000014800)
	/Users/prologic/tmp/oak/drawLoop.go:22 +0x125
created by github.com/oakmound/oak/v3.(*Window).lifecycleLoop
	/Users/prologic/tmp/oak/lifecycle.go:36 +0x1c9
exit status 2

James Mills · Answer 5 · Sun Sep 12 2021 07:22:28 GMT+0800 (China Standard Time)

Also the keys in the platformer example don't seem to work?

Patrick Stephen · Answer 6 · Sun Sep 12 2021 07:41:23 GMT+0800 (China Standard Time)

Ok, it looks like I assumed it was just one problem too quickly : ) I'll go through every example and verify that they operate correctly and add needed fixes to that PR.

James Mills · Answer 7 · Sun Sep 12 2021 08:31:26 GMT+0800 (China Standard Time)

Happy to test/confirm here! Thanks! 👌

Patrick Stephen · Answer 8 · Sun Sep 12 2021 19:57:48 GMT+0800 (China Standard Time)

Added a couple of fixes, remaining issues I see:

keyboard-test (osx key events either have runes or key directions, where other OSes always have both. Non trivial design decisions.)
joystick-viz (not implemented)
multi-window (not implemented)
screenopts (not implemented)
slide (scene flow halts, fixed in release/3.0.0-final and on this branch, going to prefer the former fix)
sprite-demo (image / rendering nil panic, fixed in release/3.0.0-final)
text-demo-1 (font not rendering, fixed in release/3.0.0-final)

Continuing to fix.

James Mills · Answer 9 · Sun Sep 12 2021 20:24:02 GMT+0800 (China Standard Time)

Sorry about all the work 🤗

Patrick Stephen · Answer 10 · Thu Sep 16 2021 07:02:35 GMT+0800 (China Standard Time)

Ok, I'm going to leave joystick support for the existing issue (#87), but having run through all of the examples before and re-run through about half, including all those that previously failed, post fixes; give it another go, please @prologic, on release/3.0.0-final.

Several examples were already fixed between the beta branch that is HEAD of master and release/3.0.0-final, which is to be released shortly, pending final review, but in addition the standard osx rendering driver is more or less up to feature parity with the standard windows and linux drivers through this line of work.

James Mills · Answer 11 · Fri Sep 17 2021 18:20:24 GMT+0800 (China Standard Time)

This is really cool! 🎉 Of the ones that were broken for me, now work! 👌 💯

Ii'll keep playing with this but I'm really happy 🤗

Patrick Stephen · Answer 12 · Sun Oct 03 2021 00:02:20 GMT+0800 (China Standard Time)

Closing as the original problem is resolved.