teh8bits wrote:Ah that makes sense. It would be nice if there was an image buffer that you could have direct pixel interaction with, then copy to VRAM to be drawn.
Yes, that would be nice. However, since LÖVE uses OpenGL, there is no direct way to access the framebuffer (= screen pixels). However, you could stream data to an Image. The steps one had to take are:
Create a OpenGL texture object (roughly corresponds to love.graphics.Image). This is used for communation with the graphics card.
Allocate a block of memory in RAM (i.e. love.image.ImageData).
Fill the block with RGB pixel data (i.e. ImageData:mapPixel()).
Transfer the memory-block (in RAM) to the graphics card using the texture object.
Draw the texture (i.e. love.graphics.draw(image, ...))
Goto step 3.
There is currently no way to do this. Maybe there could be a Image:setData() or something. It's not clear whether this would be as fast as with Java, because in this case the slow part is the third step because it involves expensive crossing of the Lua/C++ barrier.
Another method would be to use PixelEffects where you in fact have access to the raw pixel data. Because PixelEffects run on the graphics card they are very fast. For the same reason they don't work on every computer though - especially ones with Intel GMA.
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.
Damn. What if a simple OpenGL port was added to LÖVE? Again, I'm not entirely sure how it all works but couldn't something just be added to the interpreter that like emulates love.gl or something into C code or whatever the proper terminology is?
This wouldn't help with direct pixel interaction obviously but basic 3D engines would be possible.
