LÖVE

So I have a few questions about 0.11.0

Changed all color values to be in the range 0-1, rather than 0-255.

Why was this implemented? It seems like it's just a very taste-based change that will break a lot of projects. Or was this change made because shader code uses values 0-1 for colours?

Changed the 'vsync' field of love.window.setMode and t.window in love.conf. It's now an integer with 0 disabling vsync.

Does this mean we can set the frame cap to integer multiples of the monitor's vsync?

Davidobot wrote: ↑Sat Jul 29, 2017 4:57 am

Changed all color values to be in the range 0-1, rather than 0-255.

Why was this implemented? It seems like it's just a very taste-based change that will break a lot of projects. Or was this change made because shader code uses values 0-1 for colours?

There were two big reasons for the change:

• It creates better consistency across LÖVE's functionality (shader code is no longer different in this regard compared to love.graphics and ImageData).
• More importantly, it allows for implementing varying bit depths and texture formats without love users needing any special-case code that deals with colors. For example 0.11.0 adds a normalized 16 bit per component ImageData format, and floating point 16 bit and 32 bit per component formats. Representing these with the old APIs would make no sense.

It's also easier to do math (for example interpolating between two colors, or premultiplying alpha) on [0, 1] colors compared to [0, 255].

Davidobot wrote: ↑Sat Jul 29, 2017 4:57 am

Changed the 'vsync' field of love.window.setMode and t.window in love.conf. It's now an integer with 0 disabling vsync.

Does this mean we can set the frame cap to integer multiples of the monitor's vsync?

Yes, although some drivers or operating systems may fall back to an effective vsync value of 1 (also keep in mind monitor refresh rates vary - the 3 displays I use in my house are 60hz, 75hz, and 144hz).

0-1 range was because canvases can do more formats than the 8bit srgb, and 0-1 makes it easier, since it's normalized.

Is the wiki for any new or changed functions going to be up-to-date by the time this update comes out? Looking forward to it. =)

Sir_Silver wrote: ↑Sat Jul 29, 2017 5:26 am Is the wiki for any new or changed functions going to be up-to-date by the time this update comes out? Looking forward to it. =)

The answer to that would be yes. The dev team keeps the wiki very up-to-date.

This pull request feed? https://bitbucket.org/rude/love/pull-re ... ented/diff

If it is that one, I don't think it answers many of my questions.

To be clear, I wasn't asking those questions because I thought that they hadn't been thought of or thoroughly discussed before, I was asking because I'm interested in LOVE's API design and I think it's useful to discuss and document API design rationale publicly.

Santos wrote: ↑Sat Jul 29, 2017 10:43 am This pull request feed? https://bitbucket.org/rude/love/pull-re ... ented/diff

If it is that one, I don't think it answers many of my questions.

To be clear, I wasn't asking those questions because I thought that they hadn't been thought of or thoroughly discussed before, I was asking because I'm interested in LOVE's API design and I think it's useful to discus and document API design rationale publicly.

I'd keep my eye on the commit history instead: https://bitbucket.org/rude/love/commits/all

Also, since anything that gets implemented can and will be in question until the "official" release, the docs aren't updated until that time, since it'd take more time to fix up existing wiki entries that will also have the chance to be forgotten about, doing it that way.

So, are projects in older releases that use 0-255 value will not be compatible with the soon to be released 0.11 version?

yetneverdone wrote: ↑Sat Jul 29, 2017 1:46 pm So, are projects in older releases that use 0-255 value will not be compatible with the soon to be released 0.11 version?

minor releases always break compatibility... just create a wrapper for it

And make sure you use forward-compatible wrapper so you remove it once new version is out, not backwards compatible wrapper that'll stay there forever.