can you view IL disassembly instead of decomp?
can you view IL disassembly instead of decomp?
Moh this stack trace is far more helpful
Ngetprocaddress seems to just invoke nuint max
Mwhat is _EIA
Ni assume the ios binding structure
Ni didnt write the bindings
Mright generated code stuff
Nit must not be able to find sdl_getplatform
Nyou would think it would with everything i have linked
Mi don't know why, but i guess so
Mmaybe it's not linking anything at all
Ncertainly possible
Mi imagine by the call to GetApi at least the module is loaded
Pcan you do
var ctx = Sdl.CreateDefaultContext()
var sdl = new Sdl(ctx)
var ctx = Sdl.CreateDefaultContext()
var sdl = new Sdl(ctx)
Pand lmk what ctx is
Pand possibly call a few GetProcAddresses on ctx yourself
Nlike this?
Pyep
Njust... pauses
Pctx.GetProcAddress(“SDL_GetPlatform”)?
N?????
Plolwat
Nrestarting, gonna try that again
Nim so confused
Ni assume it throws some kind of exception and aborts evaluation
Pmaybe cast it to nint
Nsame thing
PUgh
PI guess use actual code instead of the debugger then
Nfails to even do that
Pand inspect it that way
Lx
Ncrashes at string.Empty
Nsame thing
Nyou would think it returns 0x0
Puhhhhhh
N...or i guess throw an exception
Nim going to take a break from working on this, it is driving me up the wall in a manner of speaking
Napologies for my scatterbrained debugging process
Pthe segfault is probably the exception
Ptry TryGetProcAddress
Pwhen you get back to it 
DI guess no C# ones then?
Lif you need that kind of reflection, use SPIRV, not WGSL
PTry rust. Rust is fun.
PBut no, no C# ones right now
Pwe have SPIRV-Reflect but obviously that doesn’t help you for WGSL
Pyou’d still need to use naga to translate to SPIR-V
Lid reccomend just writing your shaders in some other language and directly feeding wgpu-native SPIRV, since theres nothing in C# right now for relecting wgsl
DIn WebGPU the delegates have kind of terrible parameter names. i.e. arg0, arg1. I was looking at some header file https://github.com/webgpu-native/webgpu-headers/blob/main/webgpu.h. The parameters in function pointer definitions seem to have good names. i.e.
Are the headers Silk using different? Or the cause of the current name due to some other reason?
Are the headers Silk using different? Or the cause of the current name due to some other reason?