Help with external library inclusion

[iconmaster]

I have, in my .love file, a library named 'gd.dll'. The first line of code in my program is

Code: Select all

gd = require "gd"

This returns the error message that the library is not found. In the list of places it checked, it says no file was at '.\gd.dll', which happens to be exactly where gd.dll currently is! Am I doing something wrong?

[SquareMan]

require appends a .lua extension to a file you specify, im not sure if you can use dlls in love2d without editing the source code to include it.

[Boolsheet]

Yes, LÖVE can load binaries.

I have, in my .love file, a library named 'gd.dll'.
[...]
it says no file was at '.\gd.dll', which happens to be exactly where gd.dll currently is!

There are a few things to consider. You say the dynamic library is in a compressed archive. The OS will never load a binary out of a Zip and the LÖVE binary loader does not automatically extract it for you. It's necessary to write the library to an actual file with love.filesystem (or the Lua IO, if you really have to ). The tricky part is where you need to place it.

Techincally, you could put the library anywhere and just modify the Lua binary loader search path (package.cpath) to make it look in the correct directory. This would be the easiest solution during development. Not so sure if that's going to give any problems when you release it.

The LÖVE binary loader only looks in one place. Well, actually two. For normal games it searches in the application data directory + '/love/'. This can be expressed as 'love.filesystem.getAppdataDirectory().."/love/"' or, on Windows, '%APPDATA%/love/'. The obvious problem is that you can't write there with the love.filesystem module. My guess is that this path is only meant for the development stage.
For fused release-mode games it searches in the save directory (love.filesystem.getSaveDirectory). This makes it very easy to load it. Just write it to the save directory and require it.

[Inny]

I'm assuming gd.dll is this: http://gnuwin32.sourceforge.net/packages/gd.htm

In which case, can I ask why this would be helpful? Maybe we can have a little discussion and get around even needing the dll in the first place, and keeping your game portable across every platform love supports.

[iconmaster]

Yes, LÖVE can load binaries.

There are a few things to consider. You say the dynamic library is in a compressed archive. The OS will never load a binary out of a Zip and the LÖVE binary loader does not automatically extract it for you. It's necessary to write the library to an actual file with love.filesystem (or the Lua IO, if you really have to ). The tricky part is where you need to place it.

Techincally, you could put the library anywhere and just modify the Lua binary loader search path (package.cpath) to make it look in the correct directory. This would be the easiest solution during development. Not so sure if that's going to give any problems when you release it.

The LÖVE binary loader only looks in one place. Well, actually two. For normal games it searches in the application data directory + '/love/'. This can be expressed as 'love.filesystem.getAppdataDirectory().."/love/"' or, on Windows, '%APPDATA%/love/'. The obvious problem is that you can't write there with the love.filesystem module. My guess is that this path is only meant for the development stage.
For fused release-mode games it searches in the save directory (love.filesystem.getSaveDirectory). This makes it very easy to load it. Just write it to the save directory and require it.

This is what I was looking for, I believe. So, let's say I want to, on startup, move my dll from my .love file to the save directory. Is this possible, and if so, How would I wrangle love.filesystem to do this for me?

I'm assuming gd.dll is this: http://gnuwin32.sourceforge.net/packages/gd.htm

In which case, can I ask why this would be helpful? Maybe we can have a little discussion and get around even needing the dll in the first place, and keeping your game portable across every platform love supports.

I'm using the GD library that came with my Lua distribution, which I believe is what you say, yes. I am using it so I can combine and manipulate multiple images together and then save them as a temporary tileset for a SpriteBatch. I am assuming it's probably is a poor tool for my job. I was looking just for a library to manipluate image files directly.

[Jasoco]

Also, using a DLL kind of defeats the purpose of cross-platform since OS X and Linux users may not be able to load them. DLL's are a Windows thing. Unless there's such a thing as a universal DLL?

[Nixola]

As far as I know, DDLs are for Windows, .so are vor Linux and I don't know anything about Macs

[Boolsheet]

This is what I was looking for, I believe. So, let's say I want to, on startup, move my dll from my .love file to the save directory. Is this possible, and if so, How would I wrangle love.filesystem to do this for me?

Let's say you have a rot128 module like this.

Code: Select all

#include <stdlib.h>
#include <lua.h>

static int rot128(lua_State * L)
{
	size_t size, i;
	const unsigned char * in = (const unsigned char *)luaL_checklstring(L, 1, &size);
	unsigned char * out = malloc(size);
	if (out == NULL)
		return 0;
	for (i = 0; i < size; i++)
		out[i] = in[i] + 128;
	lua_pushlstring(L, out, size);
	free(out);
	return 1;
}

#ifdef _WIN32
__declspec(dllexport)
#endif
int luaopen_rot128(lua_State * L)
{
	lua_pushcfunction(L, rot128);
	return 1;
}

I compiled it to _rot128.dll and _rot128.so and placed them in the game archive. My main.lua looks like this.

Code: Select all

love.filesystem.setIdentity("binarytest")

local lib_ext
if love._os == "Windows" then
	lib_ext = ".dll"
elseif love._os == "Linux" then
	lib_ext = ".so"
end
if not lib_ext then
	error("System apparently not Windows or Linux.")
end

if not love.filesystem.exists("rot128"..lib_ext) then
	love.filesystem.write("rot128"..lib_ext, love.filesystem.read("_rot128"..lib_ext))
end

rot128 = require("rot128")

function love.load()
	msg = "Hello world"
	msg = rot128(rot128(msg))
end

function love.draw()
	love.graphics.print(msg, 10, 10)
end

(I don't have OS X so I left it out.)
This only works for fused release-mode games. It is possible to force release mode in LÖVE 0.8.0 by calling love.filesystem.setRelease(true) at the top of conf.lua. The next version of LÖVE will include a fused command-line argument.

Unless there's such a thing as a universal DLL?

No, it is necessary to compile the library for all the platforms to make it work everywhere. It is possible, but can involve some headaches. Just deploying LÖVE alone is so much easier.

[coffee]

Also, using a DLL kind of defeats the purpose of cross-platform since OS X and Linux users may not be able to load them. DLL's are a Windows thing. Unless there's such a thing as a universal DLL?

Yes Jasoco I agree with your concernings but if the library used is trully cross-platform you can also compile it as "dylib" for osx. Some game languages and frameworks usually can create their own universal dll. If I remember for example Pure Basic does something like that.

[T-Bone]

I've never heard of universal dll:s. What are they compiled into? They can't be real binaries, can they?