Dynamic textures/render-to-texture interface

[rude]

Thanks for ruining the surprise

My pleasure. 8-)

Allright ... I guess we need both streaming texture updates and render-to-texture.

For dynamic textures, how about:

Code: Select all

-- Amazing 2x2 white image.
white = { 
  255, 255, 255, 255, 255, 255, 255, 255, 
  255, 255, 255, 255, 255, 255, 255, 255 
}

-- Create some buffer with size 2x2.
buffer = love.graphics.newBuffer( 2, 2 )

-- At any time you can read pixels:
color = buffer:getPixel(0, 1)

-- Update certain pixels:
buffer:setPixel(0, 1, 128, 0, 0, 255)

-- Or update all pixels:
buffer:replace(white)

-- Texture will update automatically if changed.
love.graphics.draw(buffer, x, y)

Render to texture, as suggested by Ivan:

Code: Select all

buffer = love.graphics.newBuffer( 2, 2 )
love.graphics.setTarget(buffer)
love.graphics.setPixel(1, 1, color) -- Rendered to texture.
love.graphics.draw(image, 0, 0) -- Rendered to texture.
love.graphics.setTarget(love.target_screen) -- "buffer" is uploaded to GPU here.
love.graphics.draw(buffer, 50, 50) -- Rendered to screen.

I know little of Mode7 ... how does it work, and is it possible to achieve it with this interface? I do know it looks cool, so maybe we "need" native Mode7.

[Merkoth]

Both methods would work for mode7, but IMHO the second one looks cleaner.

The basic idea behind mode7 is pretty simple: It works pretty much like sprite scaling, with the only difference being that, for each line on the Y axis (screen_y) you have to consider a space_z value (a rather simple 3d projection), so each screen_y is scaled down according to distance. You also have to set the height of the horizon, pretty much and offset you add to screen_x. Of course you also have to consider the relation between screen_x and space_x. I just found a nice tutorial here (search for mode7) if you want more details

Is it really worth adding it to the engine? I don't think it's that useful, given the fact that not many games implement it.

[rude]

Both methods would work for mode7, but IMHO the second one looks cleaner.

(Edit: We do not have to choose between one method or the other: both could be implemented).

Once again I fail completely by using "buffer". What really happens:

Code: Select all

target = love.graphics.newTarget( 2, 2 )

-- glClear(). glViewport(2, 2).
love.graphics.setTarget(target) 

love.graphics.setPixel(1, 1, color) -- Drawn normally.
love.graphics.draw(image, 0, 0) -- Drawn normally.

-- glCopyTexImage(-ish) copies current pixels into a texture.
-- glClear(). glViewport(screenx, screeny).
love.graphics.setTarget(love.target_screen) 

love.graphics.draw(target, 50, 50) -- Drawn normally.

-- Fail:
color = target:getPixel(x, y)

We don't really have a "buffer" (OpenGL has it), so they should probably called "targets".

My point is that we won't be able to get the pixels from the "buffer" once the target has been reset; that buffer dies with the next glClear. At least according to my feeble human worm-baby brain.

Is it really worth adding it to the engine?

There are maybe more basic things that should be added first, yes. (As always).