Wednesday, March 31, 2010

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.

Saturday, March 27, 2010

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.

Wednesday, March 24, 2010

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.

Tuesday, March 23, 2010

Wrapping up libtcod, swig, and cmake nonsense soon hopefully....

While I've enjoyed the libtcod, swig, and cmake work, my interest is seriously starting to wind down. Here's a status update:

libtcod-java - See this mailing list post. Nobody has answered yet, and I have no clue how to get it working right now. This might have to be stowed.

libtcod-php - Waiting to hear back from person who wanted it to see if they wanted php4 or php5. cmake apparently only support php4 naively.

libtcod-ruby - Apparently there is some interest in this, but it isn't working for them. Will be trying to sort that out.

libtcod-cmake-osx - Working with somebody via e-mail (slowly) in order to try to get this working.

libtcod-csharp - Working with somebody via e-mail to sort out crashes and problems I'm not seeing.

Bit of libtcod swig isn't wrapping - Heightmap is down to four functions not being wrapped. BSP looks like a bit of a lost cause. The SWIG documentation on function pointers and callbacks is almost unreadable. The only way I can figure to wrap it is to remove the callback, and create functions that return lists of all the nodes in the BSP in the requested order.

Sunday, March 21, 2010

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...

Wednesday, March 17, 2010

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.

Tuesday, March 16, 2010

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...

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.