LÖVE

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.

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!

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.

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.

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)

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.

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