love-loader: load resources in a separate thread, easily

[kikito]

Hello people!

I'm releasing a new library today.

As the title says, its purpose is being able to load resources in a secondary thread, so the primary thread doesn't get blocked.

The lib can be found on github:

https://github.com/kikito/love-loader

The best thing is that it doesn't really require much overhead to work; and the thread is completely managed by the lib. You only specify which images and sounds to load, launch the lib with start, and have a callback when it's done!

There is some documentation on how to use it on the github page, and I have also prepared a demo (fixed now - thanks, Boolsheet!)

Thanks, and good night!

Edit: Adding explanation for MarekkPie

The problem it solves is that loading resources "the usual way" (with direct calls to love.audio.newSource, for example) is blocking. This means that nothing gets done until the file is loaded; in effect, the program "pauses".

On the demo there is a spiral spinning around. It spins a little bit every dt. In the background, I load the same image 50 times, plus an .ogg ; but the spinning of the spiral is fluid and unaffected. Had I loaded the files in the main thread, the fps would have dropped and the movement would have been "jerky".

The use case is basically that: you want fluidness while you are loading things from the hard drive. The typical case is when you have a .love with lots of resources, and you want to play an animation while they load. Loading stuff while showing the menu didn't occur to me, but it's also a great idea.

Edit2: The demo now works, and the song license file is more clearly identified as a license file.
Edit3: Updated demo to v1.1.0
Edit4: Added demo for v2.0.0 / LÖVE 0.9.0

[Taehl]

Very awesome idea. I'll give it a try if I ever end up making a game which takes more than one second to load, or has a lot of content to swap out mid-play. As for your uncompressed folder thing, I don't know, that's very strange.

[MarekkPie]

I'm sure there is one, but what would be the point of this? The only example I can think of is maybe something like a light/dark world that changes on the fly, and for whatever reason you didn't want to load all the assets at the beginning of the level/play state, but you also didn't want to stop gameplay. (I haven't messed with multi-threading at all, so maybe there's something inherent in that which provides this it's benefit).

Hopefully I am not sounding confrontational. I'm just generally interested/confused.

[tentus]

I'm sure there is one, but what would be the point of this?

A lot of Love games (take In The Dark as an example) have a ton of images for art assets. You don't want to load them as needed (multiple 512x512 images is a lot of images to load between frames), but you also don't want to wait for them all to load before starting the level. Hence, threaded loading.

Kikito: brilliant. Once I actually have art to load, this is totally going in my next game.

[MarekkPie]

But wouldn't the game still need to wait for the second thread the load the image before it can access it in the first thread? Are you needing to preemptively load the images at some time p-t, where p is the point in time when you need access to the image and t is the time it takes to load?

A more concrete example: I have a player who is walking to the edge of one of your 512x512 map plates. I need to have the image loaded by the time the player reaches the edge, so the illusion isn't broken. So I would need to program in some logic that says "if I am within n pixels of the edge, begin loading."

So it seems this is more for really big to pseudo-infinite worlds (or like you said tentus, for something with gobs and gobs of art assets); for most practical purposes this might be unnecessary. I am right on that?

[utunnels]

Ah great. I had been considering a resource loader but got stuck because it told me the model love.graphics was not available. I wonder how it gets done (I'm still new to lua).

But wouldn't the game still need to wait for the second thread the load the image before it can access it in the first thread?

Maybe you can buffer adjacent plates once you are in one of them. Though it depends on how much memory you plan to use.

[Boolsheet]

I think the 'if' statement in killThreadIfDone is the culprit. It probably should also check if resourceBeingLoaded is nil.

Code: Select all

if #pending == 0 and not resourceBeingLoaded then

[tentus]

But wouldn't the game still need to wait for the second thread the load the image before it can access it in the first thread?

Yes, but the point is that you can start doing stuff before you have everything loaded. Imagine a level that has 100 512x512 images in it, presumably in a predictable sequence. You may not let the player start playing until a full 25% of those are loaded, but that's still a 75% shorter level load time, for minimal effort.

Alternatively, this could be used to load common assets during a menu... imagine that your game avatar has a lot of images. You could start loading them while the player navigates the menu, without getting into hairy spare-frames statements.

[MarekkPie]

Maybe you can buffer adjacent plates once you are in one of them. Though it depends on how much memory you plan to use.

All that does is push the issue one plate over.

Yes, but the point is that you can start doing stuff before you have everything loaded. Imagine a level that has 100 512x512 images in it, presumably in a predictable sequence. You may not let the player start playing until a full 25% of those are loaded, but that's still a 75% shorter level load time, for minimal effort.

Alternatively, this could be used to load common assets during a menu... imagine that your game avatar has a lot of images. You could start loading them while the player navigates the menu, without getting into hairy spare-frames statements.

Alright, I gotcha.

[slime]

Notice how you can't click the cancel button most of the time when loading TF2 maps? That's because it blocks the main thread completely when doing so. Obviously it's not as much of an issue in 2D games usually, but it's still useful.

I think you could make this forward-compatible with 0.8.0 pretty easily by either defining the send and receive methods as set and get if they don't exist, or doing if-checks in the places where you send and receive (like: if mythread.get then mythread:get("blah") else mythread:receive("blah") end, or whatever).