Saturday, March 13, 2010

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.

Friday, March 12, 2010

Bringing cmake to libtcod - Last bits of polish

(Your regularly scheduled blog posting about c# and magecrawl will return shorting, this is the last post scheduled to deal with cmake and libtcod.)

The last major issues I believe have been worked out. With the exception of osx support, which libtcod didn't have up to date in the first place, and some documentation I'm planning on writing tonight, cmake support is finished.

I finished up upx support last night, and spent today breaking up the build files into libtcod and sample parts, which makes everything much more clear. Overall, despite my gripes last night about its documentation, cmake is a great build system. It is vastly better in my opinion than makefiles, and the only build system is comparable in features is scons.

If you're writing a roguelike (or anything really) in C/C++, and consider cross platform important at all, I'd take a look at cmake.

Thursday, March 11, 2010

Bringing cmake to libtcod - Why "use the source Luke" doesn't mean you can skip documentation..

I'm going to start this quick post off by saying that cmake doesn't have the worst documentation ever. I'd generally award that honor to the C# swig documentation.

However, the documentation for cmake leaves much to be desired. Throughout my work, I've found most of my help with Google and other peoples submitted scripts. I'm going to try not to be cynical and assume that this is due to them selling a book.

Anyway, it seems that the upx for cmake documentation just doesn't exist. I can find nobody on the internet using it. *Edit* I found one person here but it isn't working for me. At this point, I'm digging into the source of FindSelfPackers trying to figure out what I need to tickle to get it working. While this is better than the situation if cmake was closed source, it saddens me nevertheless.

(/endrant)

As the maintainer of libtcod-net, which is only somewhat documented, I realize this same complaint could be leveled back at me. If you happen to find yourself cursing the documentation of libtcod-net, please let me know.

*Edit-2* Since apparently I have a high google rating for "upx cmake" and I've found my solution, I'll post it for any future googlers. I gave up on using the built in finder, and am just using the one visible from the prompt. I'll have to variable it out to work on windows, but it's "good enough".

samples_c being the name of one of the outputs:
        ADD_CUSTOM_COMMAND(
            TARGET samples_c
            POST_BUILD
            COMMAND upx samples_c   
            VERBATIM
        )

Bringing cmake to libtcod - Almost there...

From my original list:

  • Build the example programs
  • Add back opengl support
  • Test linux (and mac if I can get ahold of one) builds.
  • Seperate C and CPP libraries for linux.
  • Install build stuff to root directory
  • A list of nice to have.
  • Documentation! Quickstart guide!
  • Work on issues provided by and try to convince maintainers of libtcod that cmake is better.
Ignoring the mac build, which I still don't have, I only have the "nice things to have" (upx, electric fence), documentation, and some cleaning up to do.

CMakeLists.txt is now 160 163 lines of text so far. Compared to 1209 lines of makefiles it's doing the job of, its currently 7 1/2 times shorter. It is also one place to update the new/deleted files, as opposed to 8 makefiles + a codeblocks project that exists somewhere.

Assuming upx and friends don't take forever, I'm figuring one more good afternoon is all it will take to get a passable build done.

Update: Scratch electric fence, it was a 3 liner over breakfast.

Wednesday, March 10, 2010

Bringing cmake to libtcod - And then there was Linux

Since my last post I've accomplished a few things. One of them includes:



The sample programs were ridiculously easy to move to cmake. Almost one liners in fact.

Beyond that, opengl has been added back. That was pretty easy, find_package has to be the coolest macro in cmake.

Linux support happened this morning. Other than some bashisms in my script to generate the cmake files, all it took was a few more find_packages to use the system headers/libraries.

Last thing of note was a quickstart document was written up, to get people started using cmake if they want to try it out. On libtcod's SVN head, its cmake/QuickStart.txt

Still a lot to do, but I'm getting there.

Tuesday, March 9, 2010

Bringing cmake to libtcod - First Successes

I just checked in cmake files that will build libtcod and libtcod-gui under both visual studio and msys/mingw.
















I still have a laundry list of things to do left including:
  • Build the example programs
  • Add back opengl support
  • Test linux (and mac if I can get ahold of one) builds.
  • Seperate C and CPP libraries for linux.
  • Install build stuff to root directory
  • A list of nice to have.
  • Documentation! Quickstart guide!
  • Work on issues provided by and try to convince maintainers of libtcod that cmake is better.
But I am happy with what I've accomplished so far.

Monday, March 8, 2010

A truckload full of random updates...

So it's been more than a week since my last post, which is more than twice what I strive for (1.75/week). A variety of reasons are to blame for this, so I figured I'd comment on the relevant ones.

  • Illness - Have to love the times of year when everyone in the office seems to get sick.
  • Dragon Age - I just finished this game this weekend. I'm in the weird position of really really enjoying the game, but suggesting that others not buy the game and boycotting the expansion myself. The game comes with DLC (downloadable content) that requires authentication against EAs server to use. I didn't know that when I purchased the game. That means if you download the new armor and character, you can't play single player if you don't have an internet connection. Considering the problems that this can cause, I refuse to support games that do this. 
  • libtcod - The base library that Magecrawl is built upon (via libtcod-net). While working on a bit of research that I'm not ready to open the lid on, I came across the build system, which is makefiles. Since my last post was a rant, I'll spare you the feeling on make. I'm working on adding cmake support, and was making great progress before getting sick. It's my goal to finish that before continuing work on Magecrawl.