Debugging tool: extremely rudimentary breakpoints

Attached is an example of using an extremely rudimentary function that creates breakpoints.

It has some advantages over other attempts to make breakpoints I found on the forum, including:

  • it’s a one-line call (breakpoint()) that you can easily put anywhere in your code that you want a breakpoint
  • it’s a true breakpoint in the sense that it pauses the draw cycle, instead of just skipping some arbitrary amount of code while the draw cycle still runs

It does have drawbacks too, among which are:

  • You have to have the keyboard showing
  • You can’t actually use the keyboard to query values, just to resume the code running.

In the demo project you can see a blue square moving across the screen and when you enable breakpoints you can make it advance frame by frame.

@dave1707 yeah I know, but I’m not sure there’s much point in that. I tried it with the physics demo project, and it seems like the physics engine is still running in some way even when it’s not updating the screen. Using this technique can make it appear to stop visually, but when you resume, things will be drawn in the positions they’d be in if they’d been moving all along, so even with pause and resume I don’t think it will ever deliver a frame-by-frame experience.

@UberGoober This won’t work for programs that use physics code. You’ll need to add physics.pause and physics.resume.