How to use Framebuffer:renderTo() properly

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
Jasoco
Inner party member
Posts: 3655
Joined: Mon Jun 22, 2009 9:35 am
Location: Pennsylvania, USA
Contact:

Re: How to use Framebuffer:renderTo() properly

Post by Jasoco »

benloran wrote:
Jasoco wrote:What color is the background? As I've mentioned before and have had a discussion about the inability for Löve to do it, but this would not be a problem if FrameBuffers could support alpha transparency. The edges around those circles are because FB's can't do alpha. Only solid or transparent like a GIF. Not alpha like a PNG. Sucks. But I'm more a 16-bit homage person so none of my graphics really have alpha edges.
I guess the background color is black, it's not being set anywhere in the example code.

I didn't realize that FrameBuffers only support 0% or 100% transparency, that's good to know.
It seems that a 0% opaque pixel remains 0% opaque, but anything between 1 and 254 will be placed on a black pixel. Which sucks a bit. Means you have to use rough edges or only have black pixels be transparent.
User avatar
benloran
Prole
Posts: 19
Joined: Tue Jul 05, 2011 4:52 pm

Re: How to use Framebuffer:renderTo() properly

Post by benloran »

Boolsheet wrote:No no, the framebuffers do fully support alpha (if there's such a thing)...
Aha! That makes sense. Thanks for your explanation, as well as the links to the Love ticket and that blog post (the next post on that blog seems to also describe exactly what's happening in TechnoCat's demo). Now I find myself really hoping that the ticket will be resolved before the next version of Love!
User avatar
Robin
The Omniscient
Posts: 6506
Joined: Fri Feb 20, 2009 4:29 pm
Location: The Netherlands
Contact:

Re: How to use Framebuffer:renderTo() properly

Post by Robin »

Jasoco wrote:It seems that a 0% opaque pixel remains 0% opaque, but anything between 1 and 254 will be placed on a black pixel. Which sucks a bit. Means you have to use rough edges or only have black pixels be transparent.
No, I played around with my example for a bit, and it turns out it does have colour. For example, a blue rectangle with 128 alpha will look like a half-visible blue rectangle. The problem is, due to the lack of premultiplied blending, it will do funky things in some situations, leading to my confusion, thinking that alpha < 255 causes the pixel to be black.
Help us help you: attach a .love.
User avatar
Ertain
Citizen
Posts: 55
Joined: Fri Nov 19, 2010 9:38 pm
Location: Texas, U.S.A.

Re: How to use Framebuffer:renderTo() properly

Post by Ertain »

Jasoco wrote:but anything between 1 and 254 will be placed on a black pixel. Which sucks a bit.
Robin wrote:I played around with my example for a bit.
Oh, the geek jokes just seem to be coming to me. :crazy:
Booted, suited, and ready to get executed.
User avatar
Boolsheet
Inner party member
Posts: 780
Joined: Wed Dec 29, 2010 4:57 am
Location: Switzerland

Re: How to use Framebuffer:renderTo() properly

Post by Boolsheet »

Hey, premultiplied made it in!
Here's an updated version of TechnoCat's Framebuffer.love which demonstrates again how drawing once to the framebuffer (in 0.8.0 called canvas) can be more efficient than drawing the images every frame separately to the screen.

Use arrow keys to translate the images and space to toggle canvas-to-screen/image-to-screen drawing.

(The Windows nightly build should be due in an hour or two)
Attachments
Canvas.love
Requires LÖVE 0.8.0 r850
(2.92 KiB) Downloaded 254 times
Shallow indentations.
User avatar
slime
Solid Snayke
Posts: 2930
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: How to use Framebuffer:renderTo() properly

Post by slime »

The above example is a situation where it might be better to use a spritebatch rather than a framebuffer/canvas, because they're supported by more computers and achieve the exact same thing. :P

Also, I would like to see people start putting frame times (in milliseconds) in their framerate strings. It can give a more accurate representation. <.< >.>
Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests