Dynamic textures/render-to-texture interface

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Dynamic textures/render-to-texture interface

Post by rude »

rude wrote: 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. :D
User avatar
Merkoth
Party member
Posts: 186
Joined: Mon Feb 04, 2008 11:43 pm
Location: Buenos Aires, Argentina

Re: Dynamic textures/render-to-texture interface

Post by 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.
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Dynamic textures/render-to-texture interface

Post by rude »

Merkoth wrote: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.
Merkoth wrote: Is it really worth adding it to the engine?
There are maybe more basic things that should be added first, yes. (As always).
Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 54 guests