Löve Debugger

[DPlayer234]

After working on this utility for a long time and extensively using and extending it myself, I finally decided to share and publish it.

You can find its GitHub repo here.

In a nutshell, it will look about like this when used:

Don't worry, it scales with your font. (So: Larger font => larger text, larger clicking-areas)

While the repo's README describes most if not all of its functions, I will summarize the usage here as well.
Require and call the module, to "inject" love.update, love.draw and several callbacks

Code: Select all

-- Calling the module makes it return itself as well
local debugger = require "debugger" ()
-- You should not change love.update, love.draw or any callbacks after this to avoid the debugger from breaking

If you want to be able to also browse, view and set function upvalues via the environment display, do this after that:

Code: Select all

-- Enable function indexing and nicer names
debugger.allowFunctionIndex(true)

The optional argument (boolean) to this function will enable nicer, more descriptive, but also at first slower "tostring" values for functions if set to 'true'.

You can open and close the Lua prompt and environment by pressing "F4".
Navigate the environment by simply Left-Clicking tables, Shift-Left-Clicking functions (if indexing of them was enabled) or Shift-Right-Clicking variables to open their metatable. Left-Click the top bar to go back.
Right-Clicking any variable or Left-Clicking any non-table variable will copy its name to the prompt.

It will also display framerate, memory used by Lua (collectgarbage "count"), and an estimate of the time taken between the beginning of love.update and the end of love.draw.

Other features should be described in the repo, as I've already mentioned.
If there are any suggestions, well, I think you will know what to do.
Feedback is also appreciated.

Also, yeah, the code is kinda messy. I started this back when I first started using Löve, then continued to expand it and rework some parts as I got more used to it. And if there is one thing it isn't, it's memory or CPU efficient.

[airstruck]

Always interesting to see how library authors handle user input. For anyone else interested, the madness starts around line 228. Feels a bit like a game of "which cup is the ball in." Would really be nice if library authors didn't have to go through this insanity (or subject users to it).