Author Topic: How do I actually use libtcod?  (Read 34958 times)

Krice

  • (Banned)
  • Rogueliker
  • ***
  • Posts: 2316
  • Karma: +0/-2
    • View Profile
    • Email
Re: How do I actually use libtcod?
« Reply #15 on: March 31, 2015, 10:59:04 AM »
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.

Current release of Teemu has I think two gameplay bugs and apparently couple of memory leaks according to some guy that ran it through Valgrind (in linux as the source code is available). The current development version is I think even better, although it has more source code (with potential bugs). It's not yet ready, but when it is I guess I'm releasing the source code as well so you can all check out for bugs! Isn't it exciting?

TheCreator

  • Rogueliker
  • ***
  • Posts: 370
  • Karma: +0/-0
    • View Profile
    • Fame
    • Email
Re: How do I actually use libtcod?
« Reply #16 on: March 31, 2015, 12:39:39 PM »
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.

Sure I know this stuff (what other choice do I really have if I need to debug my game on Linux?) , but it is still *very* far from the comfort VS has been offering since forever. STL has became a part of the standard back in 1994 (please correct me if I'm wrong), now we have 2015 and "situation is improving" does not make me a happy GCC user at all :).
Fame (Untitled) - my game. Everything is a roguelike.

ahnlak

  • Newcomer
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: How do I actually use libtcod?
« Reply #17 on: March 31, 2015, 02:50:22 PM »
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.
Then I admire your programming prowess. A rate of 10k lines / bug is ... remarkable.

For us mortals, however, debuggers are useful tools.

mushroom patch

  • Rogueliker
  • ***
  • Posts: 554
  • Karma: +0/-0
    • View Profile
Re: How do I actually use libtcod?
« Reply #18 on: March 31, 2015, 03:27:11 PM »
Mushroom patch simulator has 185K lines of code and only one bug. I know where the bug is, but I follow the practice of ancient Persian carpet weavers by leaving one knot untied, because if I tied that last knot, my creation would be perfect.

Krice

  • (Banned)
  • Rogueliker
  • ***
  • Posts: 2316
  • Karma: +0/-2
    • View Profile
    • Email
Re: How do I actually use libtcod?
« Reply #19 on: March 31, 2015, 03:57:19 PM »
It's mainly OOP that reduces bugs for me. But no matter what the language is the most important realization is that you as a programmer will create bugs. There is no way to prevent that, but you can decide what kind of bugs you create by looking at the way you handle memory management etc. And returning to actual topic it's the programmer's job trying to make C or C++ source code as standard as possible. I've found a great way to achieve that by making my source codes compile in both VC and GCC at the same time. That way you can't have any excuses for it not working in one of the most standard compilers there are.

AquaTsar17

  • 7DRL Reviewer
  • Rogueliker
  • *
  • Posts: 57
  • Karma: +0/-0
    • View Profile
Re: How do I actually use libtcod?
« Reply #20 on: March 31, 2015, 08:56:43 PM »
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).

Actually, no. That particular bug was found in January 2015. If you use the latest version of MinGW, you have to deal with this bug. You're fine if you use an older version, but good luck finding a reliable place to download such things. This bug caused me a huge headache at the end of the 7DRL challenge, since I couldn't compile libtcod properly without fixing it. There's a workaround here for it: http://ehc.ac/p/mingw/bugs/2250/

Right now, the problem with libtcod is that you pretty much need to compile the library on your own to guarantee it will work. Once you do the workaround for compiling the library, the existing tutorials are pretty much sufficient. However, I've found that the tutorials for it tend to be unreliable because it encourages you to use the latest version of MinGW and stuff like this happens...

Omnivore

  • Rogueliker
  • ***
  • Posts: 154
  • Karma: +0/-0
    • View Profile
Re: How do I actually use libtcod?
« Reply #21 on: March 31, 2015, 09:32:20 PM »
Right now, the problem with libtcod is that you pretty much need to compile the library on your own to guarantee it will work. Once you do the workaround for compiling the library, the existing tutorials are pretty much sufficient. However, I've found that the tutorials for it tend to be unreliable because it encourages you to use the latest version of MinGW and stuff like this happens...

That is far from the only problem with libtcod.  While I applaud Jice for making it available years ago, and I assume it is/was  undoubtedly a good solution to the needs of Doryen, as a general purpose lib today it has a huge number of shortcomings.  The least of which is that the last stable release is dated August, 29 2012.  A much bigger problem that has existed since its initial release is that it attempts to do way too much and, as a result, has a ton of cruft that is only usable in specific, narrow, use case scenarios.  Add in the toolchain issues we have fought with for the past twenty years in the pursuit of portable C++ code and heh... much of this thread is illustrative.

I do believe we need new tutorials using narrowly scoped, modern, solutions, but... I'm not volunteering.  There are way too many bad practices being encouraged these days and, frankly, the definition of roguelike has long past veered into the land of the lost and meaningless.  As a point, personally I consider the entire 7DRL concept to be encouraging of bad practices in programming and design, so anything I would write would have zero appeal to those who disagree.

Cfyz

  • Rogueliker
  • ***
  • Posts: 194
  • Karma: +0/-0
    • View Profile
    • Email
Re: How do I actually use libtcod?
« Reply #22 on: March 31, 2015, 11:35:31 PM »
Quote from: AquaTsar17
That particular bug was found in January 2015. If you use the latest version of MinGW, you have to deal with this bug. You're fine if you use an older version, but good luck finding a reliable place to download such things.
Can you describe what and where from had you downloaded to get such version? Out of all MinGW-related builds I am aware of (vanilla MinGW, MSYS2, MinGW-w64 and its personal builds, mingw32-builds and TDM; please share if you know something else worth noticing) I see only MSYS2 having something from this year, all others provide releases from late 2014 or earlier. And MSYS2 is not a complete MinGW build, it is an environment to help using an exising MinGW-w64 installation. Edit: I've realized you refer to the time bug was found. Any links?

4.8.1 and 4.9.2 from TDM and mingw32-builds (most recent available), with and without MSYS2 do build libtcod cleanly. Well, aside from ming32-builds not providing aliases hardcoded in jice's makefiles, just change 'mingw32-xyz' to 'xyz'. And for reliable places to download, I've pointer that a few times: start from Qt wiki. TDM-GCC and mingw32-builds provide stable 4.8 and 4.9 builds and will continue to do so for some time.
« Last Edit: March 31, 2015, 11:52:42 PM by Cfyz »

vultures

  • Newcomer
  • Posts: 33
  • Karma: +0/-0
    • View Profile
    • The Causeway
    • Email
Re: How do I actually use libtcod?
« Reply #23 on: April 01, 2015, 12:08:00 AM »
Quote from: Omnivore
That is far from the only problem with libtcod.  While I applaud Jice for making it available years ago, and I assume it is/was  undoubtedly a good solution to the needs of Doryen, as a general purpose lib today it has a huge number of shortcomings.  The least of which is that the last stable release is dated August, 29 2012.  A much bigger problem that has existed since its initial release is that it attempts to do way too much and, as a result, has a ton of cruft that is only usable in specific, narrow, use case scenarios.  Add in the toolchain issues we have fought with for the past twenty years in the pursuit of portable C++ code and heh... much of this thread is illustrative.

I do believe we need new tutorials using narrowly scoped, modern, solutions, but... I'm not volunteering.  There are way too many bad practices being encouraged these days and, frankly, the definition of roguelike has long past veered into the land of the lost and meaningless.  As a point, personally I consider the entire 7DRL concept to be encouraging of bad practices in programming and design, so anything I would write would have zero appeal to those who disagree.

That's a nice thing bubbling in your sig. :)
Infra Arcana is a great game.

Whilst reserving your methods in order to make them current at some point, there is a lively thing going on regarding those few notches down the timescale. There is a fact, to be honest, that says how devs (and programmers in general) find their pioneering efforts most admirable at some point. Kinda loosenes 'em up, gives em' a big grin - if you know what I mean. :)

Now, I know how getting tough on all those malpractices certainly brings things up into perspective or at least makes you less self-aware, being that humans make mistakes.. and altough, for my part, I never liked things I couldn't finish - it all seemed quite simple upon reminescing. Even though a mere make-believe fail-attempt makes you frown once or twice, it actually brings you closer to the sense of achievement where perfection is more hard-earned, and less stumbled upon, vaguely embraced...

Be it somehow you agreed or disagreed, even flaws in foundations have their positive perks. And the simple things such as coding style, pseudo-programming guidelines or naming conventions - they all bring one's wisdom to our grasp, and even better if the practice is condoned by many. IMO, struggling with styles and specific workarounds when using a library of choice for developing a RL game for a challenge such as 7DRL is a sign of inexperience, nothing more. Remembering how making a RL is all about the attempt to create your own game brings up the simple truth which repeats itself through our programming endeavors, which is - errors are bound to happen.

Seeing that the year 2015 has started with some really good efforts from the community which I've been a fan of since, yeah, as long as I knew what OOP was made me enthusiastic on many levels. Upon seeing how players who've never asked what a RL game is venture into a procgen dungeon I found most assuring the thought of RL community getting better by the day. The errors, seen as mere obstacles that had to be crossed made me believe once again that coding RL games isn't a skillset that's either not there or it's witheld, but more of an art-form - a choice of deliberance to make a computer game as you imagined it.

AquaTsar17

  • 7DRL Reviewer
  • Rogueliker
  • *
  • Posts: 57
  • Karma: +0/-0
    • View Profile
Re: How do I actually use libtcod?
« Reply #24 on: April 02, 2015, 12:53:50 AM »
Can you describe what and where from had you downloaded to get such version?

All I did was: uninstall and remove my previous version of MinGW, get the latest version from http://sourceforge.net/projects/mingw/files/ using the "latest version" link, used the downloader to install it, used MSys to download the latest version of the source for libtcod (likely 1.6.0), and tried to build it. I only ran into the compile problem mentioned by OP, and did the workaround suggested in the link (added a compiler flag to the libtcod makefile), and then had no problems.

My comment about older versions of MinGW stem from me trying to find particular versions of it when I suddenly have an urge to program C/C++ after a year or three of not doing anything. I've resigned myself to just using the latest version, which isn't necessarily bad. I just found this particular bug with MinGW most annoying/amusing since I just noticed it on the final day of the 7DRL challenge.

Cfyz

  • Rogueliker
  • ***
  • Posts: 194
  • Karma: +0/-0
    • View Profile
    • Email
Re: How do I actually use libtcod?
« Reply #25 on: April 02, 2015, 10:32:57 PM »
Quote from: AquaTsar17
get the latest version from http://sourceforge.net/projects/mingw/files/ using the "latest version" link
Well, that one is somewhat close to "random, outdated build" I mentioned earlier, though I did not think things stayed this bad. Unfortunately (and very counter-intuitively), MinGW build found at mingw.org is barely useable at most. And as far as I remember it was this way, but with alternative builds evolving, the difference between a proper build (there are at least two) and the 'vanilla' one became disheartening. It may be worth trying to contact mingw.org to make them include a brief overview of current situation at least.

MinGW from mingw.org (sf.net/projects/mingw) provides a version capable of compiling 32-bit binaries only. It does not let to choose exception mechanic. It uses win32 thread model so no C++11 threading support. The latest GCC version is 4.8.1 dated 2013 (there are 4.8.3 and 4.9.2 already). It uses fairly random packaging overall: _hypot is a problem present in mingwrt-3.21, which is somehow newer than mingwrt-4.0.3 (one with correct hypotf). And their repository is a mess. *deep sigh* MinGW as a project became better, but its titular instance did not.

Once again, just in case someone might stumble upon this, at this time proper builds are MinGW-w64/mingw-builds (joined recently) and TDM.
« Last Edit: April 02, 2015, 10:36:49 PM by Cfyz »

Scottbert

  • Newcomer
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: How do I actually use libtcod?
« Reply #26 on: April 03, 2015, 10:27:20 PM »
Turns out the binaries I compiled with _barf's suggestion were bizarrely buggy. The 'check if a key was pressed' function zeroed some variables when it detected a key press. I never did figure that out.

The eventual solution was just to use mingw-get to downgrade gcc and g++ to 4.6.2 and use the precompiled 1.5.1 source. This seems to be a stable solution.