What was the reasoning for changing setColor from RGB 0-255 to 0-1 interval?

[dusoft]

Ehm, I just downloaded official deb package of trAInsported (http://trainsportedgame.no-ip.org/download.php) and of course, it won't work, because ... it was made for 0.9 and my distro has love 0.11 executable. Kind of mess, now for me as a user, too.

[MissDanish]

You seem to think that it's somehow indecent to criticize other's work, or even suggest ways to improve it. But it is not, even when done for free. Without criticism, there would be no progress.

I never argued against criticism, in fact I clarified in one of my posts that it's fine, but the thing is we're at least not getting any backwards compatibility soon from what I have seen so why even bring something up that has already been rejected? I was responding to your post about time, it's better that we have to spend 30-60 minutes updating our code than the few LÖVE devs left gets over worked, it's already insane what they're doing. We're using their work and we should be grateful for that.

How you come to think their time is worth more than everyone elses combined is beyond me, but you're entitled to your own opinion I guess.

When we're using a free framework the devs' time is more important, if we were actually paying them somehow it would be another story as then you can actually expect a service.

edit: *hugs*

[pgimeno]

Piece of cake. On Windows, that is. On Linux, I would use containers, but I don't think I'll make a Linux version.

I've thrown this quick-and-dirty code together:

Code: Select all

#!/bin/bash
ver=$(luajit <<'EOF'
  local love = {}
  pcall(require, 'conf')
  local c = {modules={}, window={}, screen={}}
  if love.conf then
    pcall(love.conf, c)
  end
  if c.version then
    io.write(c.version)
  else
    io.write('11.1')
  end
EOF
)
exec $ver/love "$@"

It might be able to use one of the LÖVE versions instead of LuaJIT. The binaries would need to be compiled statically, though.

Actually, 0.5.0 is the only version I know that can't be renamed, so if you don't plan to support it, you could have all executables in one dir.

[grump]

When we're using a free framework the devs' time is more important, if we were actually paying them somehow it would be another story

Isn't that the only reason why a framework exists in the first place? To provide you something of value that is designed to save you time, even if it's free? I also don't think the price of a framework is relevant when discussing things that need work to make the product more user friendly and accessible.

as then you can actually expect a service.

Yeah well, I certainly didn't command the LÖVE team to provide me a service. Pointing out flaws and discussing possible solution does not create an obligation for them. To the contrary, I'm going to build a LÖVE distribution myself that doesn't suffer from version hell. More like, attempt to build one

*hugs*

*hugs back*

[grump]

It might be able to use one of the LÖVE versions instead of LuaJIT. The binaries would need to be compiled statically, though.

Actually, 0.5.0 is the only version I know that can't be renamed, so if you don't plan to support it, you could have all executables in one dir.

I wish there were AppImages of all Linux builds available, just like the binary releases for Windows. That would make it super easy to build. I have to look into how to properly build them, especially with older lib versions. It's probably a lot of work. I'll stick to Windows for now, there's much less tripping hazards involved.

edit: It's not that hard to build some AppImages for testing. At least for 11.0, 0.10 and 0.9 I can simply copy and modify the 11.1 one. I will implement it for Linux first, because Windows is easy. I think I'll have a working prototype with just a few hours work over the next days

[dusoft]

Well, also an argument that 0.xx.xx means unstable versions that are bound to change underlying functions - I agree. If only Love wouldn't take years to go from 0.7 to 0.11. With this pace we will never see 1.x in our lives. (this is not a criticism of the Love developers per se, but rather criticism of the beta-forever approach with underlying functions breaking).

[grump]

If only Love wouldn't take years to go from 0.7 to 0.11.

Good news! We've already reached 11.1. The last sub-1.0 release was 0.10.2. I don't know if that means the interface is stable now.

[dusoft]

If only Love wouldn't take years to go from 0.7 to 0.11.

Good news! We've already reached 11.1. The last sub-1.0 release was 0.10.2. I don't know if that means the interface is stable now.

Right. Must have missed that. Jumping from 0.10.x to 11.x just makes that much sense ;-) Well, I hope that setColor won't change in few months to #FF00FF format.

[pgimeno]

Well, I hope that setColor won't change in few months to #FF00FF format.

Back to the topic, I think I read somewhere that it was because of the different texture formats in OpenGL, and not just because of shaders. Several texture formats use floats and these use normalized values (i.e. in the range 0 to 1). If I recall correctly, OpenGL defines the integer texture formats as representing floats in the range 0 to 1; the implementation internally divides them by the maximum possible integer value. For example, textures with 16-bit integer values represent floats in the range 0 to 1, which you can obtain by dividing the value by 65535. That makes e.g. the blending functions work as designed; see BlendMode_Formulas.

I have to say, I'm not a big fan of this change either. I think it is a step in the wrong direction, in the sense that it makes it harder for novices to work with colours, while one of the big selling points of LÖVE is how novice-friendly and easy it is because of how it hides many implementation details behind its lövely API. This change exposes implementation details in a very prominent area that everyone is going to run into, and not just advanced users.

[dusoft]

I have to say, I'm not a big fan of this change either. I think it is a step in the wrong direction, in the sense that it makes it harder for novices to work with colours, while one of the big selling points of LÖVE is how novice-friendly and easy it is because of how it hides many implementation details behind its lövely API. This change exposes implementation details in a very prominent area that everyone is going to run into, and not just advanced users.

Well said. This is another important factor in addition to the completely broken games. Also, working with integers is just something everybody knows and understands. Working with "infinite" interval of 0 to 1 is more difficult to grasp. Not even talking about changes needed to accommodate random numbers generation for colors etc.