Compiling with VS2015

[t4nk]

Just to be a little constructive: I actually have a little experience in converting an existing code base from C to C++ and it does actually work out pretty smoothly[1]

Interesting! I skimmed some files; the codebase is still very C-like (at least the parts that I saw). Well, that's not necessarily a bad thing

I actually thought seriously about using D "back in the day", but honestly: At the time it was extremely niche, but even today it's (unfortunately) still quite a niche language.

So what, it's just Angband

Overall I do think that D might be a better language if you want to do metaprogramming

Nah, what I want is automated garbage collection (apparently that's coming to C++... at some point), Unicode in standard library, faster compile times...

[Pete Mack]

The first one to separate spell effects was Andrew Doull (Unangband.)

[Derakon]

The first one to separate spell effects was Andrew Doull (Unangband.)

It's sad that we have so much duplication of effort in Angband and its variants.

[AnonymousHero]

[I]

It's sad that we have so much duplication of effort in Angband and its variants.

Such is the life of a maintainer.

EDIT: I was going to do a whole "janitor"/"maintainer" analogy here, but... meh.

[Pete Mack]

The improved data model for parsing makes all the difference.

If you look at the code, there's a tiny core in initialization and effect_do, and a lot of busywork (cut and paste of effects from original code, and cut and paste of projection side effects.) Using unanband would have cut busywork only slightly--you still have to verify the list of effects for V.

[Nick]

It's sad that we have so much duplication of effort in Angband and its variants.

I used to think that, but I see it as more like an ecosystem now. As a maintainer it's great to have so many variants around to steal ideas from. So the process of a maintainer developing their ideas, and then others copying it doesn't just give a chance for all the variants to improve, but in the end it probably ends up with better implementations.

That's especially the case for "creative" ideas, but I think it also is for coding techniques (sorry, I English bad today). There's also the thing that Angband and variants have such a broad design space that you can do things like wilderness or randarts in many, many different ways.

[Siemelink]

MSVC doesn't have stdbool.h
You can write your own, then add -I. to the compile line.
http://stackoverflow.com/questions/5...s2010-question

Angband has h-basic.h, which defines bool as well:

/* Use a char otherwise */
typedef char bool;

#undef TRUE
#undef FALSE

#define TRUE 1
#define FALSE 0

#endif

replacing the typedef with #define bool char seems to recover bool.

But the order of includes seems off. get.h gives errors in the getset definition, bool is not defined. I can add #include "h-basic.h" in get.h to get a bit further.

Then I am stuck on item_filter, which is not defined anywhere, in any file.

bool get_item(struct object **choice, const char *pmt, const char *fail, cmd_code cmd, item_filter filter, int mode);

Confusion reigns!

[Pete Mack]

get.c, line 54

[takkaria]

Your problem is that you shouldn't be compiling get.c or get.h, they're not used. They should be removed, I think that's my fault that they're still there.

[Siemelink]

Your problem is that you shouldn't be compiling get.c or get.h, they're not used. They should be removed, I think that's my fault that they're still there.

Oh, that made a difference!
Now I only have one more nut to crack, a linker error:

unresolved external symbol _FreeDIB referenced in function _Term_xtra_win_react

Neither of those keywords means something to me.

Willem.

[takkaria]

Oh, that made a difference!
Now I only have one more nut to crack, a linker error:

unresolved external symbol _FreeDIB referenced in function _Term_xtra_win_react

Neither of those keywords means something to me.

Willem.

You might need to include win/readdib.c if it's there as a file to compile.

[Siemelink]

You might need to include win/readdib.c if it's there as a file to compile.

Thanks again. I had the file included but for unknown reason WINDOWS was not defined. So the whole file was commented out with #ifdef. I fixed this by adding #include "h-basic.h"

So finally, I can compile without error. The game runs, I can start new or load a save file. I have the main window and the subwindows. But as soon as a dungeon is generated, the game crashes.

I still have a compiler warning on the code below: Expected an expression. This probably means that the array is expanded as {}

static const char *desc_stat_pos[] =
{
#define STAT(a, b, c, d, e, f, g, h) f,
#include "list-stats.h"
#undef STAT
};

The warning goes away if I expand this by hand.
static const char *desc_stat_pos[] =
{
"strong",
"smart",
"wise",
"dextrous",
"healthy"
};

I see that the method to define an array using an #include is repeated aplenty. Expanding everything by hand would be a mess, so now my next quest is to configure this code for the funky compiler.

Willem.

[Pete Mack]

Rather than including basic.h, add /DWINDOWS to the compile options.

[t4nk]

static const char *desc_stat_pos[] =
{
#define STAT(a, b, c, d, e, f, g, h) f,
#include "list-stats.h"
#undef STAT
};

static const char *desc_stat_pos[] =
{
"strong",
"smart",
"wise",
"dextrous",
"healthy"
};

It's probably trailing comma? Note that macroexpanded code looks like this:

        ...
	"dextrous",
	"healthy", /* the comma */
};

[Siemelink]

It's probably trailing comma?

Yes.
When I compiled the snippet separately I could get the warning and also the correct contents from the array.

Willem.