lua

Client Technology

~ Enno ~ Leave a comment

With the decision to start writing the client first came the question of client technology. The existing Eressea client, Magellan, is written in Java, and even if I wanted to use some code from it, I would not be able to run it on a mobile device. I also do not know the code base, since it is mostly written by player volunteers.

So unlike the server situation, there is no reason to stick to the language used in the past, and I am free to choose whatever I want. The real constraint here is mobile, and the options that I know of are Cordova/Phonegap (HTML5 and Javascript), Unity and LÖVE.

Cordova is the only one of these that I have practical experience with, and while it’s a great choice for an app with a lot of UI, it is not what I would choose for a game in which I want to render a lot of bitmaps. I am also not a huge fan of Javascript. Unity is hot with other indies, but it is a 3D engine first, and there is a learning curve that I do not feel like scaling right now. I would also have to brush up on my rusty 3D math, just to make 2D projections. That seems like a waste. On the other hand, Unity skills are very marketable in the game industry right now.

Finally, there is LÖVE. I had only briefly looked at it before, but it looks exactly like the engine that I had always wanted to write myself: Built on solid, industry-proven, portable C libraries (SDL, PhysicsFS, Box2D), with Lua as the programming language, and Android and iOS ports in addition to the desktop releases. There is an active developer community, and an IRC channel where people answer questions. I think it’s charming, so I wrote a few prototypes for key technology (networking, UI, controller input), got a simple map viewer for Tiled to run on my phone, and decided that my search for technology was over.

The problem with tolua++ and DLLs (solved!)

~ Enno ~ Leave a comment

Today I was going to make a tiny DLL that binds some C code with tolua++, and I ran into this error message:

lua: error loading module ‘foo’ from file ‘daisydebugfoo.dll’:

        The specified procedure could not be found.

That looks like my DLL isn’t exporting the luaopen_foo function correctly. That is the function lua calls to initialize the package it just opened, and tolua++ was not declaring it properly:

TOLUA_API int luaopen_foo (lua_State* tolua_S) {
  return tolua_foo_open(tolua_S);
};

TOLUA_APIis defined toextern, which doesn’t mean that it will be exported by the DLL, because on windows, the magic incantation for that is__declspec(dllexport). The tolua++ header has no special treatment for Windows, so I’m guessing that problem has just never come up for them.

Once the problem is understood, the solution is easy: I added another function to dllmain.cpp that has the correct export declaration and calls the generated one.

extern "C" {
  int tolua_bar_open(lua_State*);
  int __declspec(dllexport) luaopen_foo (lua_State* L) {
    return tolua_bar_open(L);
  };
}

There’s one caveat, because tolua++ has already created a function named luaopen_foo, so I had to tell it to name things differently, for which there is a command-line argument:

tolua++ -n bar foo.pkg > foo.c

Project Euler

~ Enno ~ Leave a comment

Thursday night I discovered Project Euler, a site full of math puzzles that can be solved algorithmically in under a minute each. Since then, I’ve solved the first 30-odd of them. Friday night Marcus and I sat down to solve the week’s new problem as it appeared online (we came in among the first 25 or so).

These are great fun. I think about them quite a lot as a background brain task, and I’m rediscovering how cool math problems can be. To make it a coding excercise, I’m trying too write them all in Lua and not in C, and as a result I feel that I’m getting a lot more confident in everyday Lua hacking.

Geeky pleasures.