Hacker News Reader

Comment by skywal_l | Hacker News Reader

How do you write all this with almost no way to debug anything in webgl?

I work largely with shaders and I often debug things by encoding debug information into r, g, b. Though I can't encode very much at a time because I'm colour blind (deuteranomaly) so I usually try to avoid using both the r and g channel.

But most of the time it's more a matter of thinking things through an extra time rather than poring over debug prints.

When thinking things through and drawing debug info as colours both fail I usually load up a graphics debugger such as RenderDoc. You might think that wasn't an option here, but if I were to develop something this intricate for Shadertoy I'd definitely develop it as a standalone app in regular OpenGL first and then port it.

That is my approach as well, or using native tools like GeekXLab (https://geeks3d.com/geexlab).

Unfortunely good debuging tools for 3D Web API isn't a priority even after 10 years, and same applies to WebGPU roadmap.

Luckily for me I work exclusively with game development for PC and consoles. The console manufacturers have their own platform specific debugging tools, for PC there's Nvidia NSight and RenderDoc. Also, I mainly work with Unity these days and for many simpler tasks their own debugging and profiling tools are quite sufficient.

Maybe they started with the text printing routines and from there on it's just printf debugging right? :-)

Btw you'll enjoy learning that lots of microchip / embedded programming happens on chips that don't have printf at all (even when connected to a computer) and also no debugging capabilities. People tend to connect a LED to an unused pin for some 1-bit printf debugging and that's all you got.

I don't think I've ever used a debugger for anything. I just print the values to the screen. I don't even know why people need debuggers, when just outputting relevant values is so much more straight forward.

Because you can not only inspect the relevant values, but also the whole call stack to see how the erroneous value was generated. You can step through the program to see what path control followed and quickly work out what’s causing yous problem.

I mostly use browser debuggers and even then I only use a small fraction of their capabilities, but honestly they are just more effective that printing values.

To add to this: not only does it allow you to step through and follow the control flow of a program. In some hairy cases there are issues which are very difficult to answer with printf debugging.

Let's say a variable is being overwritten and you can't figure out why. It could be some dark corner of the code you missed or it could even be memory corruption. A debugger will let you put a conditional breakpoint on that memory address being written, which will then give you all the context needed to see what's going on. This has helped me solve quite a few really tricky bugs.

There's also the simple case of debugging a tricky crash. Before learning to use a debugger (some twenty years ago) I had to do printf with all kinds of local variables guessing at what might be the cause. Attaching a debugger you mostly just run the program, it gets an access violation, and the debugger breaks showing you the generated exception, the stack, the exact statement which caused the crash (though this mostly requires debugging with optimizations turned off), and you can just hover over any variable to check their values. Most crash bugs which would have been very tricky with printf now take seconds to diagnose because you have the full context of the program just as it was when it crashed, right at your fingertips.

Since this is a comment on a shader program there's also the matter of GPU debuggers which I just have to mention in order to say: you can't really do typical printf debugging for most shaders and graphics debuggers are like magic.

Oh, ho ho ho manical laughter. It is true that outputting relevant values is much more straight, but the power of a debugger; using the call stack, conditional breakpoints, value inspection is transcendental..

Using the debugger is a skill. Don't knock it till you try it.

Especially when you have a debugger that lets you step backwards!

https://en.wikipedia.org/wiki/Time_travel_debugging

I never needed any of that and I'm an assembly programmer for 35+ years.

Pascal, x86 assembly, arm assembly, Python ... and sometimes even a mix of them running together.

How would you debug a program that you don't have source code access to? Or even a program that has a fairly long compile/link cycle?

I don't debug programs that aren't mine.

Why would you even ask?

If you have an LED, you have a UART Tx. Why not use it for that instead?

Because when you're doing 'wiggle a pin' debugging you're generally in very very early boot where clock/pll configuration can easily be one of your problems.

You do a native implementation using good debuging tools like Renderdoc and only port to WebGL as last step.

Reply on news.ycombinator.com