2008
01.08

C++ sample done!

I’ve just finished a C++ sample that demonstrate most of the library features.
You can get the source code here :
http://roguecentral.free.fr/libtcod/sample.cpp

Until it’s included in a new release of the library, you’ll have to compile it yourself… Here is what you should get :

Sample 1 : color manipulations, text rendering



Sample 2 : offscreen consoles, printFrame


Sample 3 : line drawing, offscreen console blitting

4 comments so far

Add Your Comment
  1. Awesome! It compiled right away with VS2005, and works like a charm. I have to say that seeing it in motion is much better than still images, and gives a good feel for the library’s potential.

  2. Wow ! This is a good news because I never compiled it on Visual Studio (only on mingw32). On another hand, one of the goal of the library is to be able to produce portable code and let the library handle the system specific parts. It seems to work !

    Also, using the library on something else than TCOD is good for debugging it. As you may have seen, the sample emphasizes a very special bug on libtcod-1.0 that I never saw with all these months of testing on TCOD :

    When you try to draw an ASCII character using color TCODColor::grey (196,196,196), and that character has never been drawn with another color, the character is printed with color 128,128,128 instead of 196,196,196…! This is obvious in the text at the bottom of the samples. libtcod-1.0.1 will correct this.

    Anyway, I hope you like the library and find it easy to use. I still have to work on robustness, because currently, if you do something bad like using coordinates outside of the console, there are lots of chance you finish with a segfault…

  3. Ahh not to burst your bubble but there is some flickering in the first sample. At first I thought it was because the random colors were getting out of bounds but it’s not enough… for some reason, one of the corner colors will occasionally switch to a completely different color (and back). That color still interpolates fine with the others.

    About checking out-of-bounds coordinates, some of the guys might see that as an unnecessary slow-down 🙂 You could have a wrapper function that does this check and use it instead of the regular function if the programmer used some #define. Like an optional debug version… but then you probably weren’t counting on that so it might be too much work.

  4. Yeah I know for the flickering issue. It’s not a bug in the library, it’s the way the sample is coded : each frame, I add a random value to the corner colors between -3 and 3. When one of the r,g,b component goes beyond the 0-255 range, it wraps (because it’s an uint8). This results in a sudden color change. I have to find a better way to randomize the colors to avoid this.

    Concerning the coordinate check, I don’t think it will have a noticeable impact on the performances. On another hand, if you have a crash each time you write out of the console, you will detect more easily bugs in your code. If I do the check and simply clamp the string, the bug will remain unnoticed…