Todo Brain Dump

[floooh]

• [x] code-generate the array-converter helpers
• [x] get rid of handwritten "extras" files entirely
• [x] GH Action test build
• [x] Windows: detect compiler for linker options
• [x] sokol-shdc: nim output
• [x] make sapp.Keycode items uppercase make enum {.pure.} add prefix to enum items, otherwise this can happen: https://twitter.com/FlohOfWoe/status/1540409023224315905
• [x] use same approach for sokol_glue.h as in the zig bindings
• [x] update samples to what's in sokol-zig
• [x] need a formatted print override for sdtx.printf()
• [x] the sokol-app event callback appears to allow writing to the Event arg (no const ptr) (see: https://github.com/floooh/sokol-nim/issues/18)
• [x] need a slice-to-range converter (see buffer update in instancing.nim)
• [x] the to_Range() often doesn't do what's expected (for instance when used on a slice)
• [x] test on Windows D3D11
• [x] test on Windows GL
• [x] test on macOS Metal
• [x] test on macOS GL
• [x] test on Linux

NOTE: slices in Nim are quite useless for efficiently "slicing out" an array range, because the slice operation creates a copy. Maybe experimental views can help somehow: https://nim-lang.org/docs/manual_experimental.html#view-types

[floooh]

Rendering problems on my Ubuntu laptop (specific to Nim, doesn't happen in the C version):

In blend demo, the background is sometimes black, and sometimes the expected quads are shown but are not moving:

In the MRT sample, the composed cube looks wrong (there composed cube doesn't have the RGB render targets shifted by offset):

...looks like a problem with shader uniforms? => check code-generated structs!

[floooh]

...the shader uniform problem on Linux is somehow caused by the to_Range converter.

Basically this works:

sg.Range(pointer: vsparams.unsafeAddr, size: vsparams.sizeof.uint)

...but this doesn't:

sg.Range(fsqParams)

The second statement goes through the to_Range() converter function. This somehow results in a range struct with a pointer pointing to invalid data (dangling?).

...it's interesting that this is only a problem in rare cases... only on Linux, and only on small structs, maybe 16 bytes threshold?

Yep confirmed. Adding uniform block members so that the structs grows > 16 bytes changes the behaviour of

sg.Range(fsqParams)

Now the struct is no longer copied, and range pointer points to valid data :/

PS: Windows has the exact same problem in Release mode, but not in Debug mode (compiled with --cc:vcc, others not tested)

PPS: ...aaand it's also broken on macOS when compiling in release mode. The to_Range() converter needs to go :)