LÖVE

Has anyone written a library that you can require which simulates older LÖVE function calls/objects with the current API?

Has anyone tried to and found it to be impossible?

Yes.*
Yes. Yes.

*: Wasn't complete, if i recall correctly.

There are things that may work with wrappers or such, but usually the API changed in ways between minor versions that you can't really recreate/simulate.

Something to make 0.9.x games work on 0.10.x is probably a lot easier than making 0.8.x games work on 0.9.x.

I've done some work on making 0.8 games work on 0.9 and 0.10. I didn't complete it because I couldn't figure out how to make it not-so-painful to use. It required modifying both conf.lua and main.lua.

One of the biggest obstacles was the change in SDL version.

I didn't complete threads because I hadn't found this when I started working on them: https://github.com/slime73/love-mutex but with that, I think they're doable as well.

I think I can do threads, someday I PROMISE I will try this, I can get down to 0.8.0 but not down to 0.7.2, there was a change in LÖVE physics which I don't think I can fill up.

In order to do killable single channel threads I would:

• Create a table which simulates to be a [wiki]Thread[/wiki] object, containing the methods a [wiki]Thread and a [wiki]Channel[/wiki], maybe the table could be omitted and we could directly modify Thread's metatables (ugly but smoother)
• The thread wouldn't be created from the file itself, it would need to be wrapped using a string or file
• This file or string would, require this library so that all love API's are changed to the expected ones (0.8.0), this would be useful for things like love-loader which need the love API from a thread.
• And would run a main function with a [manual]debug.sethook[/manual] in order to pause it from time to time, and check if the Thread has been killed with [wiki]Thread:kill[/wiki] (This would send an specific type of message through a Channel).

This is to me the bare minimum implementation. Some other features are needed.

Joystick suffer a big change too, which in order to fix would need many callback redirections if I don't remember wrong.

Also you would need to find the [wiki]love.textinput[/wiki] event and the [wiki]love.keypressed[/wiki] one and combine them into a [wiki]love.keypressed[/wiki] with a second argument being the unicode character. This would mean some work in [wiki]love.event.pump[/wiki]

Those are my thoughts, if someone has some other ideas, wants to correct me or provide alternative solutions (or use this solution and create a library) feel free to do so. I investigated a lot about this, for Cube, a library I'm about to bring back to life soon I hope

I an still thinking about a "version solution" on my Win7. I did some testing:
- I installed love-0.9.x and love-0.10.x in diferent folders using the zipped install packages.

- I did NOT insert the folders in the PATH.

- I renamed the downloaded .love files for 0.10.x to *.love010 and the others to *.love09.

- I doubleclicked one .love010 file in explorer and bound the extension with ...\love-0.10.1\love.exe Result: success so far for the .love010 files.

- I tried the same binding for .love09 files. Trouble: Caused by the same executable name, the binding ends up to be the same as the 1st one no matter, how i try.

- I renamed the ...\love-0.9.2\love.exe to ...\love-0.9.2\love09.exe and retried the binding. Success.

Results: It is possible to use different versions parallel on my computer, as long i can automate the distinguishing of versions.
The described solution is not the best one because she needs user actions, easy ones, but may be too complicated for some people.
Some support by the love team would come handy:

- Rename the love executable to love<version> eg. love010.exe or provide this executable name in addition as a link.

- The best solution (for windows) would be: all love versions in one folder using the same shared libs. All executable have version-strings. The one executable without version string is the newest version. I am not shure, all love versions can be copied into one folder. May be some libs have different versions? How big is the effort to recompile older love versions, so they use the newest shared libs? After being sucessfull installing all love versions in one folder, i would be possible to implement a "love-loader": the love loader opens .love files, checks the version information inside conf.lua and starts the right loveXXX.exe.