2009
03.22

libtcod 1.4.1 released

Finally ! After almost 6 months of betas and release candidates…
You can get it here :
http://thedoryenlibrary.appspot.com/

The documentation has also moved here :
http://roguecentral.free.fr/libtcod/1.4/doc/doc.php

I’ll try to get an up-to-date version for linux 64bits as soon as possible.

I’ll maintain the 1.4 branch with bugfix releases probably for quite a long time because the new 1.5 branch will break API compatibility. See the roadmap on libtcod’s site for details.

I also wanted to thank all the developers who put their trust in libtcod for the recent 7DRL challenge. I’ll soon put a brainstorming thread on libtcod’s forum to get as much feedback as possible from this event and to put the 1.5 version on the right track to be even easier to use and more powerful.

7 comments so far

Add Your Comment
  1. I really, really like where this is going! This is a serious contribution to the RL community. Thanks!

    About the packer toolkit: you could also say it can be used for map generation.

    Which reminds me that all attempts until now to “mix elements” to get a sensible dungeon/map have failed, so maybe you could just have a set of useful functions and let the library user connect them at will?

    Still, creating a dungeon generator is one of the coolest tasks when programming a RL, so maybe it would be better to not prescribe a all-in-one solution?

  2. yeah that’s the idea. provide a toolkit with various basic transformation functions that produce complex behaviour when connected together (by the user).

  3. Thanks for the release!

    Is it just me or is there a performance regression when running samples_py.py? I remember “True colors” and “Noise” running at higher fps in the release candidates.

    Still, creating a dungeon generator is one of the coolest tasks when programming a RL, so maybe it would be better to not prescribe a all-in-one solution?

    Yeah, it’s cool. I’d refuse to use a premade dungeon generator. Don’t you try to take the fun from me 😛 I might use some helper functions like the upcoming packer toolkit, though.

  4. Anonymous: with Python you can’t just use the same idioms as you do in C. When I implemented my lighting model (which is a bit heavy), the FPS dropped from 30 to about 3 or 4. I had to make sure I didn’t redraw more than absolutely necessary to recover those FPS.

    My impression is that the python sample is mostly a direct translation from the C++ sample (which is only fair!), so it might not have the best performance. But that’s your job anyway 🙂

  5. No I don’t think the changes between rc3 and final release can explain a drop in performances, especially in the noise module which hasn’t changed for months…

    Indeed, the python samples and direct translations from C by someone who never used python (myself)… So they’re probably not the best python code example. They’re rather here to show what can be done with the library…

  6. Jotaf: I was comparing Python to Python.

    Jice: “True color” used to max out my aging CPU. Now “Noise” maxes it out too and “True color” runs much slower than before.

    It could be:
    – libtcod
    – samples_py.py
    – some weird issue with my system

    If it’s samples_py.py it not a big issue, of course.

  7. mmh indeed the color wrapper has been rewritten to share the same wrapping functions with the common lisp wrapper. Now every color has to be converted to/from int in python… That’s why it’s much slower.. Pff I’ll have to do something about it..