Asynchronous resource loading

[bartbes]

No, we went for magic unicorns who transport the data between the threads.. to do so we did have to create a rainbow between the threads.

Seriously, all data passing is done via a messaging system implemented in C++. Btw, how dare you doubt my work?

[leiradel]

Seriously, all data passing is done via a messaging system implemented in C++.

Ah, there had to be some way. But will it be possible to pass tables and userdata via the messaging system?

Btw, how dare you doubt my work?

Sorry, I'll create an OBEY avatar to remember me never doing that again

[bartbes]

There are some restrictions, like tables.
I'll quote something from the 'design doc'

-- These values are copied: booleans, numbers, string and full/light userdata.

EDIT: I would like to add that although functions aren't directly supported lua provides some excellent functionality, take a look at string.dump.

[giniu]

If you'd like to actually try out the experimental thread support, you'll need to install Mercurial in order to download the bleeding-edge source for LÖVE - SourceForge doesn't, as far as I know, offer a "download files" button. Once downloaded, just run hg clone http://love.hg.sourceforge.net:8000/hgroot/love/love in whatever directory you'd like to put the love folder in. From there, build as appropriate for your system; it comes with Visual Studio and Xcode projects for Windows/Mac, or if you're building on Linux, just cd to the root of the love folder and run sh platform/unix/automagic. However you choose, you'll eventually end up with an executable of the bleeding-edge of LÖVE, and can mess around with love.thread to see if it fits the bill.

or if you happen to use Arch Linux, you can use

Code: Select all

yaourt -S love-hg

to get latest version in one line - executable is then relocated to love-hg so you can have love-05, love and love-hg in one system - just thought I will mention it so someone can save typing if he uses Arch

[rude]

Ah yes, love.thread ... not quite ready, but promising. I miss the asynchronous functionality too. The reason I wanted love.thread in the first place was specifically async resource loading (though it can obviously be used for much more). It is possible to load OpenGL textures to the GPU asynchronously, and if so, we have to do it. (It is not possible to draw things asynchronously, however).

[leiradel]

It is possible to load OpenGL textures to the GPU asynchronously, and if so, we have to do it. (It is not possible to draw things asynchronously, however).

Hum... I researched this quite a bit when I was implementing it in my engine, and I don't think asynchronously uploading textures to the GPU is possible unless one uses pixel buffers which is not well supported on old hardware. LÖVE, being a hardware accelerated 2D engine, is suitable for casual games which often run on old hardware.

My solution was to break the texture into smaller squares (I used 128x128 I think) and upload one piece per frame. The conversion from image (I used SDL_Surface) to texture in main RAM was asynchronous, and after that the main loop would upload the pieces.

I can dig the code if you guys are interested.

Cheers,

Andre

[rude]

Ok, then I'm misinformed. I've never actually tried it.

[ljdp]

Does the threads module work at all?
I poked at the source and found newThread, looks like it takes a filepath as its 2nd argument?
I presume as an external function?
Anyway calling love.thread.newThread( 'threadname', 'thread.lua' ) throws a "Incorrect parameter type: expected userdata", I assume that's because it calls love.filesystem.read, which returns a string?

EDIT:
Managed to get it working by passing the return value from newFileData

Code: Select all

file = love.filesystem.newFileData( 'file.lua' )
thread = love.thread.newThread( 'threadname', file )

Any info on how these threads work?