Completed C# and Lua Swig Wrappers!

It has been a busy couple days since my "I'll get the wrapper up here that night" post. A few more last minute issues, including a weird race condition with different .NET runtimes that I think I ironed out, held this up, but now it is ready.

C# Wrapper

Lua Wrapper

The C# wrapper is now powering magecrawl, which is a pretty significant codebase, so hopefully most of the issues there are ironed out. With Lua, the "hello world" demo works, but I don't know lua well enough to test it beyond that.

Please note, that the libtcod these use is the svn of the upcoming 1.5.x release, and is therefor unstable. The API might change, it might crash, it could steal your girlfriend and watch TV while you're at work, so report bugs you find so they can ironed out early.

Beyond that, I finished all the C# documentation for the new release, so when that comes out, C# will be a first class citizen. My todo list for libtcod is just about done now, so expect a new post in the next few days talking about scheduling magecrawl and "rebooting" this iteration.

Quick status update...

I just finished getting the libtcod c# swig demo working. There are some performance places I'd like to work on at some point, but it's very reasonable (160fps vs 200fps on initial screen).

I'm going to walk over the diff, and figure out which places of the API could use some renames or cleaning up. I know the print/printRect functions need some love, and the noise functions, but beyond that I think I'm in good shape.

Post that, I'll port magecrawl to use the new API. I'm hoping that turns out to be straightforward. I'm guesstimating 4 hours of work. After that, I'll know that things work great, and I'll post a second version of the wrapper for public testing.

swig'ed libtcod c# demo sucess...

There still are multiple modules not working right and a crash on exit in TCDODijkstra, but I got the demo in c# ported to the new API and working!

Between craziness at work and work planning a trip over the summer, my hacking time has been scare this week, but I feel like this is good progress.

Update: The TCODDijkstra crash appears to be a bug in libtcod itself, as I can reproduce it in the C++ demo. I've notified one of the maintainers.

Update^2: The crash was fixed in all of 15 minutes, nobody can say the libtcod maintainers aren't responsive.

Sometimes you have to use a bigger hammer...

This evening I spent awhile trying to hammer the SWIG'ed c# wrapper into something usable and less ugly. I've fixed all the "known" issues with the wrapper not wrapping some modules or functionality. The reduction in ugliness is related to the C-style enum and data type names. Things such as:

• TCOD_BKGND_NONE
• TCOD_key_status_t
• TCOD_NOISE_MAX_OCTAVES

While for C users there is nothing wrong with them, users of higher level languages expect identifiers with less capital letters and underscores. After spending an hour or two trying to do it "nicely", I finally settled with adding somewhere around 200 lines like:

%rename (NoiseMaxOctaves) TCOD_NOISE_MAX_OCTAVES;

While a few VIM macros made this less painful that first glace would suggest, it still took awhile. It isn't a very elegant solution it works.

Now that I can type the constants without wanting to cry, I'm working on converting the C# libtcod-net demo program to use the new API. It started with about 400 compiler errors and I still have 230 to go, so it will take a while. It also means converting magecrawl (and by extension all the users of libtcod-net) will take awhile.

libtcod and swig - The current plan...

tbellin stepped up and figured out the swig documentation when it came to callbacks. He's tested in C# and apparently it works. I'm thrilled that somebody figured it out. :)

From reading the documentation, the given language needs "director" support for callbacks to work, so some languages like lua are out of luck for now (until SWIG adds more support) unfortuntly.

As I mentioned in the comments sections yesterday, here are my plans:

• Get heightmap finished
• Fix one issue with callbacks user data.
• Port the libtcod-net demo application to the new libtcod wrapper for testing.
• Port magecrawl to the new libtcod wrapper for more testing.
• Release two "official" platforms
• C# - If things work out, for the period of at least a release support both the new and old library. Strongly encourage people to move to the new wrapper.
• LUA - While it'll have to not have support for callbacks (stupid swig director support), it's still "good enough".
• Ask people who are interested in other languages/platforms to work with me to bring those languages up to a good enough level.

libtcod-ruby...

Well I have something done for ruby, but it isn't up the my normal standards (aka the demo isn't done). Here is what I have:

http://libtcod-net.googlecode.com/files/libtcod-ruby%20bits.zip

This is a built libtcod-ruby library, for Linux. I can't understand ruby well enough to get a hello world demo working, but require "libtcod-ruby" seems to work. If one of you ruby people want to get a demo working, I'll post it.

The reason that it's a Linux demo is because cmake seems to be utterly broken for finding ruby under Windows. After spending entirely too long messing with it, I gave up and built it under Linux. If someone want to try to get libtcod-ruby working under Windows, let me know and I'll point you to where I've given up.

Off to libtcod-php and libtcod-java, then fixing the known issues and then maybe I can go back to Magecrawl...

libtcod in LUA, any more requests?

I now have the same demo from yesterday in LUA for download. 

Download

Here are the list of output languages SWIG can target:

• Allegro CL
• C#
• CFFI
• CLISP
• Chicken
• Guile
• Java
• Lua
• Modula-3
• Mzscheme
• OCAML
• Octave
• Perl
• PHP
• Python
• R
• Ruby
• Tcl
• UFFI 

If anyone is interested in libtcod wrapped in any of the above languages, speak up and I'll see what I can do.

Otherwise, I'm going to work on fixing up the known issues with these SWIG wrappers so I can hand some/all of it off to somebody else and go back to work on Magecrawl.

Prototype libtcod + swig wrappers (python & C#)...

So I finished up the 95% of wrapping libtcod via swig today. The major outstanding areas not done are heightmap and bsp. Heightmap just because it passes a lot of arrays around, and bsp since it uses callbacks. I'm still not sure how I'm going to handle both of these.

Since they were easy to push out (and it's midnight my time right now), I'm just doing python and c#. I hope to get java and/or lua done tomorrow.

Python Demo

C# Demo

Remember, these are demos. They could eat your leftovers in the fridge or cause your program to explode, so be careful. And if things do explode or don't work, let me know. These demos are at the "it compiles, ship it" quality level.

Still more non-magecrawl work...

I keep promising myself that I'll get back to magecrawl soon, but right now this libtcod/SWIG work is keeping me busy. I've almost gotten the Console, Colors, and System classes wrapped. I find that googling for what I want to do is almost strictly better than looking it up in the documentation.

I'm figuring that once I get the hang of all the operation types I need to do in the conversion, that adding additional modules to the SWIG build will be easy. We'll see how well that assumption holds...

All your libtcod wrapper are belong to us...

(Apologies in advance for the title, but it was too good to pass-up).

The primary reason for my cmake work all of this/last week was so the build could get out of my way and I could experiment on some idea for wrapping libtcod. While libtcod-net works, and is good enough for writing magecrawl, I've seen multiple people going through the work of wrapping libtcod for each language they are interested in (python, c#, D, lisp, etc). Other people have been interested in using libtcod with java or other languages, but lack the time or skill to create their own wrapper. I'm also lazy, and if i can automate or reduce my workload, I'm all about it.

SWIG is a program that generates the "glue" layer so higher level languages can call C/C++, doing most of the work for you. It's a powerful program, with terrible documentation. At work, I've used it enough to feel comfortable trying it on libtcod.

After a morning of work, I have a proof of concept.

python:
import libtcod

libtcod.TCODConsole.initRoot(80, 50, "Test - python", False, libtcod.TCOD_RENDERER_SDL)
root = libtcod.TCODConsole.root.fget()

while not libtcod.TCODConsole.isWindowClosed():
    root.putChar(10, 10, 64);
    root.printLeft(3, 3, libtcod.TCOD_BKGND_SET, "Hello World");
    root.flush()
    root.checkForKeypress()


c#:

using libtcod;

namespace TestApp
{
    class Program
    {
        static void Main(string[] args)
        {
            TCODConsole.initRoot(80, 50, "Test - C#", false, TCOD_renderer_t.TCOD_RENDERER_SDL);
            TCODConsole.root.setForegroundColor(TCODColor.white);
            while (!TCODConsole.isWindowClosed())
            {
                TCODConsole.root.printLeft(3, 3, TCOD_bkgnd_flag_t.TCOD_BKGND_SET, "Hello World");
                TCODConsole.root.putCharEx(10, 10, '@', TCODColor.white, TCODColor.black);
                TCODConsole.flush();
                TCODConsole.checkForKeypress();
            }
        }
    }
}



There is a lot of work to be done, but the idea appears to be sound! I'll post more when I get the proof of concept fleshed out more.