LÖVE

I wonder whether using S3TC is a good idea. It might restrict the portability of your game.
The problem is that this stuff is still patent encumbered. On Linux and possibly other systems it might therefor not be available. I know that it is not available by default on Linux with Intel graphics, it might be different for the proprietary ATI/NVIDIA drivers.
It is also a lossy format and not suitable for some kinds of graphics.

Is it really incompatible with some system ? Even if I load it throught LÖVE ?

murks wrote:I wonder whether using S3TC is a good idea. It might restrict the portability of your game.
The problem is that this stuff is still patent encumbered. On Linux and possibly other systems it might therefor not be available. I know that it is not available by default on Linux with Intel graphics, it might be different for the proprietary ATI/NVIDIA drivers.

Here's a table showing support for S3TC/DXT collected by a game that has a disproportionately large Linux userbase: http://feedback.wildfiregames.com/repor ... ssion_s3tc

Don't worry about portability on desktops, all GPUs support it, all drivers on OS X / Windows support it, all proprietary drivers on Linux support it, and most/all open-source drivers on Linux support it. The handful of Linux systems that don't support it out-of-the-box can either set 'force_s3tc_enable=true' to enable it, or they can get the 'libtxc-dxtn' package which gives them support.

Since I have to clear/re-add sprites to spritebatches quite often, can someone provide an example on how to add a sprite to a spritebatch via FFI if it's possible?

Having to clear 32 spritebatches (on a 1680x1050 res) and re-add 8192 sprites once the lighting changes is way too many C func calls and makes a slight stutter.

Is there any way to draw lines like these:

I once saw a lib here that did this but I can't remember it's name.

If it is just about finding the screen coordinates of the end points of these lines, then this is not very difficult. If you want to draw lines, with varying line width, then you'd have to use meshes.

For the screen coordinates: Assume you have a 3d point (x,y,z) and want to know where it is on screen. Then first define the position of the vanishing point (x_v,y_v) on screen. Calculate the difference-vector between (x,y) and (x_v,y_v) and divide by z. Add this to the vanishing point. In code: Also check out the video tutorial by Oysi

If I send a canvas and spritebatch reference to another thread, do drawing stuff there, will the canvas be automatically updated on the main thread since it's the same userdata?

While I don't know the answer I do know that the wiki says not to use love.graphics in a thread (other than the main one obviously). So I wouldn't recommend doing it even if it did update the main thread's version of the canvas

mickeyjm wrote:While I don't know the answer I do know that the wiki says not to use love.graphics in a thread (other than the main one obviously). So I wouldn't recommend doing it even if it did update the main thread's version of the canvas

Well that pretty much completely ruins the functionality of threads for me if I can't render something to a canvas on a separate thread.

Well that pretty much completely ruins the functionality of threads for me if I can't render something to a canvas on a separate thread.

Well consider it as ruined, drawing even on canvas must be done in the main thread.