How to use Framebuffer:renderTo() properly

[TechnoCat]

Does it need to be PO2?

It is my experience that, yes, they need to be PO2. Or else you get implementation errors on some (many it seems) systems.

[Robin]

Does it need to be PO2?

It is my experience that, yes, they need to be PO2. Or else you get implementation errors on some (many it seems) systems.

Oh, ok. I wouldn't know.

[kikito]

Is that a bug or a feature?

Neither. It's a constraint set by OpenGL.

To understand why, think of the framebuffer as an offscreen... screen. In a 3D world, you don't handle pixels, but only shapes (that may have some nice textures on them). These shapes are projected onto a screen, like in a shadow theater.
Now you always want to project the shapes in a way that the whole screen will be filled. If you take a bigger screen and set it up so that it will show the same shadows as the small screen, the shadows will obviously be larger.
When creating a framebuffer, OpenGL will ensure you see the same content on the buffer as you do on your main screen.

The way LÖVE handles 2D is basically to have only flat shapes in the same plane. Images are just surfaces with the image as texture on them. If you project that to a bigger screen, the image will appear to be upscaled.
The scaling with love.graphics.scale is somewhat like moving the screen further away (or closer to) from the objects that are projected onto the screen.

Sounds complicated.

So I take that on a tile-based game, spriteBatches are more appropiate for rendering the level than framebuffers then. Specially if they involve scrolling, perhaps?

-__- I'm still very 0.6-oriented.

[TechnoCat]

Sounds complicated.

So I take that on a tile-based game, spriteBatches are more appropiate for rendering the level than framebuffers then. Specially if they involve scrolling, perhaps?

-__- I'm still very 0.6-oriented.

Don't sprite batches still draw each object every frame?

Anyways, still curious about this PO2 stretching issue.

[Robin]

Anyways, still curious about this PO2 stretching issue.

Congrats on your 600th post.

And you could try some things, see what they do?

[TechnoCat]

Easiest solution is to make the window po2 too. But then forget full screen.

Disclaimer: Framebuffer and screen size will be independent soon. http://bitbucket.org/rude/love/changeset/4deb61ae7d2c

[TechnoCat]

LOVE was fixed to not stretch framebuffer windows to the main window. I'm waiting on a build with that before I continue using framebuffers.

[Jasoco]

How would I use this to:

Copy the contents of the main visible screen to a separate buffer
Manipulate the pixels of the separate newly copied buffer, say make all the pixels greyscale
Then use that separate buffer as an image to paste onto the main screen

?

[TechnoCat]

How would I use this to:

Copy the contents of the main visible screen to a separate buffer
Manipulate the pixels of the separate newly copied buffer, say make all the pixels greyscale
Then use that separate buffer as an image to paste onto the main screen

?

Sounds more like a job for a shader.

but maybe, screenshot, greyscale mappixel, draw

[Jasoco]

Well, mostly the first and third steps. Can I copy from one frame to another? Then can I take another and use it as image data?

That's mainly what I want. Or just how do I draw to another buffer and use that buffer on my main screen? I don't understand the code provided. Anyone have a working example .love file?