LÖVE

Is there any way I can restart stopped thread? I can't seem to start it again once it's returned, and if I kill it, it obviously won't work either.

My problem is that I want a resource loader thread running separately, so that during loading main loop would poll it time to time to check on progress, and having loading resources without blocking the game display update and input. The idea there is to stop thread once it's no longer needed and start it again when it's needed again.

Keep the worker thread alive. When there is no work to do simply wait for the next message. With Love .80 you'll want to use thread.demand(). For thread shut down, ie when the game is done, simply send a "kill thread" message which terminates the loop.
Pseudocode:

raidho36 wrote:loading resources

How do you intend to pass these loaded resources from one thread to another?

Azhukar wrote:How do you intend to pass these loaded resources from one thread to another?

In 0.8.0, with some combination of [wiki]Thread:demand[/wiki], [wiki]Thread:set[/wiki], [wiki]Thread:peek[/wiki] and [wiki]Thread:get[/wiki].
In 0.9.0, with a Channel.

You can load ImageData in a separate thread and send it to the main thread to be loaded into a love.graphics image, but you cannot load a love.graphics image directly in a thread other than the one which created your window.
SoundData/Sources don't have this restriction.

In 0.9.0 you'll be able to use DXT compressed textures, which can be an order of magnitude faster to load compared to regular png/jpg (and take up way less RAM/VRAM, and have better performance when drawing.)

And they look like crap. It's absolutely forbidden to use them with either gradient-smooth or vector-sharp textures, because it will put noticeable distortion, and people will notice. Look what it does to textures. And that's DXT5, gives best possible picture.

raidho36 wrote:And they look like crap. It's absolutely forbidden to use them with either gradient-smooth or vector-sharp textures, because it will put noticeable distortion, and people will notice. Look what it does to textures. And that's DXT5.

You're right that it definitely depends on the source image. Though by using a good compressor you'll get much better results (still probably not good enough for images with obvious gradients). A lot of the worst example images out there are the result of a sub-par realtime compressor.

True, but the algorightm itslef hates smooth and sharp images. It'll work best with naturally noisy and plain lit images, like flat concrete texture.

DXT compression is used in nearly every AAA game. Take that as you will.

DXT obviously isn't perfect (and there are a couple much higher quality alternatives/replacements, but sadly they only work on DX10/GL3 and DX11/GL4 hardware.)
I have personally never seen a DXT compressed image with anywhere close to that amount of compression artifacts. Do you have the original source image handy?

Because it saves memory, and AAA games just always need more memory, it's never enough. If you will to spare image quality over textures volume then using it is fine, provided it naturally harder to spot such defects on rapidly moving and constantly transforming surfaces as model polygons. Even if they are static, they're twisted all the way around, also highlighted properly and would also have bump maps on them which increases lighting effect, all that would additionally hide defects from user. But 2D games won't have any of that but rapid movement, and any such defect is easily noticeable. Also, rendering performance gain is pretty much minimum, if any.

I think the best way to employ them is to 1) expose DXT-compressed textures handling functions to user, in addition to regular textures, and 2) have tools for dynamic DXT compression of regular textures, once again by user demand. I wouldn't like if löve2d screwed up my sprites because it thinks it's more effective that way.