As many may know, Magecrawl uses libtcod (via libtcod-net) for both graphics and engine support (FOV, LOS, etc). Months ago, I created a SWIG'ed version of libtcod-net, so that I could stop supporting a hand-rolled wrapper. A (beta) release featuring that has now come out.
If you use libtcod via c#, I highly recommend upgrading to the new wrapper, as the old one is deprecated and no new work will be done on it. Also, the new version has OSX versions for both C# and native C/C++ developers.
Get the hotness here.
Showing posts with label libtcod-net. Show all posts
Showing posts with label libtcod-net. Show all posts
Saturday, August 21, 2010
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.
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.
Monday, February 8, 2010
libtcod-net 1.5.0rc1-2 released (fixes reported TCODRandom issue)
The issue reported here has been debugged and fixed. The short answer for those not interested in the details is that I was using an API in libtcod wrong and that API was doing the wrong thing and corrupting its internal state. Get the newest libtcod-net here.
For those who are more technically minded, here's the story.
In between libtcod 1.5.0b2 and 1.5.0rc1, the C API changed for creating TCOD_Random's. Previously, one could call TCOD_random_new(), however in this release they added two different RNG implementations. This function now take a paramater. The way to get the "default" RNG is to call TCOD_random_get_instance, which I did happily. I also added a new TCODRandom constructor that took the enum for those who cared, but that's beside the point.
This worked, and seemed to be all I needed to do to fix libcod-net TCODRandom for the new API. However, there was an underlying issue. Sometimes in magecrawl, monsters and players would get into long stretchs (4000+ turns) of continual misses.
After some detective work, the issue was found. TCODRandom, like all libtcod-net wrappers that handle unmanaged resources, implement IDisposable. The idea is that you, or the runtime, will call Dispose() on it to free the allocated memory. The issue is that the new api had a note that you weren't supposed to call TCOD_random_delete on the default RNG. When you did this, you free'ed the memory for the global instance, but not null it out. Due to the implementation of the RNG, it'd happily use the garbage memory giving random answer most of the time. Some times however, some of the garbage pointed to a segment of zero'ed out memory, and I'd see the long stretch of zero's.
The solution was twofold. I updated libtcod-net to follow the API's rules and not delete the default RNG if that was how we implemented it. jice updated libtcod to not internally corrupt itself if you happened to do this. The joys of maintaining libtcod-net is that sometimes you get to track down memory corruption issues, even if you're written in c#. That is the fun of interfacing with unmanaged code.
For those who are more technically minded, here's the story.
In between libtcod 1.5.0b2 and 1.5.0rc1, the C API changed for creating TCOD_Random's. Previously, one could call TCOD_random_new(), however in this release they added two different RNG implementations. This function now take a paramater. The way to get the "default" RNG is to call TCOD_random_get_instance, which I did happily. I also added a new TCODRandom constructor that took the enum for those who cared, but that's beside the point.
This worked, and seemed to be all I needed to do to fix libcod-net TCODRandom for the new API. However, there was an underlying issue. Sometimes in magecrawl, monsters and players would get into long stretchs (4000+ turns) of continual misses.
After some detective work, the issue was found. TCODRandom, like all libtcod-net wrappers that handle unmanaged resources, implement IDisposable. The idea is that you, or the runtime, will call Dispose() on it to free the allocated memory. The issue is that the new api had a note that you weren't supposed to call TCOD_random_delete on the default RNG. When you did this, you free'ed the memory for the global instance, but not null it out. Due to the implementation of the RNG, it'd happily use the garbage memory giving random answer most of the time. Some times however, some of the garbage pointed to a segment of zero'ed out memory, and I'd see the long stretch of zero's.
The solution was twofold. I updated libtcod-net to follow the API's rules and not delete the default RNG if that was how we implemented it. jice updated libtcod to not internally corrupt itself if you happened to do this. The joys of maintaining libtcod-net is that sometimes you get to track down memory corruption issues, even if you're written in c#. That is the fun of interfacing with unmanaged code.
Sunday, February 7, 2010
libtcod-net 1.5.0rc1 seems to have an issue with TCODRandom, beware.
Update: See this for a solution.
I've spent half of today debugging this issue. It appears that there is an issue I'm hitting in magecrawl where a TCODRandom gets stuck in a state where it returns 0's for every GetRandomInt call. I'm working with the maintainers of libtcod, but it appears the issue is one underlying libtcod itself.
The workaround is to use the constructor that takes an enum and pass is the MersenneTwister value.
I'll update more when we find out more. I just didn't want anyone else to try to debug into their code for a few hours looking for sensor ghosts.
I've spent half of today debugging this issue. It appears that there is an issue I'm hitting in magecrawl where a TCODRandom gets stuck in a state where it returns 0's for every GetRandomInt call. I'm working with the maintainers of libtcod, but it appears the issue is one underlying libtcod itself.
The workaround is to use the constructor that takes an enum and pass is the MersenneTwister value.
I'll update more when we find out more. I just didn't want anyone else to try to debug into their code for a few hours looking for sensor ghosts.
libtcod-net 1.5.0rc1 released!
libtcod-net 1.5.0rc1 has been released (same day as base library libtcod itself may I add :) ).
The major changes include TCODPathFinding being removed. It's been split up into TCODAStrPathFinding and TCODDijkstraPathFinding. This is obviously an API break, but one that can be replaced with a simple find a replace. Beyond that:
http://code.google.com/p/libtcod-net/
The major changes include TCODPathFinding being removed. It's been split up into TCODAStrPathFinding and TCODDijkstraPathFinding. This is obviously an API break, but one that can be replaced with a simple find a replace. Beyond that:
- TCODSystem::GetCurrentFontSize
- New random number generator type and new default (ComplementaryMultiplyWithCarry)
- New functions - GetGaussianFloat, GetGaussianInt, Save
- Removed functions - GetIntFromByteArray
- ResetCreditsAnimation, which fixes an outstanding bug in Magecrawl.
http://code.google.com/p/libtcod-net/
Wednesday, January 20, 2010
libtcod-net 1.5.0b2 release
(Your regularly scheduled roguelike posts will continue after this brief announcement.)
Magecrawl uses libtcod-net heavily both for graphics display and in the game engine (pathfinding, LOS, etc). libtcod-net is just a thin c# wrapper layer around libtcod that I wrote before starting Magecrawl.. I think for any new roguelike, written in either in a managed or unmanaged language, libtcod is a wonderful library to use. jice, the writer and maintainer, is very responsive with suggested features and bug fixes.
A new version of the library has come out in beta, 1.5.0b2. It adds random name generation, sub-cell image blitting, and a few other things I can't think of right now. I'm not currently in need of any of the new features, but it seemed like a good time to update the wrapper and move Magecrawl to use it.
If your in the market for a library to sit your new or current roguelike under take a look at libtcod and/or libtcod-net.
Magecrawl uses libtcod-net heavily both for graphics display and in the game engine (pathfinding, LOS, etc). libtcod-net is just a thin c# wrapper layer around libtcod that I wrote before starting Magecrawl.. I think for any new roguelike, written in either in a managed or unmanaged language, libtcod is a wonderful library to use. jice, the writer and maintainer, is very responsive with suggested features and bug fixes.
A new version of the library has come out in beta, 1.5.0b2. It adds random name generation, sub-cell image blitting, and a few other things I can't think of right now. I'm not currently in need of any of the new features, but it seemed like a good time to update the wrapper and move Magecrawl to use it.
If your in the market for a library to sit your new or current roguelike under take a look at libtcod and/or libtcod-net.
Subscribe to:
Posts (Atom)