LÖVE

Didn't expect a change but a lot of the GLSL code I really have trouble understanding.
Guess the people at GLSL Sandbox must be on the other side of the equator.

Most shader code found on shadertoy and GLSL sandbox is stuff you'll never see in real game code, since those sites have no way to load textures, no way to use sprite or vertex or model data, and no way to use vertex shaders – they only have pixel shaders and that's it.

So most code there has to make do by having very complicated (and often very slow) pixel shaders even when the same thing could be done much more simply and efficiently in a normal scenario (like in LÖVE).

Would it be possible to add Moonscript-Support?

What I mean is the ability to directly pack .moon (alongside of .lua) files in a .love file and let LÖVE take care of the rest.

rmcode wrote:Would it be possible to add Moonscript-Support?

What I mean is the ability to directly pack .moon (alongside of .lua) files in a .love file and let LÖVE take care of the rest.

There used to be a fork of LOVE that did this, made by leafo himself if I recall correctly, but the reasoning against its development was that it was easy enough to just compile the .lua files with moonc.

That works, though it's a little bothersome considering moonc doesn't properly register new .moon files on Windows, nor does it properly rename/delete .lua files corresponding the .moon files on all platforms with the watch option (last I've used it).

I'd like a more functional compiler, though being able to load them directly from the framework would be a little nice.

I really love Love2d, and I'm excited that I'm getting to a point where I can start throwing stuff at friends for testing. There are some features which can make distributing Love2d-based games easier:

• love.filesystem - support for writing files into the root folder (and subfolders) of main.lua. This will make it a lot easier for users to keep eg. their savegames and configurations intact if they move the app around (eg. to a new computer)

• permissions- when I follow the instructions for Game Distribution ( https://love2d.org/wiki/Game_Distribution ), I get an app which runs. However! It trips Gatekeeper on a standard configuration OSX-install. Most users haven't touched this setting. Is there anything that can be done about this (other than publish via the App Store)?

• distribution - ability to remove unused frameworks from the executable without breaking it - eg. Vorbis.framework (which is 20% of the total size of the distributable)

Keep up the great work! Super excited about iOS getting some Love, too.

I vote against including a bunch of modules, or moonscript - part of the appeal of Love2d for me is that it is not bloated with unnecessary things - see Unity3D for horrifying counterexample.

deströyer wrote:love.filesystem - support for writing files into the root folder (and subfolders) of main.lua. This will make it a lot easier for users to keep eg. their savegames and configurations intact if they move the app around (eg. to a new computer)

I'm afraid this is not possible; writing into a .zip file is, if not impossible, quite difficult to do, especially if you're running that zip file. It would only work when running a folder, not a .love file, so it would only maybe aid for debugging and not actually help with savegames and configurations.

deströyer wrote:• distribution - ability to remove unused frameworks from the executable without breaking it - eg. Vorbis.framework (which is 20% of the total size of the distributable)

I agree with this. It might not be much, but size can matter (especially on mobile) and (not so important, but heh) I really dislike distributing modules I do not use (I pretty much don't ever use love.physics or love.video, which I think are maybe the heaviest ones).

deströyer wrote:I vote against including a bunch of modules, or moonscript - part of the appeal of Love2d for me is that it is not bloated with unnecessary things - see Unity3D for horrifying counterexample.

Completely agree with this as well. One of the best things of LÖVE is, I write my own stuff.

Theoretically can remove these things. Iirc the build scripts allow you and if not you can hack the code and stuff to remove them.

Kingdaro wrote:

rmcode wrote:Would it be possible to add Moonscript-Support?

What I mean is the ability to directly pack .moon (alongside of .lua) files in a .love file and let LÖVE take care of the rest.

There used to be a fork of LOVE that did this, made by leafo himself if I recall correctly, but the reasoning against its development was that it was easy enough to just compile the .lua files with moonc.

lovekit ?

Kingdaro wrote:

rmcode wrote:Would it be possible to add Moonscript-Support?

What I mean is the ability to directly pack .moon (alongside of .lua) files in a .love file and let LÖVE take care of the rest.

There used to be a fork of LOVE that did this, made by leafo himself if I recall correctly, but the reasoning against its development was that it was easy enough to just compile the .lua files with moonc.

That works, though it's a little bothersome considering moonc doesn't properly register new .moon files on Windows, nor does it properly rename/delete .lua files corresponding the .moon files on all platforms with the watch option (last I've used it).

I'd like a more functional compiler, though being able to load them directly from the framework would be a little nice.

If you require "moonscript" it will overwrite the require function with one that compiled and loads moonscript files too. You can use that and compile with moonc for releases.
You could even just put in the .moon files in the .love, but then users will have to install moonscript (of you would have to package it aswell).

Roland_Yonaba wrote: lovekit ?

No, lovekit is a collection of moonscript classes for things like tweening, vector math, input etc.

I'd love to see support for multiple mice. I want to develop a strategy game for two players on one PC, both simultaneously using a mouse.

Back when SDL 2.0 was released, SDL contributor Ryan Gordon said something along the lines that multi-mouse support was being requested by lots of people, so I hoped that SDL would get that feature soon. But it's still not there as far as I know. Instead of waiting for SDL to provide that functionality, maybe Löve could make use of Ryan's ManyMouse library.