I recently ported love-loader to work with the new thread changes in 0.9.x. I use this library all the time to avoid IO lags in frames from loading assets and it was killing me not to have it working in 0.9.x.
The changes have already been merged into the master branch of the repository and the public API hasn't changed at all so you should be able to just replace the old version if you were already using this in 0.8.x. If you have any suggestions for additional features I'd love to for you to open a github issue for it.
Once again, the URL: https://github.com/kikito/love-loader
Kikito's love-loader for 0.9.x
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: Kikito's love-loader for 0.9.x
I am not sure that calling it "kikito's love-loader" is accurate any more, since you did all the heavy lifting on this version .
Thanks again, and welcome to the forums
Thanks again, and welcome to the forums
When I write def I mean function.
- richardperkins
- Prole
- Posts: 9
- Joined: Tue Jan 07, 2014 6:20 am
Re: Kikito's love-loader for 0.9.x
This is pretty great stuff! Thanks. I was working on something similar, but there is no need to reinvent the wheel
Re: Kikito's love-loader for 0.9.x
To even further simplify its use: here is some code that will recursively preload all the images in the "images" directory.
Code: Select all
local loader = require 'lib/love-loader'
local preloaded_images = {}
local preloaded_fonts = {}
-- puts loaded images into the preloaded_images hash with they key being the file name
local filetypes = {png = true, gif = true, jpg = true}
local function load_images(container, directory)
for index, file_name in ipairs(love.filesystem.getDirectoryItems(directory)) do
-- build the full, relative path of the file
local full_name = directory .. '/' .. file_name
if love.filesystem.isDirectory(full_name) then
-- recurse
local subcontainer = {}
container[file_name] = subcontainer
load_images(subcontainer, full_name)
else
-- match the filetype and then queue the image for loading
local file_name, filetype = full_name:match("^.*/(.+)%.(%a+)$")
if filetypes[filetype] then
local key = file_name .. "." .. filetype
loader.newImage(container, key, full_name)
end
end
end
end
load_images(preloaded_images, "images")
Re: Kikito's love-loader for 0.9.x
I may found a problem when finishCallback is called twice.
problem is also discussed here.
http://love2d.org/forums/viewtopic.php? ... 4&start=30
Machine:
Windows 7, 64bit, Core i7-3770
Most times I get:
But this is wrong. "second tween finished" should only called once. It seems, that when there is load on the cpu, everything is correct. But when there is no load, the finishCallback is called twice.
Sample attached.
problem is also discussed here.
http://love2d.org/forums/viewtopic.php? ... 4&start=30
Machine:
Windows 7, 64bit, Core i7-3770
Most times I get:
Code: Select all
first tween finished
second tween finished
second tween finished
Sample attached.
- Attachments
-
- oncomplete3.love
- (19.24 KiB) Downloaded 128 times
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: Kikito's love-loader for 0.9.x
Hi Science,
I have executed your examples many times (around 10 or so) and could not replicate this - I always get only 1 "second tween finished".
However, I've studied the code and I imagined a case where there could indeed be a multi-threading related issue - I made a change that should fix it (theoretically, as I said before my machine never fails with your code). Instead of using a variable, the "endThread" function actually waits for the thread to finish before continuing, using an extra channel.
Could you please try this and tell me if this solves your issue? If so, I will deploy the change to love-loader.
Regards!
I have executed your examples many times (around 10 or so) and could not replicate this - I always get only 1 "second tween finished".
However, I've studied the code and I imagined a case where there could indeed be a multi-threading related issue - I made a change that should fix it (theoretically, as I said before my machine never fails with your code). Instead of using a variable, the "endThread" function actually waits for the thread to finish before continuing, using an extra channel.
Could you please try this and tell me if this solves your issue? If so, I will deploy the change to love-loader.
Regards!
- Attachments
-
- oncomplete4.love
- (20.11 KiB) Downloaded 126 times
When I write def I mean function.
Re: Kikito's love-loader for 0.9.x
Nope does not work. Screenshot attached.
I made a small fix and send you a pull request on github. It's only a hack but this works.
I made a small fix and send you a pull request on github. It's only a hack but this works.
- Zilarrezko
- Party member
- Posts: 345
- Joined: Mon Dec 10, 2012 5:50 am
- Location: Oregon
Re: Kikito's love-loader for 0.9.x
What does this do?
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: Kikito's love-loader for 0.9.x
Yes, I saw it. I am not going to merge it just yet. I need to understand why it happens so I can fix the real problem, not mask it. This is difficult for me since I can't reproduce the issue.SiENcE wrote:I made a small fix and send you a pull request on github. It's only a hack but this works.
But in the meantime, use it if it fixes your issue.
It allows loading stuff on a secondary thread without blocking. This means that the man thread can display a fluid "loading animation", while loading takes place, for example. Unfortunately Science has found a bug and I am trying to find the issue. But it only seems to happen on his machine, so it's difficult.Zilarrezko wrote:What does this do?
More info on its thread: http://love2d.org/forums/viewtopic.php?f=5&t=7721
When I write def I mean function.
- Zilarrezko
- Party member
- Posts: 345
- Joined: Mon Dec 10, 2012 5:50 am
- Location: Oregon
Re: Kikito's love-loader for 0.9.x
alright, cool.
Who is online
Users browsing this forum: Ahrefs [Bot] and 0 guests