floooh / sokol

minimal cross-platform standalone C headers
https://floooh.github.io/sokol-html5
zlib License
6.55k stars 469 forks source link

Suggestion: Show labels in validation errors #950

Open comblock opened 7 months ago

comblock commented 7 months ago

Currently the validation errors don't show any labels (or at least, I haven't seen any appear), I think showing the labels would be incredibly helpful for debugging and I don't see any good reason not to. Right now you might get a message like this:

[sg][error][id:240] libs/sokol/sokol_gfx.h:16295:0: 
        VALIDATE_ABND_FS_EXPECTED_SAMPLER_BINDING: sg_apply_bindings: sampler binding on fragment stage is missing or the sampler handle is invalid

meaning you first have to figure out which binding is causing the error.

floooh commented 7 months ago

Yeah, the log messages are currently fairly restricted because I didn't want to have the size overhead of printf in the standard logging solution, so there's no "straightforward" formatted printing.

In some cases I use a workaround though where I fire two log messages, where the second one uses a custom message, like here for the shader compilation errors:

https://github.com/floooh/sokol/blob/c08a34d092ed76429df232d9861e74268239629c/sokol_gfx.h#L7990-L7991

...something like this might also work for additional information like labels.

Currently the recommended workflow is to find the logging location in the code (e.g. in this case: libs/sokol/sokol_gfx.h:16295:0) and set a debugger breakpoint there to figure out what caused the problem.

comblock commented 7 months ago

I understand not wanting the overhead of printf, but a solution to this could be adding a macro (something like SOKOL_DEBUG) to enable/disable printf logging. You could also not use printf, but first print the message, then the label, and then the rest of the message (if it wouldn't make sense for the label to be put at the end of the message) I realise both of these approaches don't work well (or at all) with the current _sg_log function/function pointer, so it might not be worth the effort ¯\(ツ)/¯.