LÖVE

So, this thing is awesome for prototyping, and normally a few odd crashes here and there wouldn't be a big deal, but the more I get into this and want to do more cool shit, the more I wonder about debugging tips?

So for instance, I have a little sandbox running with some Box2D stuff going on, and pretty randomly I get a crash where the thing just exits - no warning - so it's hard to breakpoint with the debug() command.

I'd love to build it from source (and maybe even contribute), but on Windows at least, I just got mired in dependency hell and gave up. Anyway, any love experts out there want to share some tips on how to debug apps without prints - or anything to do in the case of big crashes?

A debug version of love.exe with symbols would be almost as good as debugging from source since you could attach and just catch the crash and have a clue as to what is dying.

Anyway, I'm sure it's something I'm doing that's stupid but I am at a total loss as to what it is without any debugging ability!

Love the love though! So fast!

You have a lot of questions here, perhaps someone can help you if you ask one at a time?

Haha, fair enough. Yeah, I guess basically, I'd love to be able to debug crashes inside the love.exe is what it comes down to. And I guess that basically means I have to compile love from source.

So I guess after looking into it, really my question is, anyone have any helpful tips for compiling Love from source on windows?

rawktron wrote:Haha, fair enough. Yeah, I guess basically, I'd love to be able to debug crashes inside the love.exe is what it comes down to. And I guess that basically means I have to compile love from source.

Well, the console provides a traceback when something goes wrong, and if you want, you can change love.errhand(ler?) so it calls debug.debug().

But for both of these things you need the console, and on windows (which really is a crappy platform for developers) you need to activate the console, either by giving the argument --console to love.exe or by adding t.console = true in your conf.lua.

So tempting to insult Windows, but I've learned from my mistakes.

I recommend --console because you'll see fatal messages always. t.console will have the console when LÖVE dies, IIRC.

That is wrong.

Thanks for the all the tips guys - great stuff as I wasn't aware of the console, or conf.lua. Very useful to be able to see output from errors etc.

Although the crash I'm getting (which I'm pretty sure is physics related) is taking the whole thing down. Console and all. It's probably some value out of range thing, BUT, it'd be nice to not have to guess randomly at what it is and just be able to see it in the debugger.

I know windows is unpopular, but is there a list of the required dependencies and where they go for building from source? (I grabbing the include folder from lua and SDL,but afterwards there were still a tonne of missing headers that weren't immediately obvious what package they were from).

thx again.

Btw, I gave compiling it on Windows another go - got further this time. 8 of the 17 projects compiled. And not that many compile errors left.

A sampling of the errors:
That one is because the array g is being indexed with 'length' which is not defined, and isn't a parameter in that version of the function. It is in the 3 parameter version. Tried adding it but it breaks other versions of the function. Figured I shouldn't mess with it too much.
I just made the member public. But not sure why it's private to begin with when it is accessed as body->world all over the place.

Imagefont.cpp and TrueType.cpp are also in the project files but weren't in the source dump I got from bitbucket. Removing them got me a bit further, but not really sure if those are needed or just old.

Getting closer!