A Few Questions on Love and Lua

[NykolaR]

Hi all, new here, though I've lurked and been doing some work with Love and Lua for the past few months. I've stumbled upon a few questions over this time, with limited success searching for answers.


Love Question (On image rendering and coordinate systems):

In my game, I'm using a coordinate system that goes from (0,0) to (32, 18) rather than to the screen size. However, when I draw an image, it is drawn so a single pixel takes up (1, 1) units of the screen.
So, when I'm drawing a 32x32 quad, at 1x scale it covers more than the entire screen, so I have to scale it by 1/32. Is there a way to set the default scaling to 1/32 size (so that a 32x32 image at default scale will draw to a 1x1 scale in the coordinate system?). I don't think this is critically important, but it sure would help readability and clarity if I wasn't constantly scaling things by their inverse, haha.
I haven't worked with the Love SpriteBatch yet though I'm planning on implementing it later, so apologies if this works different than the "draw" call and is related to an answer.


Lua/Love Question (On debugging/performance testing and analysis):

Are there any generally useful debugging/analysis programs for Love/Lua?

• Debugging - perhaps something window based running [along] the Love file, showing a Tree of currently used variables and their values?
• Analysis like something that plots memory usage VS time, records garbage dumps, etc. I've used tools like this that interacted with the Java VM, but I couldn't find anything similar for Lua. Not sure if I was looking in the wrong places, or if they don't exist.

Lua Question (On [Lua/LuaJIT/FFI C binding]/Performance):

In an algorithm, is it bad practice/slow to use tables rather than a basic data type? And above this, for critical/heavy algorithms, is it even faster to use C through FFI rather than Lua? Does this complicate the packaging process or change which hardware it can run on? I looked on the LuaJIT FFI section and it says it's faster, more lightweight, and (should?) run on any hardware LuaJIT runs on, but if someone has real experience with it a second opinion would be nice.



If it changes any of the answers, I'm currently running the most recent Love, on Linux Lubuntu 16.10. Thanks a lot in advance, and I'm excited to join this community!

[ivan]

Are there any generally useful debugging/analysis programs for Love/Lua?

For debugging, I use strict.lua. It throws an exception whenever you try to access an "undeclared" global variable.
The only problem with strict.lua is that it only catches these errors when the code block is executed so it doesn't work statically.

Although it's technically possible, I don't think it would be very useful to see a dump of the Lua environment.
I remember Decoda had something similar including breakpoints, etc but I never had the patience to use it.

For profiling, I'm going to plug my own tool:
viewtopic.php?f=5&t=80759
But to be honest, optimizing games is not "what's the fastest/most optimized way to do this",
it's usually more like "let's find a way to run this piece of code less often".

It's not bad practice to use tables - tables are quite fast,
just try to avoid a lot of intermediate tables (creating/destroying tables all the time)
since that can be a strain on the garbage collector.

So while C is faster than Lua, there is a slight overhead when you call C functions from Lua
so a C function that you call all the time is not ideal.
In short, if you want a fast-running game, then you have to run less code.

[raidho36]

In short, if you want a fast-running game, then you have to run less code.

That would be "less computations". Just because it's short doesn't mean it's fast.

[easy82]

Hello and Welcome!

I use ZeroBrane Sudio which has a built-in debugger, autocompletion for Love2D, etc. Check it out: https://studio.zerobrane.com/
To enable debugging you have to add 1 line of code to your project: http://notebook.kulchenko.com/zerobrane ... -debugging
I also use strict.lua, but ZeroBrane has an Analyze option that does static analysis on your code, pretty useful.

[zorg]

For scaling, if i read your issue correctly, you can call [wiki]love.graphics.scale[/wiki] once, then do stuff, and it should work. (for extra safety, you can do this in an lg.push/pop block too.

Table access is just a bit slower than direct variable access only if you're doing something like a.b.c[d].e[f][g[h]].i ...or in other words, accessing a flat table should be almost as fast as accessing any other type of variable. I might be wrong on whether it'd take substantially more time or not, when accessing such a monster as above though.

Also, if the variables are kept close to the scope you're currently in, variable access gets faster (and contrarywise, the further from the local scope you go, lua has to jump hoops to load values into its internal registers, slowing things down), but again, without benchmarking, you can't be sure what would slow down a piece of code, and how much.

Most people are sated enough by a simple big (1mil/10k, depending on circumstances) loop on an offending piece of code, wrapped by love.timer.getTime or os.clock, to see what solution would be faster.

As for realtime analysis, you can get some stats from within love/lua, so it shouldn't be hard storing and visualizing that data, if you want/need to;
- Used memory: collectgarbage("count") (Note that this only counts lua-side stuff, not what löve has on C side, like its own Object hierarchy)
- Graphical stuff: [wiki]love.graphics.getStats[/wiki] (drawcalls, canvas switches, texture memory, canvas count, font count, shader switches)

[NykolaR]

For debugging, I use strict.lua. It throws an exception whenever you try to access an "undeclared" global variable.

For profiling, I'm going to plug my own tool:
viewtopic.php?f=5&t=80759
But to be honest [...] run less code.

I'll check out strict.lua & your profiling tool. And of course, an efficient algorithm & implementation is always step 1 (and 99% of the time runs good enough, I'm just a bit OCD on performance). I'll probably stick to no C code, and try to optimize for little GC. Thanks for the insight!

Hello and Welcome!

I use ZeroBrane Sudio [...]
I also use strict.lua, but ZeroBrane has an Analyze option that does static analysis on your code, pretty useful.

I've heard of ZeroBrane! I never thoroughly looked into it because I'm a bit of a Vim addict, but I'll check it out for it's analysis options! Thanks!

For scaling, if i read your issue correctly, you can call [wiki]love.graphics.scale[/wiki] once, then do stuff, and it should work. (for extra safety, you can do this in an lg.push/pop block too).

Yup, I push / scale / pop for my rendering phase. I think Love is working as intended, it just isn't doing what I want in my specific case. I've thought of a solution that will hopefully work, if not I'll probably be back to the drawing board.

Table access [...]though.

I try to keep my tables flat and keep my scoping as tight as possible, so I'm probably fine. I suppose it's more a worry of how much garbage they make if they're being declared locally per frame (if they're put on stack/in registers or some random memory location), but I think I can work this out using something you said further down.

Most people are sated enough by a simple big (1mil/10k, depending on circumstances) loop on an offending piece of code, wrapped by love.timer.getTime or os.clock, to see what solution would be faster.

As for realtime analysis [...]

This actually gave me a pretty good idea on writing an analysis/debug helper file to do some real time code snippet analysis. Thank you!

[Positive07]

I also recommend to use something like luacheck, lualint or luaparse in your editor through some kind of linting plugin, this will tell you about errors in your code and bad patterns while you are coding.

I also like hot reloading and the best I have found is probably Lume+Lurker

I also redirect console output to my editor and have some tracing command that allows me to jump to the lint where each print statement was called (Lume has a tracing utility)

About FFI vs C, when JIT is enabled FFI is faster because calling from Lua to C to Lua has some overhead, while FFI is compiled with the Lua code so they are at the same level (ultra simplified explanation, look it up if you want to learn more about FFI and JIT).
When JIT is diabled (which is most likely the case in mobile) FFI is way slower than C bindings so be careful.

For scaling, yeah, you should check [wiki]love.graphics.scale[/wiki]

[wiki]SpriteBatch[/wiki]es are pretty much an [wiki]Image[/wiki] with a collection of [wiki]Quad[/wiki]s, you then give all your draw operations that you wanna do with that image and those quads to the [wiki]SpriteBatch[/wiki] and groups all this draw operations into a single draw operation (again, ultra simplified explanation)

[SiENcE]

Hey,

Are there any generally useful debugging/analysis programs for Love/Lua?
Debugging - perhaps something window based running [along] the Love file, showing a Tree of currently used variables and their values?
Analysis like something that plots memory usage VS time, records garbage dumps, etc. I've used tools like this that interacted with the Java VM, but I couldn't find anything similar for Lua. Not sure if I was looking in the wrong places, or if they don't exist.

I recommned Babelua for Debugging Lua/Löve. It's the most robust debugger for lua and works without adding anything to your sourcecode.

While "ZeroBrane Sudio" is nice, it needs to embed code into your sources and is not that stable.

cheers

[Zireael]

Babelua looks like a VS addon, though. How is the performance while debugging (since VS is a memory hog?)

[paulclinger]

While "ZeroBrane Sudio" is nice, it needs to embed code into your sources and is not that stable.

@SiENcE, adding one line is usually not a problem when the user is working on its own code, but you do need to add it to start debugging. Also, I'm not aware of any stability issues other than one specific case on OSX for which there is already a ticket. Do you have an example when it's not stable that I can investigate? Thanks. Paul.