love
love copied to clipboard
love2d
Enable 3rd party extensions
Original report by Saggi Mizrahi (Bitbucket: ficoos, GitHub: ficoos).
It would be nice to have a feature similar to MOAI where you can have a plugins directory specified where subdirectories define new C++ module to be compiled into the love binary. This will make it easy for 3rd parties to add additional non-core functionality.
This is different than having a regular loadable Lua module since it could use the existing Lua modules without going through Lua. Also, for mobile platforms it's much better to statically link instead of using a dynamic library.
Currently just adding a directory under src/modules somewhat works after you run automagic but adding Lua bindings for your code will require modification to files in src/common making it so you can register types in-module instead of changing global data structures would make it much easier to integrate C++ extensions to existing love builds.
Using external plugins in MOAI: https://github.com/moai/moai-dev/wiki/Using-External-Plugins
Original comment by David Serrano (Bitbucket: Bobbyjones, GitHub: Bobbyjones).
I also think having some sort of plugin support in the build systems would make doing certain things easier. For example there are a couple source modifications for the Android port that have to be add in by hand. By having support for plugins it could potentially make it as simple as just dropping the plugin into a plugin folder and the build system will check that folder and do whatever it has to do to integrate the plugin into the apk. I feel as though this could potentially be useful on iOS as well. This would make things easier for people who want to add third party support for ads or IAP. It would also make it easier for people to use APIs not exposed by love. For example on mobile there could be a camera plugin or GPS plugin.
The way I think this could work(I have no idea how build systems work) is that a plugin will be a folder including source code for the plugin and a file that the build system will use. That file will have the instructions on how the plugin should be built and also it should have whatever edits it needs to be done to the android manifest and etc for permissions and etc. This would make adding plugins simple. Although it could potentially make creating plugins a bit more complicated.
Original comment by Bart van Strien (Bitbucket: bartbes, GitHub: bartbes).
I'm not quite sure what you're asking for. Unfortunately the way types are handled it's impossible to add love types dynamically, something we've not found a satisfactory solution to yet, but you usually won't have to do so. As for calling LÖVE internal code directly, it's already possible, though its API is fairly unstable. So does it come down to being able to easily add static libraries?
Original comment by Nathan 1852 (Bitbucket: Nathan1852, GitHub: Nathan1852).
I would really like it if at least the new Object stuff (the ability to define types yourself) would be open to use from c++. Right now it is possible on unix systems, but the LOVE_EXPORT directive is missing for windows.
The type and Object functions are usefull for any lua library, not just c++ libraries for love, so if you don't want to open up love, would it be an option to put this into an extra small library?
Also, what are the current arguments against allowing the use of love functions from c++? I don't think we need the ability to have custom modules be compiled into the love binary, but what is bad about the possibility for c++ addons to, for example, define a new Video type that inherits from loves Video Object (and for that needs access to the Videos methods) and adds the ability to stream youtube videos?
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
You can already use LÖVE from C++, but it's not officially supported as an external API. Having proper support would put a large burden on the LÖVE developers and increase the scope of LÖVE far beyond what it's currently designed for.
Many of LÖVE's APIs and internal code are designed from the ground up with Lua in mind. Designing for an external C++ API instead would take LÖVE's code in a different direction. I don't think you can have a shared codebase with both at once as first-class citizens whose goals are both met.
Original comment by Nathan 1852 (Bitbucket: Nathan1852, GitHub: Nathan1852).
Would it be at least possible to add the LOVE_EXTENSION Macro for windows to loves c++ functions? That still wouldn't mean that love officially supports calling the functions from c++, but it at least would allow everyone on every platform to make use of it, supported or not
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
I view LÖVE as providing solid base building blocks for 2D games to be created. If something is missing from a LÖVE API that prevents a feature useful in that context from being implemented in a game, I would rather improve the base building blocks instead of adding lots of hooks or similar extensibility.
Doing the latter would result in a codebase that is much harder to improve in the future while not reaching the goals that hooks promise, since it causes external library code to rely on LÖVE's internal implementation details and it's questionable whether anyone can guess as to what hooks will be wanted before they're wanted.
An example of the former is queuable audio sources. Instead of adding C++ side hooks for Source subclasses or whatever, LÖVE 0.11 adds new APIs to push any custom sound data into a Source. The solution is a base building block that anyone can use to stream real-time generated (or pre-created) sounds. If some third party C++ extension code had been created instead, it would already be broken because LÖVE's internal implementation of love.audio has changed fairly significantly during 0.11's development.
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
Would it be at least possible to add the LOVE_EXTENSION Macro for windows to loves c++ functions?
Every C++ function? Or just some? Which ones and why those, if the latter?
Original comment by Nathan 1852 (Bitbucket: Nathan1852, GitHub: Nathan1852).
But there are things which cant be built into LÖVE. Take my use case for example: I am writing a bindung to NanoVG for LÖVE. Something that will never be included inside of LÖVE, I am sure. But the ability to use LÖVEs new Type and Object system allows me to add NanoVGs objects into the Lua State. It doesn't manipulate LÖVE in any way. If I don't have the ability to use the Object system, I would have to pretty much copy loves code into a seperate library, since the Object code itself is very useful and good.
I can understand that you don't want to support the C++ side as well as the Lua side. But I don't quite get why you don't say: "The possibility to extend LÖVE exists. There is no official support for it, so issues regarding that (other than bugs which affect the Lua side as well) will be deleted. But the ability exists"
Edit: I just saw your comment. I would love for the Object/Type system to be open, so a user can use loves helper functions for userdata objects. I don't need anything else
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
Are you comfortable with your bindings / DLLs relying on a specific major/minor/patch LÖVE official release, and potentially not working with a custom build of LÖVE, if the custom build uses the same source code as the release version but just uses a different compiler version?
If I tell people about it officially, then it is effectively officially supported. I would be responsible for people having problems with it regardless of whether I'm willing to help them.
Original comment by Nathan 1852 (Bitbucket: Nathan1852, GitHub: Nathan1852).
I don't quite get what you mean with the specific major/minor/patch release?
Original comment by Sasha Szpakowski (Bitbucket: slime73, GitHub: slime73).
LÖVE's C++ code is not API or ABI stable between patch releases of LÖVE (this fact especially helps bug fixes). Also, if you compile a DLL with one specific compiler, it will not necessarily work with a build of LÖVE compiled for a different compiler/version.
Original comment by Nathan 1852 (Bitbucket: Nathan1852, GitHub: Nathan1852).
Ah, now I understand what you mean. I have no problem having to recompile my bindings for a new LÖVE version.
Also, you could add the windows macro without writing it anywhere on the wiki, making it work, but not telling people about it officially. I mean, it already works on unix distibutions, since they don't have dllexport, did people have issues with it on unix?
I think #1640 might supersede most of this issue? I don't think LÖVE will ever be getting functionality to use a C/C++ compiler for user C/C++ code, at least.
Not sure if this is relevant but I recently implemented plugins for lovr. Plugin folders can be added to a plugins folder (via git submodules or just copying) and they'll automatically get built by CMake. Their shared libraries get packaged in a place where they can get required on the target platform (this required some changes to the filesystem module's library package loader).
I'm hoping that this system makes it easier to use native libraries, but it's only been a couple of weeks so I'm still seeing how it goes. I also made enet and cjson plugins instead of including them by default. Technically lovr plugins can rely on the internal object model stuff but it isn't officially recommended/encouraged (that's where having some sort of C API comes into play I think).
Interesting. Making something like that work with LÖVE would probably be more involved because of how many build systems it uses (xcode + autoconf/etc + whatever Android uses + cmake), but if it ends up working well for lovr maybe it'll be worth it to solve that stuff for LÖVE.