Trying to understand the Angband 3.X source code

[nppangband]

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.

LCC-Win 32, but I don't think that is the problem. The most current NPP is based on Angband 3.0.6, and I am dropping in Angband code from the latest release. With the re-writing of all the main.xxx files, the list of things that are #defined or #undef are completely different. I believe I am missing a #defined or there is an extra #undef that needs deleting. The fact that I am getting a compiler warning that bool is defined twice tells me I need to have to check this, file by file.

Does anyone have any recomendations for a good, free C compiler if LCC-WIN is the problem? My biggest limitation is that I am not a true programmer who could work off of a C:\ prompt. It would have to be a windows environment.....

[d_m]

In C, -1 has a two's complement binary representation as "1111111...." for whatever size integer you're talking about. If you cast it to (char) like Pete did, you end up with "11111111" in binary, which is 0xFF in hex, and 255 in decimal.

I think you're confused... in C the char datatype is always defined as one byte. If you want to represent a unicode character you'd use a different type. (char)-1 == (char)255 is invariant.

[ekolis]

-1 == 255? Maybe in byte-land, but what if you're using multi-byte character sets (Unicode)?

[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.

[nppangband]

'\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.

[d_m]

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]

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?

[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]

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.

[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]

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.

[Magnate]

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.

[zaimoni]

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.

[PowerDiver]

Most likely I can't help, but would you try temporarily changing that line to

const char *close = strstr("", "");

and see what error you get? Also, double check that there are only variable declarations from the start of the function to that point.

[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.