LÖVE

Posted: **Sun Oct 21, 2018 8:15 pm**

Here's an old discussion on LÖVE versioning, for reference: viewtopic.php?f=4&t=81130

(It happens to be my first post on the forums)

I made some progress on an old version emulation library, but after I managed to have all versions compiled as separate executables, and seeing that the general opinion was that there would be little interest, I gave up.

Posted: **Sun Oct 21, 2018 8:23 pm**

pgimeno wrote: ↑Sun Oct 21, 2018 8:15 pm Here's an old discussion on LÖVE versioning, for reference: viewtopic.php?f=4&t=81130

(It happens to be my first post on the forums)

I made some progress on an old version emulation library, but after I managed to have all versions compiled as separate executables, and seeing that the general opinion was that there would be little interest, I gave up.

Yeah and I am not surprised, it's just lazy to distribute a .love rather than distributing the game with the right version. .love files should really only be distributed on these forums and among devs, no other real use for them

And with the whole "it's bad to rely on devs to update their software!", it's really not. Slime and the other people that contribute to the source work hard on it and it's pretty entitled to sit here and expect them to do even more work, generally it's not even that hard to update your code with each new version. If you really want to use an old version just distribute an .exe file or .app file with the correct LÖVE version.

Posted: **Sun Oct 21, 2018 8:26 pm**

pgimeno wrote: ↑Sun Oct 21, 2018 8:15 pm Here's an old discussion on LÖVE versioning, for reference: viewtopic.php?f=4&t=81130

Thanks!

I made some progress on an old version emulation library, but after I managed to have all versions compiled as separate executables, and seeing that the general opinion was that there would be little interest, I gave up.

Yeah, that's what I thought. I might do it anyway, just to prove a point (and to waste some time I have no use for). A love.exe replacement that is version aware and has all love releases included is super easy to build. Other OS are more work, since there are no contained releases before 11.

Posted: **Sun Oct 21, 2018 8:55 pm**

MissDanish wrote: ↑Sun Oct 21, 2018 8:23 pm Yeah and I am not surprised, it's just lazy to distribute a .love rather than distributing the game with the right version. .love files should really only be distributed on these forums and among devs, no other real use for them

For Linux, it's not lazy, it's kind of necessary. There are appimages and can't-remember-what other stuff, which have their limitations, but in my case I'm very wary of anything distributed as binaries. That's the norm under Mac and Windows, but the exception under Linux (save for the software that comes in the distros).

Debian still comes with 0.9.1 today, which is why I keep 0.9.1 through 11.1 compatibility in T2R, GSpöt and GifLoad.

grump wrote: ↑Sun Oct 21, 2018 8:26 pm Yeah, that's what I thought. I might do it anyway, just to prove a point (and to waste some time I have no use for). A love.exe replacement that is version aware and has all love releases included is super easy to build. Other OS are more work, since there are no contained releases before 11.

Good luck with that, if you follow that path. I think one of the major problems I stumbled upon is that functions in userdata can't be overriden; that shouldn't be an obstacle if you're going to implement the compatibility on the C++ side, though. Another obstacle was the switch from SDL1 to SDL2 at some point (for 0.9.0 I believe); some games may still rely on SDL1 quirks (can't remember which, but either love.keypressed or love.textinput were handled differently).

Posted: **Sun Oct 21, 2018 9:33 pm**

Just to clarify, in case it's not clear yet: users who can't run old games available as love files only are the ones who have to suffer from the design of LÖVE. Not developers who package and sell a game for each specific platform.

MissDanish wrote: ↑Sun Oct 21, 2018 8:23 pm And with the whole "it's bad to rely on devs to update their software!", it's really not.

Oh come on, nobody said that it's bad to update code. You're missing the point. It's not hard to update my code for any new release. But it's hard to update my code in a way that makes it work with older releases too. And it's not only hard for me, it's hard for everyone else. It's even harder for each and every user who downloads an older love file and can't use it, because double clicking game.love starts the wrong version, and it simply doesn't work.

The vast majority of available LÖVE games is available as love files only, built for one specific version. No such game will work with LÖVE 12.They're useless in a year's time frame, and nobody will be able to play them. Few devs update their game, and almost no user will tinker with their system to run a game some dude posted here years ago. The user is shit out of luck.

You simply say "love files are not for distribution", but what is the point then? That line of thinking is not in the spirit of multi-platform.

Slime and the other people that contribute to the source work hard on it and it's pretty entitled to sit here and expect them to do even more work

What's your point? That the time of slime and the few other people is categorically worth more than the time of all LÖVE devs and users in existence combined?

If you really want to use an old version just distribute an .exe file or .app file with the correct LÖVE version.

You keep missing the point and you're conflating terms. A user, a developer and a distributor are entirely different entities.

A distributor makes sure the finished game runs on the platforms of their choice, and package it with the correct runtime. They have to build their packages for all desired platforms separately. No problem here.

A developer (the kind that posts his WIP game here or on his blog) makes it either only work with a specific version, or they'll have a hell of a time making it work with multiple versions. You can't seriously expect them to package their alpha-state game for every supported system.

The situation for a user is that they're the one who have to figure out how to run that shit. They could fiddle with their system. But in reality, it's almost impossible for an ordinary user to use older love files. If you don't think that's a problem, then I can't help you.

The bottom line is, the way LÖVE is designed, you should never post love files if you want users to be able to play them next year. You need to package your game for every platform in existence instead if you want it to be playable in the future.
If that is how LÖVE and love files are supposed to work, then that's definitely bad design, considering that LÖVE a platform-agnostic framework.

Posted: **Sun Oct 21, 2018 9:37 pm**

pgimeno wrote: ↑Sun Oct 21, 2018 8:55 pm I think one of the major problems I stumbled upon is that functions in userdata can't be overriden; that shouldn't be an obstacle if you're going to implement the compatibility on the C++ side, though. Another obstacle was the switch from SDL1 to SDL2 at some point (for 0.9.0 I believe); some games may still rely on SDL1 quirks (can't remember which, but either love.keypressed or love.textinput were handled differently).

Yeah, that's not how I'm gonna do it. I will not mess with the love foundation.
There will be a small C++ Lua host that acts as the love.exe associated with .love and reads conf.lua from game.love to get the version. Then it runs the love.exe of that specific version that is entirely included in the distribution, physically separate from all other versions.

Code: Select all

love.exe
	\0.9
		love.exe
	\0.10
		love.exe
	...

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

Posted: **Sun Oct 21, 2018 9:43 pm**

grump wrote: ↑Sun Oct 21, 2018 9:33 pm
Slime and the other people that contribute to the source work hard on it and it's pretty entitled to sit here and expect them to do even more work
What's your point? That the time of slime and the few other people is categorically worth more than the time of all LÖVE devs and users in existence combined?

It literally is, they're doing this for free. You aren't entitled to their work, it's fine to suggest things but Slime has addressed this before and the answer was a clear no from what I remember. Which is completely fair considering he's doing this for free

Posted: **Sun Oct 21, 2018 9:54 pm**

Well, what a discussion. And thanks for the pointers as why the former (standard) color addressing was not up to date with shaders.

Anyway, I am pretty sure any good ecosystem provides backward compatibility to some extent. I have been part of multiple open source projects and the golden rule was not to break base functions. I see all the color things as pretty basic. So, I agree with other people here that adding backward compatible calls (or rather using different format - e.g. table - for the new color format) would be much appreciated. Moreover, it would allow people to browse these forums and still play many games available here without basically making all of them outdated and useless.

I overly appreciate Love2D developers, but saying that they are volunteering is not argument for breaking things in general. They should then also appreciate work of people that are part of the ecosystem (and Love2D would be irrelevant without the developers building on it).

As multiple people pointed out, Linux is the platform where things are often distributed as .love files. I would hate it to see otherwise and forcing people to distribute binaries just does not make sense (those would possibly not work on other Linux distros anyway!)

BTW, MissDanish - being around from whatever version does not mean a thing. I have been around probably from v0.5 or so and had to change few things on the way (functions moved between screen, graphics, window), but as I said - changing basic functions without keeping backward compatibility is pretty bad move. I have seen projects to lose developers as they rather moved on to use more stable frameworks.

Posted: **Sun Oct 21, 2018 9:56 pm**

MissDanish wrote: ↑Sun Oct 21, 2018 9:43 pm
grump wrote: ↑Sun Oct 21, 2018 9:33 pm What's your point? That the time of slime and the few other people is categorically worth more than the time of all LÖVE devs and users in existence combined?
It literally is, they're doing this for free. You aren't entitled to their work, it's fine to suggest things but Slime has addressed this before and the answer was a clear no from what I remember. Which is completely fair considering he's doing this for free

Way to refute a bunch of arguments.

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.

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.

Posted: **Sun Oct 21, 2018 9:58 pm**

dusoft wrote: ↑Sun Oct 21, 2018 9:54 pm Anyway, I am pretty sure any good ecosystem provides backward compatibility to some extent. I have been part of multiple open source projects and the golden rule was not to break base functions.

"Never break user space!" - Linus Torvalds

LÖVE

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

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

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

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

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

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

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

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

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

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

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