General discussion about LÖVE, Lua, game development, puns, and unicorns.
8 posts • Page 1 of 1
According to the wiki, love.graphics isn't usable from a thread. However, I've found that there's nothing stopping you from requiring the graphics module and calling functions from it. Can I assume it's safe to use as long as I don't do anything that might cause concurrency issues, like drawing to the screen or modifying graphics objects at the same time other threads do so?
- Party member
- Posts: 3003
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
No, it will most likely either error (hopefully) or crash (hopefully not); it's not about concurrency, rather about the fact that you can only have one thread be a dedicated openGL thread, or something like that.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
This crashes for me with a segfault, despite the extra care taken in not using love.graphics in two threads simultaneously.
Code: Select all
local chan = love.thread.getChannel('chan') local img = love.graphics.newImage('anything.png') local thread = love.thread.newThread('thread.lua') love.graphics.clear() love.run = function() end -- no main loop thread:start() -- calls to love.graphics within the thread start here chan:supply(img) -- pass the image to the thread chan:demand() -- wait for thread to finish love.graphics.present() love.timer.sleep(3)
It's the love.graphics.draw call within the thread that causes the segfault. Without it, it runs without problems, but without drawing anything, of course.
Code: Select all
require 'love.graphics' local chan = love.thread.getChannel('chan') local img = chan:demand() -- get the image love.graphics.draw(img, 0, 0) -- call a love.graphics function chan:push('done') -- we're done - the main thread can use love.graphics again
I was trying to make an animated loading screen, but short of using coroutines and loading in small chunks, which isn't always possible, I don't see how. Even love.graphics.newImage segfaults, therefore a thread can't even load images that way. At best it can load ImageData so that the main thread can use love.graphics.newImage(imageData) when the loading finishes; not sure whether that's costly for a big number of big images, but I suppose it is.
Edit: The segfault happens in libGL.so.1, within glEnableVertexAttribArray().
- Inner party member
- Posts: 3653
- Joined: Mon Jun 22, 2009 9:35 am
- Location: Pennsylvania, USA
Well you'd have to start the new thread and have the main thread wait for the new thread (Which I guess loads everything) to send the "all done!" message back to the main thread. And while you wait you'd draw that loading screen.
The point is that in the thread you can't load images with love.graphics.newImage(). You can load sounds, maps, library files, and so on, but not images, except with love.image.newImageData().
Edit: Also, there's still the problem that the environments are not shared, which makes loading certain kinds of objects more difficult or impossible from a thread. Example of "more difficult": stuff you allocate in FFI memory. You need to use malloc for it to not be garbage-collected, and you need to pass the pointer to the main thread, which isn't exactly a trivial task. Example of "impossible": userdata objects (fortunately it's not likely you need to create one of these that takes long to load).
Users browsing this forum: No registered users and 42 guests