How do I actually use libtcod?

[Scottbert]

So awhile back, I mentioned I had an idea for a roguelike. (http://forums.roguetemple.com/index.php?topic=4477.0) Now I've finally gotten around to trying to learn libtcod, and... hoo boy.

I haven't done c++ coding in awhile and I don't know python, so I go to jice's c++ tutorial (http://codeumbra.eu/complete-roguelike-tutorial-using-c-and-libtcod-part-1-setting-up).

I install orwell dev-c++, but getting it to work is a pain and even when pointed at the library what seems to be properly, it won't compile. I decide to use a more direct toolchain.

I install MinGW (the latest 32-bit version, of course) and compile the 'test if things are installed' program from the first tutorial chapter.

Of course, MinGW turns out to be bugged (http://sourceforge.net/p/mingw/bugs/2108/), but this just means having to click a button a few times every time I compile something. Okay, I can deal.

The program doesn't open a window or anything. But hey, jice explains how to debug c++ programs!

gdb reveals that my program is segfaulting because of some problem with the library.

Jice doesn't explain how to use the debug libraries, but I can figure it out. Now, recompile and have a look...

J:\dev\proto>gdb tuto
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from J:\dev\proto\tuto.exe...done.
(gdb) run
Starting program: J:\dev\proto/tuto.exe
[New Thread 14144.0x2964]
[New Thread 14144.0x1098]
24 bits font.
key color : 0 0 0
character for ascii code 255 is colored
Using SDL renderer...

Program received signal SIGSEGV, Segmentation fault.
0x65e70d9f in TCODConsole::clear (this=0x1) at src/console.cpp:196
196     src/console.cpp: No such file or directory.
(gdb) bt
#0  0x65e70d9f in TCODConsole::clear (this=0x1) at src/console.cpp:196
#1  0x0040149b in main () at src/main.cpp:15
(gdb) q
A debugging session is active.

        Inferior 1 [process 14144] will be killed.

Quit anyway? (y or n) y
error return ../../gdb-7.6.1/gdb/windows-nat.c:1275 was 5

A search of the internet reveals that this happens to a lot of people, and seems to be the result of my MinGW version not being an exact match for the one the library was compiled on, which makes me wonder why binaries of the library are being distributed at all.

J:\dev\proto>g++ -dumpversion
4.8.1

Okay. Since I have the latest MinGW version, I'll just grab the latest, nightly build of libtcod 1.5.2

No dice, same error.

Okay. so I need to build the library myself. fine. There are instructions: (http://roguecentral.org/doryen/data/libtcod/doc/1.5.2/html2/compile_libtcod_mingw.html?c=true&cpp=true&cs=true&py=true&lua=true)

'which' doesn't do anything, which is hardly a surprise at this point, but I can just run hg from the windows command line.

Finally, once I have the source for libtcod, I get into a MingW shell, go to the directory, and make it as instructed.

The MinGW error box pops up twice for every .c or .cpp file, but I'll endure.

$ make -f makefiles/makefile-mingw
Compiling debug src/bresenham_c.c
Compiling debug src/bsp_c.c
Compiling debug src/color_c.c
Compiling debug src/console_c.c
Compiling debug src/fov_c.c
Compiling debug src/fov_circular_raycasting.c
Compiling debug src/fov_diamond_raycasting.c
Compiling debug src/fov_recursive_shadowcasting.c
Compiling debug src/fov_permissive2.c
Compiling debug src/fov_restrictive.c
Compiling debug src/heightmap_c.c
Compiling debug src/image_c.c
Compiling debug src/lex_c.c
Compiling debug src/list_c.c
Compiling debug src/mersenne_c.c
Compiling debug src/noise_c.c
Compiling debug src/parser_c.c
Compiling debug src/path_c.c
Compiling debug src/sys_c.c
Compiling debug src/sys_sdl_c.c
Compiling debug src/sys_sdl12_c.c
Compiling debug src/sys_sdl_img_bmp.c
Compiling debug src/sys_sdl_img_png.c
Compiling debug src/tree_c.c
Compiling debug src/txtfield_c.c
Compiling debug src/wrappers.c
Compiling debug src/zip_c.c
Compiling debug src/namegen_c.c
Compiling debug src/bresenham.cpp
Compiling debug src/bsp.cpp
Compiling debug src/color.cpp
Compiling debug src/console.cpp
Compiling debug src/fov.cpp
Compiling debug src/heightmap.cpp
Compiling debug src/image.cpp
Compiling debug src/lex.cpp
Compiling debug src/mersenne.cpp
Compiling debug src/mouse.cpp
Compiling debug src/noise.cpp
Compiling debug src/parser.cpp
Compiling debug src/path.cpp
Compiling debug src/sys.cpp
Compiling debug src/sys_opengl_c.c
Compiling debug src/txtfield.cpp
Compiling debug src/zip.cpp
Compiling debug src/namegen.cpp
Compiling debug src/png/lodepng.c
Compiling zlib src/zlib/adler32.c
Compiling zlib src/zlib/crc32.c
Compiling zlib src/zlib/deflate.c
Compiling zlib src/zlib/infback.c
Compiling zlib src/zlib/inffast.c
Compiling zlib src/zlib/inflate.c
Compiling zlib src/zlib/inftrees.c
Compiling zlib src/zlib/trees.c
Compiling zlib src/zlib/zutil.c
Compiling zlib src/zlib/compress.c
Compiling zlib src/zlib/uncompr.c
Compiling zlib src/zlib/gzclose.c
Compiling zlib src/zlib/gzlib.c
Compiling zlib src/zlib/gzread.c
Compiling zlib src/zlib/gzwrite.c
c:\MinGW\bin\ar.exe: creating lib/libz.a
Linking libtcod-mingw-debug.dll
Compiling debug src/gui/button.cpp
Compiling debug src/gui/container.cpp
Compiling debug src/gui/flatlist.cpp
Compiling debug src/gui/hbox.cpp
Compiling debug src/gui/image.cpp
Compiling debug src/gui/label.cpp
Compiling debug src/gui/radiobutton.cpp
Compiling debug src/gui/slider.cpp
Compiling debug src/gui/statusbar.cpp
Compiling debug src/gui/textbox.cpp
Compiling debug src/gui/togglebutton.cpp
Compiling debug src/gui/toolbar.cpp
Compiling debug src/gui/vbox.cpp
Compiling debug src/gui/widget.cpp
Linking libtcod-gui-mingw-debug.dll
Compiling release src/bresenham_c.c
Compiling release src/bsp_c.c
Compiling release src/color_c.c
Compiling release src/console_c.c
Compiling release src/fov_c.c
Compiling release src/fov_circular_raycasting.c
Compiling release src/fov_diamond_raycasting.c
Compiling release src/fov_recursive_shadowcasting.c
Compiling release src/fov_permissive2.c
Compiling release src/fov_restrictive.c
Compiling release src/heightmap_c.c
Compiling release src/image_c.c
Compiling release src/lex_c.c
Compiling release src/list_c.c
Compiling release src/mersenne_c.c
Compiling release src/noise_c.c
Compiling release src/parser_c.c
Compiling release src/path_c.c
Compiling release src/sys_c.c
Compiling release src/sys_sdl_c.c
Compiling release src/sys_sdl12_c.c
Compiling release src/sys_sdl_img_bmp.c
Compiling release src/sys_sdl_img_png.c
Compiling release src/tree_c.c
Compiling release src/txtfield_c.c
Compiling release src/wrappers.c
Compiling release src/zip_c.c
Compiling release src/namegen_c.c
Compiling release src/bresenham.cpp
Compiling release src/bsp.cpp
Compiling release src/color.cpp
Compiling release src/console.cpp
Compiling release src/fov.cpp
Compiling release src/heightmap.cpp
In file included from src/heightmap.cpp:27:0:
c:\mingw\include\math.h: In function 'float hypotf(float, float)':
c:\mingw\include\math.h:635:30: error: '_hypot' was not declared in this scope
 { return (float)(_hypot (x, y)); }
                              ^
make: *** [/tmp/libtcod/release/heightmap.o] Error 1

WELL F***.

So, as far as I can tell, trying to use libtcod from publicly available information is simply a no-go. This toolchain is f*cked and I cannot believe anyone actually uses it this way -- I must be doing something very wrong.

So, how do I actually use libtcod? Or does noone use it anymore and I need to find something else?

[Scottbert]

Fix provided by barf_ on #rgrd:

See this bit of the error message:

c:\mingw\include\math.h:635:30: error: '_hypot' was not declared in this scope
 { return (float)(_hypot (x, y)); }
                              ^
Just change it to
 { return (float)(hypot (x, y)); }

As for the annoying messagebox, I fixed that by downgrading to an earlier version of gcc and g++.

[chooseusername]

Yes, all your problems are created by mingw.  It used to be solid as a rock, now it bobs and weaves like a turd on the waves created by the people at the public pool trying to swim away from it.

I personally, install VS2013 community edition, and have my own nmake makefile for it.  My own program compiled separately in VS links against it, and finds the source via the PDBs, so I get the full power of the VS debugger.

[Cfyz]

I too recommend using Visual Studio, if you can. Its debugger is awesome.

However, the remark about MinGW right above is not just. The thing is, MinGW is not a concrete product, it is more of a system. Take a look at MinGW page in Qt wiki, it gives a quick overview of different MinGW flavours and provides links to reliable ones.

And I can not pass an opportunity to remind that when it comes to pseudoterminal output, there is a BearLibTerminal alternative to libtcod.

[Krice]

Yes, all your problems are created by mingw.

You mean gcc? I've always thought it's better than VC's compiler. There are some differences in C libraries, but in most cases those can be changed depending on which compiler is used, using #ifdef blocks. When people say there is something wrong in the compiler they actually mean there is something wrong in their source code, they just can't admit it. Or they don't know it.

[chooseusername]

Yes, all your problems are created by mingw.

You mean gcc? I've always thought it's better than VC's compiler. There are some differences in C libraries, but in most cases those can be changed depending on which compiler is used, using #ifdef blocks. When people say there is something wrong in the compiler they actually mean there is something wrong in their source code, they just can't admit it. Or they don't know it.

Read the full post I replied to.  A bad mingw install (and by that I mean anyone who would have installed it would have ended up with similar problems) was the cause of it.  mingw is a buggy unreliable piece of garbage.  It never used to be that way, but it became that way over time.  I used to be able to compile the Python programming language under mingw and run the full test suite with same behaviour as I would see on Linux or under Visual Studio.  But over time, mingw deteriorated.

[TheCreator]

Use Visual Studio. It has the best debugging facilities ever created by man, while GNU tools can't even display contents of a string properly. Remember that debugging is 90% of a programmer's work. Slight compiler differences, even if they speak in favor of the GNU stuff, will never compensate an inferior debugging system.

[chooseusername]

Use Visual Studio. It has the best debugging facilities ever created by man, while GNU tools can't even display contents of a string properly. Remember that debugging is 90% of a programmer's work. Slight compiler differences, even if they speak in favor of the GNU stuff, will never compensate an inferior debugging system.

I was thinking about it, and it's the user friendliness that makes the difference.  Visual Studio just seems to provide a simple, yet capable and featureful, interface to debugging.  Somehow these qualities are never quite cloned into open source, without losing what makes it so smooth and easy to use.

However, if Casey Whatshisface from Handmade Hero is to be believed, Valve are on the job and are funding some uber-Linux debugger that'll finally make debugging on Linux a pleasure.

[Krice]

Remember that debugging is 90% of a programmer's work.

Well, I almost never use debugger and the reason for that is following strict rules in programming and using C++ (OOP) features. Debugger is useful I guess if you're clueless with traditional C. VC's debugger (and the integration to IDE) is better than gdb.

[mushroom patch]

Not having any use for a debugger is more often a sign of doing only trivial programming than having incredible programming discipline.

[vultures]

Codeumbra has this great multi-part article about RLs,
"Complete roguelike tutorial using C++ and libtcod"

This article is the first part of a series heavily inspired by Jotaf's excellent "Complete roguelike tutorial using python + libtcod".

It is intended for C++ beginners and people who want to learn how to use libtcod to create a simple roguelike video game. It covers both Linux and Windows operating systems.

[ahnlak]

Not having any use for a debugger is more often a sign of doing only trivial programming than having incredible programming discipline.

Ha! That was my thought, too. In a quarter century of coding, the only times I haven't used a debugger is when I've been in environments that don't have them.

Sure, you can work without them but why the hell would you - it drastically reduces the amount of time you spend hunting down bugs.

[Krice]

Sure, you can work without them but why the hell would you - it drastically reduces the amount of time you spend hunting down bugs.

I don't hunt down bugs, I know where they are. Kaduria has 49K lines of code and 5 open bugs and I know where they are. The thing is that you can easily take out 90% of memory corruption bugs with strict constructor-destructor and ownership rules (and not using raw arrays). You simply don't produce those bugs anymore, so you don't have to hunt them down with debugger. There are bugs after that, but mostly you know exactly where they are even without debugger.

[TheCreator]

I don't hunt down bugs, I know where they are. Kaduria has 49K lines of code and 5 open bugs and I know where they are. The thing is that you can easily take out 90% of memory corruption bugs with strict constructor-destructor and ownership rules (and not using raw arrays). You simply don't produce those bugs anymore, so you don't have to hunt them down with debugger. There are bugs after that, but mostly you know exactly where they are even without debugger.

It's very easy to keep bug count that low when your game is not released to the public. Make it available and you'll have bugs.

[Cfyz]

Edit: I'm lost with this discussion a bit. Did topic starter figure out how to use libtcod ot not?

All this MinGW bad, MinGW trash irritates me in some illogical way.

A bad mingw install was the cause of it.  mingw is a buggy unreliable piece of garbage

There were three problems in the OP: a certain bug, library binary incompatibility and undeclared function symbol.
1. I hope no one really thinks that MSVC does not have bugs. All major compilers/IDEs have them in multitude, sometimes quite severe ones (MSVC examples would be invalid constructors generated, messed argument forwarding, high_resolution_clock having milliseconds resolution, etc.). The bug in the OP is fairly regular and have obvious workaround.
2. Binary incompatibility is how C++ works. It is a fairly common knowledge that you cannot mix object files and libraries build by different compilers or even compiler options. This applies to both MinGW (see wiki) and MSVC (see SO). Edit: that's why BearLibTerminal uses dynamic linking with pure C API.
3. _hypot function that fail compilation is the most fair complaint. Scottberd must have stubled upon a link to some random or outdated MinGW build (like the one in the tutorial). It's like Linux with numerous distributions, takes some time to figure out and is the weakest part of MinGW community IMO. Use TDM build, it is a fairly sure bet and was one for quite a time. Or consult Qt wiki. Also you should not think MSVC cannot choke on this just because underscored versions are also from MS.

GNU tools can't even display contents of a string properly

Well, they can, from some time ago. It requires some additional configuring to enable so it's not quite there yet, but situation is improving.

Visual Studio just seems to provide a simple, yet capable and featureful, interface to debugging.  Somehow these qualities are never quite cloned into open source, without losing what makes it so smooth and easy to use.

Lots of people are surprised to find out Unix IDEs have visual debugger tools too. For the most part it is on par with MSVS, at least under Linux, but under Windows its 'native' debugger is superior.

The thing is that you can easily take out 90% of memory corruption bugs with strict constructor-destructor and ownership rules (and not using raw arrays). You simply don't produce those bugs anymore, so you don't have to hunt them down with debugger. There are bugs after that, but mostly you know exactly where they are even without debugger.

Ignorance is bliss, they say. Incorrect type sizes resulting in incorrect arithmetic, wrong function called with wrong argument passed, incorrect evaluation and initialization order dependencies, honest misprints, control flow errors, various things in external library internals, a certain OS version acting up. Pour in a few dozens of threads for good measure. I wish I could use debugger more often, with high load server-side I usually get some logs and one or two undamaged core dumps, if lucky.