Drawing a large number of individual pixels per frame

[kraftman]

Are you generating the framebuffer on every frame, by any chance?

I am, because I'm looking for a solution where I can dynamically display the map. However I suppose what I can do is only call newPoint on the framebuffer when a tile's data changes.

Thanks for all the suggestions, I will profile this method against the ImageData method and post my results.

What changes about the map?

[kefka]

Are you generating the framebuffer on every frame, by any chance?

I am, because I'm looking for a solution where I can dynamically display the map. However I suppose what I can do is only call newPoint on the framebuffer when a tile's data changes.

Thanks for all the suggestions, I will profile this method against the ImageData method and post my results.

What changes about the map?

Good question. The map is randomly generated by a cave-digging algorithm. I'd like to provide an interface to modify parameters of the algorithm and display the generation realtime.

[kraftman]

In that case I would recommend frame buffers. Using image data, you would need to create a new image to display each time new terrain is generated, while using frame buffers you can add extra info to the same frame buffer. I haven't used spritebatches yet, but I think you could do something similar with them.

[Taehl]

If he used the ImageData method, he could use ImageData:setPixel to add the changes to the map. He wouldn't have to re-generate the whole map every frame.

I wouldn't recommend spritebatches for this, as you WOULD need to re-generate it all the time (you can only add more and more to a spritebatch, not change or remove graphics from it).

[slime]

If he used the ImageData method, he could use ImageData:setPixel to add the changes to the map. He wouldn't have to re-generate the whole map every frame.

I wouldn't recommend spritebatches for this, as you WOULD need to re-generate it all the time (you can only add more and more to a spritebatch, not change or remove graphics from it).

You do have to call love.graphics.newImage(imagedata) every time you change it, which creates a whole new image from the imagedata. This will create huge amounts of RAM if you aren't careful, AFAIK.

Regenerating spritebatches is generally pretty efficient, comparatively. Doing a streaming spritebatch (re-creating every frame) can be faster than drawing each image individually, and an infrequently-updated (less than once per frame) spritebatch is pretty much always faster than drawing individual images.

[T-Bone]

If he used the ImageData method, he could use ImageData:setPixel to add the changes to the map. He wouldn't have to re-generate the whole map every frame.

I wouldn't recommend spritebatches for this, as you WOULD need to re-generate it all the time (you can only add more and more to a spritebatch, not change or remove graphics from it).

You do have to call love.graphics.newImage(imagedata) every time you change it, which creates a whole new image from the imagedata. This will create huge amounts of RAM if you aren't careful, AFAIK.

Regenerating spritebatches is generally pretty efficient, comparatively. Doing a streaming spritebatch (re-creating every frame) can be faster than drawing each image individually, and an infrequently-updated (less than once per frame) spritebatch is pretty much always faster than drawing individual images.

Well, it shouldn't be using all that much RAM unless you're storing all the images. It will make the garbage collector go nuts, though, which is never a good thing. I'm not sure how good the GC is in Lua (if it were Android, it would've made the app unusable (although I think they improved the GC in Android 2.3))

[Taehl]

This will create huge amounts of RAM if you aren't careful, AFAIK.

I did a test, setting a pixel / newImage-ing / drawing a 256x256 image at about a thousand times per second, and didn't see Love's RAM usage go over 26 megs.

[kraftman]

It's still less efficient to create a new image each time than to just add the extra data to the same framebuffer

[benloran]

It's still less efficient to create a new image each time than to just add the extra data to the same framebuffer

Unless I'm misunderstanding you, I don't think you can do this in Love 0.7.2, since framebuffers are cleared automatically each time you draw to them. (Though I believe this is fixed in 0.8.0).

[adrix89]

What about the Sonic solution?
Tile with hightmap info?