Official Lua Library Selection

[rude]

Yay! Libraries!

Tido and I briefly discussed "love.net" the other day, until we found this: LuaSocket. I haven't tried it, but it claims to be mature and stable. It's probably best to just include this library instead of making a custom (probably inferior) wrapper around SDL_net.

I also found this, made by the same guy: LuaThread. (Me want real threads ).

The plan is to choose some Lua libraries to be distributed with LÖVE by default.

Does anyone have any experience with these libraries? Feel free to suggest other libraries as well, although I do not guarantee that all will be included. 8-)

So far:

• LuaSocket (Network)
• LuaThread (Threads)

[nathany]

LuaSocket is documented in the official "Programming in Lua" book and is used in various web projects like Kepler, so it's probably a good choice.

Threading isn't an easy concept for new developers, so it's best if you add it on your own if you really want it. Lua has coroutines which are great for gaming, you just need to become familiar with them. I suggest reading this article, though it's on Stackless Python, the concepts apply over:
http://harkal.sylphis3d.com/2005/08/10/ ... ss-python/

Maybe you just need a simple scheduler in your main game loop?

It's unlikely that a 2d game needs to support multi-core, and even if so, it would make more sense to offload graphics/audio/networking to other threads within the engine, and stick to a single process for scripting. Or... there are other packages for parallelizing Lua across processors that use the share-nothing approach and are therefore easier to manage.

[rude]

Hey, nathany. Thanks for your input.

I want to be able to do things like load and unload images while the game is running (without massive FPS drops), multi-core and all that isn't that important.

it would make more sense to offload graphics/audio/networking to other threads within the engine, and stick to a single process for scripting.

That's true. Maybe we could offload filesystem operations to a separate thread, and then the user could specify blocking/non-blocking file reads:

Code: Select all

img = love.graphics.newImage("chii.png") -- Blocks by default.
img:isLoaded() -- Always true.

img = love.graphics.newImage("chii.png", love.non_block)
img:isLoaded() -- May not be true yet.

[giniu]

Hi, I know one shouldn't revive too old threads, but I decided to undust this one with question - I didn't found it anywhere so I guess it isn't included yet - so - is inclusion of threading still considered, for next love version maybe? Loading in background sounds really fun and useful

[bartbes]

Well, 0.6.0 used to have lanes, but it was killed at the last moment when we found out it wasn't cross-platform.

[giniu]

I see, so is there any current way of doing background loading of images? At least something better than loading the file by bytes inside main loop and when done building image from it?

[bartbes]

That's easy: no.

[bmelts]

I dunno, I've had some success with very basic usage of coroutines. Which aren't really threads, but they do provide a capability for loading things without blocking the main loop.

Although I haven't used them since 0.5.0, so maybe they won't work anymore.

[bartbes]

The thing is, they DO block.

[giniu]

I have done some thinking and I guess file operations would be thing that would be enough for most people that need real threads so - is this a reasonable idea to extend love.filesystem.File with threaded version of read and some isready/getdata functions? This limited thread support for files could be done (I think) with Physfs and SDL_Thread and that's already used (in love.audio as I looked at source) - so would something like that, not requiring any outside library in love or native - be considered portable and love-way enough for inclusion if someone (for example I if I find enough time around end of month) would success with preparing a patch?