Messages

166

Programming / Re: Getting C++ working with libtcod

« on: July 22, 2014, 10:59:25 AM »

Does my choice between 32 and 64 bit make a significant difference? I'm always tempted to choose 64-bit options, but sometimes that seems to cause issues.

Does not matter nowadays. All of the modern MinGW builds are dual "multilib" and capable of producing both 32 and 64-bit executable. Bitness of MinGW build indicates which one is default but you always can force another by adding -m32/-m64 compiler switch to the command line.

Will the installation from that alone be enough for a fully functional mingw?

Normal MinGW installation should be self-sufficient. However, try not to keep multiple copies unless you know what you are doing. MinGW installation is perfectly usable as long as its 'bin' subfolder is in the PATH, but having multiple compiler builds in the PATH at the same time may screw things up.

Edit: a fully functional MinGW will not be enough to build libtcod, you will also need Cygwin.

I tried using it with MSYS grabbed from the older mingw folder, but it seemed to be missing important things.

I'm not sure what you call MSYS exactly (the definition of this component is a bit vague) but I strongly suggest you do not mix parts of different builds. If not sure, remove everything and unpack a fresh copy.

Don't make it too complicated. Install Code::Blocks with mingw (you should learn to use IDE) or Visual C++ free edition.

Code::Blocks does not rely on compiler to be bundled with it. It has builds with MinGW included (right now it is TDM 4.7.1 and 4.8.1) but I think knowing the line between the IDE and the compiler may help a lot. As far as I can tell, we are not doing "hello world" here.

Visual Studio Express for Windows Desktop (that is how free Visual C++ is called nowadays) is a valid choice too. If anything, it has awesomely integrated debugger. It is very different though, with its own rules, quirks and bugs. And I may be a bit on the subjective side, but I believe that starting from Dev-C++/Code::Blocks/Eclipse + GCC will be better in the long run.

However, none of the alternatives mentioned above would fix the original problem about linking with libtcod. Yet they might have made fixing it harder. Maybe I'm missing something, but as far as I can see libtcod has very unfriendly building mechanics. It practically requires MinGW with Cygwin, because versions newer than 1.5.1 have only makefiles and those makefiles rely on unix utilities.

Then, if some crappy library doesn't work, don't use it.

Yeah, use BearLibTerminal: linking is trivial, supports both MinGW and Visual C++ and does not require any recompiling :-P.

167

Programming / Re: Getting C++ working with libtcod

« on: July 21, 2014, 08:23:19 PM »

I've tried to link that tutorial against libraries included in 1.5.2 release archive using several of MinGW builds (somehow I've collected quite a number of them). All of the attempts (mingw-builds or TDM, 32 bit or cross-64 bit, sjlj or dw2) gave the same result as your first one: segfault on TCODConsole::clear. Linking against manually compiled libtcod works fine though.

168

Programming / Re: Getting C++ working with libtcod

« on: July 21, 2014, 07:58:39 PM »

A good overview of different MinGW flavours and options can be found at Qt wiki.

I think you should pick any of EH variants (does not make much difference for simple programs; I use SJLJ) and posix thread model (because C++11 is awesome).

169

Programming / Re: Getting C++ working with libtcod

« on: July 21, 2014, 02:28:38 PM »

as I only had a vague idea of where things were coming from...TCODConsole::root appears to be given an address to point to, but I only slightly recognize what's going on there.

There is a static variable defined at the top of the src/console.cpp:

Code: [Select]

TCODConsole * TCODConsole::root = NULL;And TCODConsole::initRoot is a very thin wrapper around C version:

Code: [Select]

void TCODConsole::initRoot(int w, int h, const char *title, bool fullscreen, TCOD_renderer_t renderer) {
TCODConsole *con=new TCODConsole();
TCOD_console_init_root(w,h,title,fullscreen,renderer);
con->data=TCOD_ctx.root;
TCODConsole::root=con;
}It just allocates a new TCODConsole instance and assigns its address to the static 'TCODConsole::root' variable mentioned above. Which makes calling the TCODConsole::clear method on NULL pointer virtually impossible. Even if a logic error happens during console initialization, that root variable will still be assigned some valid memory address.

So, recompiling libtcod myself is unlikely to fix my problem, but I should update mingw to deal with that bug either way?

There are two mostly unrelated problems. First one (SIGSEGV while running a compiled application) is IMO caused by some compiler/library incompatibility. The other one (unknown type name 'off64_t' while compiling libtcod) is clearly a MinGW bug and it has been fixed for a while now. It is good idea to update compiler anyway. And no, I believe recompiling libtcod should fix your original problem.

Also, are you saying that having a library that's compiled with a different version of the same compiler that you're using will often cause problems? That really sounds like it could be a hassle...

Yes, it is a hassle indeed. There is a brief explanation on MinGW wiki. Note that this problem (mostly) does not exist for C. If you use C version of libtcod API, you should be okay. BearLibTerminal API was also deliberately kept to a bare minimum (a few C calls) so that interoperability will not become a problem.

170

Programming / Re: Getting C++ working with libtcod

« on: July 21, 2014, 10:29:26 AM »

I'm starting to think that this is maybe a mingw thing? Here's the bit that went wrong:

Code: [Select]

c:\mingw\include\io.h:301:1: error: unknown type name 'off64_t'

Indeed this was a bug in MinGW. First try to update MinGW and simply link against the regular 1.5.2 libtcod. I recommend mingw-builds releases.

That might not work though. The point about recompiling libtcod is that with C++ it is often important to use same compiler version and build for both application and libraries it is linking against. Usually it is easier to just recompile everything with your own compiler than keep matching library builds. Note that recompiling libtcod from the code repository (because regular release archives do not include makefiles) will get you the 'trunk' version, not 1.5.2 (but should not matter).

I can confirm it is possible to compile that tutorial, albeit with some nuances. I've used MinGW 4.8.1 from mingw32-builds and libtcod code right from the repository, but had to modify the makefile a bit:
1. Change 'CC' and 'CPP' variables from 'mingw32-gcc' and 'mingw32-g++' to simple 'gcc' and 'g++' because that is how compiler binaries are named (are these longer names from the old Cygwin packages?).
2. Manually specify 'TEMP' variable because 'make' from my Cygwin installation failed to create files in /tmp folder (what the?).
After that libtcod and tutorial are compiling and executing okay.

171

Programming / Re: Getting C++ working with libtcod

« on: July 21, 2014, 01:03:01 AM »

Code: [Select]

0x65e70d9f in TCODConsole::clear (this=0x1) at src/console.cpp:196
196     src/console.cpp: No such file or directory.

TCODConsole::clear method is located at line 196 in libtcod version 1.5.1, so the binary (.dll) library must be from 1.5.1 release. However, that release does not include MinGW libraries (libtcod-mingw[-debug]). Yet gdb cannot find src/console.cpp file implying you did not compile those libraries yourself. Which becomes really confusing: where did you get your libtcod-mingw-debug.dll from? Also, "this = 0x1" indicates  that TCODConsole::clear has recevied totally wrong object pointer. Usually it happens when you call a method on non-exising object (which should not be the case here) or when linking against a library has gone haywire.

I suggest you delete your current libtcod (and all traces of it) and try to unpack a clean 1.5.2 release. If that will not help, try to build the library as described here:
http://doryen.eptalys.net/data/libtcod/doc/1.5.2/html2/compile_libtcod_mingw.html
Note that you do not have to use the exact MinGW version mentioned on that page. When you're compiling library yourself you are fine as long as you're using the same version for everything.

On a side note and as an act of self-advertisement, I think you may find interesting an alternative output library called BearLibTerminal.

172

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: July 14, 2014, 12:27:17 PM »

Contrary to how it might look, the project is alive. Not very popular though, but oh well.
Version 0.10: http://foo.wyrd.name/en:bearlibterminal#download

I did try to make SDL-based window implementation but somehow it resulted into a mess. SDL is good, robust library when you start from it and build your app around its infrequient quirks. However, integrating it into project (half of which functionality is window management) halfway is not as simple as it seems. I've found myself working more against SDL than with it. Therefore, Mac port is delayed for now.

Instead I've refactored the input subsystem (which was a mess by itself) a bit and implemented a couple of new features. Nothing really breaking, though.

1. Minor adjustments in constants naming like TK_PAGEUP or TK_MOUSE_LEFT instead of WinAPI-legacy TK_PRIOR and TK_LBUTTON. Constants related to mouse or numpad are now grouped together: TK_MOUSE_xxx, TK_KP_xxx.

2. Input event categories are removed. There was an input.events option before which allowed to 'subscribe' on keypresses or keyreleases or mouse with somewhat inconsistent mechanics. For example, TK_CLOSE is better not to be ignored (what category it is?), same with TK_RESIZED. And actually there is no real difference between keypress and keyrelease for application as user always can press a whole lot of random buttons you will have to ignore anyway. So now the read function does read everything (like GetMessage, ha), you just have to handle only those events you're interested in.

3. Next is read_ext. A thing with somewhat obscure logic. It was introduced because it was necessary to read both event scancode and character code produced by that event: terminal_read_ext(TK_READ_CHAR). Ugh, somehow it did not fazed me in the slightest that there was already mouse events where you can read both the event and mouse properties at the same time: via terminal_state(TK_MOUSE_xxx). Therefore, the read_ext is removed and two new states are introduced: TK_CHAR and TK_WCHAR. They simply return the code of a character produced by the latest read input event, or zero if none was produced:

Code: [Select]

int key = terminal_read();
if (key == TK_ESCAPE)
{
   return;
}
else if (terminal_state(TK_WCHAR) > 0)
{
   str += (wchar_t)terminal_state(TK_WCHAR);
}TK_WCHAR returns an Unicode codepoint of the character and TK_CHAR return an ASCII/ANSI codepoint translated accordingly to the codepage selected with the terminal.encoding option.

There was also non-blocking input via read_ext but it can easly implemented without additional API methods:

Code: [Select]

// Both literally,
int key = terminal_has_input()? terminal_read(): 0;

// ...and logically
while (terminal_has_input()) {
   int key = terminal_read();
   ...
}Oh, there is also TK_EVENT that will return a scancode of the last dequeued input event.

4. Mouse input has been extended. There are new TK_MOUSE_X1 and TK_MOUSE_X2 buttons which are additional buttons on some mouse models. There is new TK_MOUSE_CLICKS state that return a number of fast consecutive clicks by the time of the last dequeued mouse button event. E. g. terminal_state(TK_MOUSE_CLICKS) == 2 indicated that this TK_MOUSE_LEFT event is the second one in double-click action.

Also, TK_MOUSE_WHEEL now returns scroll delta instead of some global counter.

5. You can press Alt+Enter to switch between windowed and fullscreen mode (with no display resolution change). The window.fullscreen option may be used to force the fullscreen mode programmaticaly.

6. You can press Alt+[plus/minus] to scale the window up and down. This may be useful if some application uses tiny tileset and you want to run it on FullHD+ display. For now it is done via simple OpenGL scene scaling. Later I'll try to take advantage of shaders where they are supported. But you cannot scale resizeable window (window.resizeable option) as it would allow for a number of difficult configuration cases I'm not yet sure how to deal with.

7. There is also a couple of debug key combinations: Alt+G will turn on cell grid and Alt+A will dump the texture atlas on disk.

The up-to-date reference on the input subsystem is located here: http://foo.wyrd.name/en:bearlibterminal:reference:input

173

Programming / Re: Which language and library to use

« on: July 07, 2014, 04:51:31 PM »

Well, overuse of inheritance is a fairly common mistake:
Stack Overflow: Prefer composition over inheritance?
MSDN blogs: Seven deadly sins of programming - Sin #2
Herb Sutter: Uses and Abuses of Inheritance, Part 1

That said, the inheritance (multiple or not) is not an evil by itself, yet adds more flexibility. This way, for example, C++ had its own "default methods" long before those were deemed necessary and introduced in Java 8 (i find ironic the fact modern Java does have kind of multiple inheritance now).

174

Programming / Re: How to avoid trashing what you've already written?

« on: July 07, 2014, 11:32:30 AM »

There is a fairly well-known article that fits the discussion: Things You Should Never Do, Part I.

175

Programming / Re: Which language and library to use

« on: July 04, 2014, 05:08:39 PM »

Totally agree with Bear.

From my experience, I've seen a lot of students struggle similarly with arrays. At start it feels complicated with all these matrix and cube and whatnot analogues, full of nuances of unknown importance like which dimension stored first and which of them can or cannot be of different size. But given just a bit of practice this suddenly becomes totally obvious to the point of not being worth mentioned.

Also, modern C++ brings memory control on a bit higher level allowing to express/enforce memory ownership right in the code.

176

Design / Re: I added a new monster, any ideas or feedback? (post your new stuff too)

« on: May 27, 2014, 02:29:36 PM »

IRL plants do grow/replicate themselves as much as they can -- which usually limited by suitable soil and/or man-made structures.

Maybe you can make fungus grow only over specific floor type and thematically/strategically distribute this floor type over the level? E. g. it can grow all it want at the left side of the room with a very important door because there is a fountain in that corner.

177

Design / Re: Good way to do 8-directional movement with WASD

« on: May 22, 2014, 04:00:53 PM »

Using several modifiers or rotating 45 degrees seems a bin non-intuitive to me. Maybe, combine keys if some modifier is pressed? This way with W or D you move up or right when button is pressed, but with Shift+W+D you move up-right when Shift is released (or when two keys have been pressed). IMHO this is easier to grasp, like basic and extended movement modes.

178

Programming / Re: Oh boy, adventures in rebinding variables!!! (Python)

« on: May 20, 2014, 03:28:46 PM »

Second variable x gets bound to five.  Now, I though that with a pointer, a new hash value was generated for a new memory address, and that address just stored the location of the first memory address and told the computer to look there next.
<...>
With what I understand a pointer to be (and I may be totally wrong) is one address that just contains instructions which 'point' the program to another different address, but with what seems like it is happening in python, there is only one address that both variables refer to.

The numbers you observe (hashes and hypothetical memory address) are actually the result of an optimization and not the optimization mechanism itself. When you ask for the second variable's properties, interpreter silently follows all those internal pointers and gives you the final result. Therefore for external observer it looks like two variables are the one and the same.

Also, do not confuse Python variables and real memory blocks. In lower-level languages like C they are the same thing. In higher-level languages variable is more like a wrapper around some object and may have very complex relation to actual memory. There is no reason for some variable to point to another variable's data indirectly. Because variable and it's data are not the same here, both variables may just directly point to same data.

179

Programming / Re: Multithreading

« on: March 26, 2014, 11:52:38 AM »

I think there are ways to make pathfinding works asynchronous. In general, you'll just have to make it possible for creature to start moving without full path available. For example, the background task may update creature's path at some intervals, i. e. creature will start in some general direction and then correct its way once or twice. Most likely it wont get too far by the time calculation is done (so error will be negligible) but this might increase responsiveness greatly and scale pretty well.

As for parallel A* I think this specific case will not benefit much. The reason is in such game there will be not one huge task but whole lots of small ones. If tasks do not sleep/wait much, there is no benefit in using more threads than number of CPU cores because all cores will be fully loaded with work anyway. It might seem that task may be calculated two times faster by dividing the work between two cores, yet actually this will also cut the number of simultaneously calculated tasks in half. On a large amount of CPU-bound tasks parallelizing will not help because average processing time will stay the same.

180

Programming / Re: A guide to using a scripting language in games

« on: March 20, 2014, 09:12:32 AM »

AFAIK, the names you use to call Lua functions (pure lua or exposed from C) are tied to actual function definition at runtime. You can assign completely different functions to the same name during execution, e. g. alternating between several implementations, therefore no tool can check validity of the call beforehand.