Page 2 of 2
Re: Asynchronous resource loading
Posted: Thu Mar 18, 2010 6:02 pm
by 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?
Re: Asynchronous resource loading
Posted: Thu Mar 18, 2010 6:32 pm
by leiradel
bartbes wrote: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?
bartbes wrote:Btw, how dare you doubt my work?
Sorry, I'll create an OBEY avatar to remember me never doing that again
Re: Asynchronous resource loading
Posted: Thu Mar 18, 2010 7:09 pm
by 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.
Re: Asynchronous resource loading
Posted: Thu Mar 18, 2010 10:15 pm
by giniu
anjo wrote: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
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
Re: Asynchronous resource loading
Posted: Fri Mar 19, 2010 8:56 am
by 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).
Re: Asynchronous resource loading
Posted: Fri Mar 19, 2010 1:05 pm
by leiradel
rude wrote: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
Re: Asynchronous resource loading
Posted: Fri Mar 19, 2010 5:47 pm
by rude
Ok, then I'm misinformed. I've never actually tried it.
Re: Asynchronous resource loading
Posted: Sat Mar 27, 2010 3:57 am
by 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?