Trying to understand the Angband 3.X source code

[zaimoni]

Originally Posted by nppangband

What compilers take the Angband source cleanly?

I have built it on MingW32 by removing the --std=c99 option. I'm pretty sure both GNU make and BSD make work when coordinating build with GCC.

MSVC and OpenWatcom are both fails currently, due to change-for-the-sake-of-change directory structure reorganizations throwing off nmake and wmake respectively. I believe that both will work if the directory structure is re-flattened for platform-agnostic files.

[Magnate]

Originally Posted by nppangband

I have made good progress in making all the changes from 3.06 to 3.2.2, but now I have some code from Angband 3.1.2 that simply won't compile for me (using LCC-win-32).

It is in util.c, in the function next_section (which is called only once, by text_out_e). ABout 10 lines into the function there is this stretch of code:

const char *close = strstr(s, "{/}");


I get multiple errors, which are making no sense...first off this line:

const char *close = strstr(s, "{/}");

It says I don't have a prototype for strstr, but string.h is included, and it gives no warning for the many other times in the source this function is called.

it also gives an error for having an operand with 'pointer to char' and 'int'

Does anyone have any suggestions?

My compiler also hates this line in inkey_aux, giving the message "incorrec char constant".

/* End "macro action" */
if ((ch == 30) || (ch == '\xff'))

What compilers take the Angband source cleanly? I am getting an awful lot of errors and compiler warnings from lcc-win. It doesn't seem to like the revised Angband source at all.

Thanks for any help or sugestions anyone may have.

Hmm. I suspect the next_section code is quite new, as an attempt to deal with overly long text output. If you're adept with svn you can find the commit which introduced (or last modified) it and contact the committer. (It wasn't me, so if it's less than 18 months old it must be takk, d_m or MD.)

I think most of the still-active developers use gcc (~minGW on Windows), which would explain why support for other compilers is so bad. Sorry.

[nppangband]

Found the problem......it was with LCC-win. Once I reinstalled it, all the strange compile errors went away. Thanks again.

And I apologize to the Angband source for all the bad things I said about it in the last 24 hours.

[nppangband]

Oh, one last thing. LCC-win comes very close to compiling the latest Angband source release (v3.1.2 2?), but it fails because there are two files names util.c (one in the src directory, one in src/player), and it won't make .obj files for both of they. Perhaps the duplicate file names in the various subdirectories of src (such as types.h, util.c) should all have unique names?

[nppangband]

Things are coming along well now. I have most of the code compatible from main-win.c, the util.c file, all the helper files, and the z-*** files. Now the code is dropping in nicely & the compile errors are less and less frequent....

One thing that it doesn't recognize is some of the mouse commands. An example is line 1005 from util.c

if ((ch == 30) || (ch == '\xff'))

I know the "\xff" part has to do with reading an entry from the mouse, but where is that defined so the game understands it. I have button.c in there, and I have checked all the help files, but I don't see where the game should understand what that means.

As always, thanks for any help anyone can offer.

[Nick]

It's defined as the key for a mousepress in Term_mousepress in z-term.c, and Term_mousepress is called from all the main-xxx.c files as how the game responds to a mouse click from the operating system. What the game does with it is then defined by do_cmd_mouseclick in cmd0.c.

If I'm wrong, someone will correct me.

[nppangband]

Nick - thanks. I will check into that when I get home.

Does the game know what '\xff' means, or does that have to be defined somewhere? Or is it like a keypress, where the game knows that 'y' and 'n' equate to the player pressing the y and n keys?

[d_m]

Originally Posted by nppangband

Does the game know what '\xff' means, or does that have to be defined somewhere? Or is it like a keypress, where the game knows that 'y' and 'n' equate to the player pressing the y and n keys?

'\xff' is (or should be) a character constant, kind of like '\n' or '\011'. In this case it's the number 255, aka 0377 in octal notation, aka 0xFF in hex notation.

[nppangband]

Originally Posted by d_m

'\xff' is (or should be) a character constant, kind of like '\n' or '\011'. In this case it's the number 255, aka 0377 in octal notation, aka 0xFF in hex notation.

I checked everything out, and all the necessary code is there. It gives me a warning when I try to save any file that has '\xff' in it. The warning is "incorrect character constant"

I guess I can just change it to 255.

My best guess is that I have inconsistent #define related to an operating system (for example, I get a compiler warning that bool is defined twice in h-basic.h, even though it is the exact same as the file as in the current Vanilla source). My other guess is that a variable in the current Angband source is defined differently than in the old source (many variables that were defined as cptr in Angband 3.0.6 are classified as char).

I will look for it once I get all the new code in and I can get the source to compile without errors.

Thanks again for the suggestions.

[Pete Mack]

What compiler are you using that complains about '\xff'? That is bog standard (char)-1
encoding.
Anyway, you are right, making it a #define constant is the right thing to do in any case.