Suggestion: more Image functions

[surtic]

At the moment there is a single function for creating an Image object: love.graphics.newImage(filename). This is fine, but there are possibly two other methods:

1. Create an image from an image: for example, one image is a sprite sheet, and the other image is a single sprite.
2. Create an image from a buffer. In Lua we can use a string as a buffer.

Suggestions:

Code: Select all

sheet = love.graphics.newImage(filename)
sprite = love.graphics.newImage(sheet, x, y, width, height)

buffer = ...
image = love.graphics.newImage(buffer, width, height)

An example for the buffer case: using cairo inside LÖVE, using GUI libraries that create buffers, etc.

Note: It's possible to implement the first case using Animation objects, but it could be a bit cleaner from an API point of view.

[rude]

Buffer is no problem, getting subimages is a bit more tricky.

When love.graphics.newImage("filename") is called, the image is loaded, a texture is created and then the image data is freed. This is done to save memory. To implement the subimage function, we would need to:

• Get the pixel data from a texture? (Is that possible?), or
• Not free the image data, or
• Fake it.

Faking it: the spritesheet and the single sprite refer to the same OpenGL texture, but have different texture coordinates.

[surtic]

I was thinking of the "faking it" solution (I imagined that you'd create a texture and get rid of the actual image). That would require some reference counting (either to the texture or to the original image object) - I wonder if it's worth it. It could be worth it from the OpenGL point of view of not creating too many textures, but I don't know how critical that is.

The buffer would definitely be useful, and at the moment the only solution for that is to write the data into a file and then read the file. That's probably not an acceptable performance hit if you do it every frame.

[rude]

That would require some reference counting (either to the texture or to the original image object) - I wonder if it's worth it.

Boost::shared_ptr will take care of that. It's not much work and very much worth it.

The buffer would definitely be useful, and at the moment the only solution for that is to write the data into a file and then read the file. That's probably not an acceptable performance hit if you do it every frame.

I'm pretty sure that creating images from a buffer at run-time won't be an acceptable performance hit no matter where the data comes from. We probably need to code a special streaming image object if we even want it to be close to efficient.

[Lord Tim]

Also what would be cool would be some way of drawing directly onto an image in the code. I heard somewhere that because of the way Lua works, you couldn't get the individual pixels, but would it be possible to draw to an image, and have that function return the new image?

[emonk]

I'm pretty sure that creating images from a buffer at run-time won't be an acceptable performance hit no matter where the data comes from. We probably need to code a special streaming image object if we even want it to be close to efficient.

I can think of plenty of ways that it would be useful to be able to generate/manipulate images in code at runtime, and I can think of at least one way that it can be done without too huge a performance hit.

What I'd suggest is to create a new class of image that is based on an in-memory bitmap. Ideally this image class would be a thin wrapper to the SDL Surface functions, would be for in-memory operations only and would have to be converted to a proper texture-based image for drawing to the screen.

So we'd have a couple of new love.graphics functions implementing various newSurface() functions (one for loading images, one for creating a fresh image of a specific size, etc) and a new object type (Surface?) with methods for the various graphics operations including pixel-level access, drawing primitives, extracting sub-surfaces, conversion to (and from?) a drawable Image, etc.