Trying to understand the Angband 3.X source code

[Magnate]

I want Angband to always be playable on the Linux console in GCU mode, so I would oppose any change that makes an 80x24 main screen unplayable (or really, worse than it currently is). Beyond that I'm not invested in what the default sizes are--if main-win (or main-sdl or main-x11) had other defaults it wouldn't bother me.

Seconded. I don't even mind if the default moves beyond 80x24 for GUIs, as long as -mgcu still works.

[nppangband]

Seconded. I don't even mind if the default moves beyond 80x24 for GUIs, as long as -mgcu still works.

Thanks. I noticed in the changelog some more player status was worked into the screen, and I was wondering where they were fit in, since pretty much every bit of space is already being used on an 80x24 screen.

I also a couple other long-standing Angband coding conventions for the sake of very old operating systems that might have been removed for the sake of progress....such as the 16 color limit, and I think I saw some #includes that C uses to calculate non-integer math, which about 10 years ago still was not done in Angband due to the problems with the earliest pentium chips). I was wondering if the standard screen size may have been increased as well.

The Angband community remains one of the most helpful and mature groups on the internet. Thanks all.

[d_m]

I also a couple other long-standing Angband coding conventions for the sake of very old operating systems that might have been removed for the sake of progress....such as the 16 color limit, and I think I saw some #includes that C uses to calculate non-integer math, which about 10 years ago still was not done in Angband due to the problems with the earliest pentium chips). I was wondering if the standard screen size may have been increased as well.

Right, there are now something like 32 colors, but they have 16 color mappings for people who don't have that many (in fact, Angband still works without colors on e.g. vt100).

I think I know which C code you mean... it's code to be used by developers in debug mode, but isn't used by the actual game. I think Angband is still playable on systems without floating 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.

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

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

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

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

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]

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