Trying to understand the Angband 3.X source code

[Derakon]

You can freely resize all of the windows in Vanilla and they'll make use of the extra space (or try to fit themselves in tighter).

[Pete Mack]

@jeff --
check out the make include files. (Makefile.src, Makefile.inc)
This is a much better model for maintaining dependencies.

Also, V does support small screen mode, but not to the extent that FA does.
One well-known player (Psi) plays FA on a small screen almost exclusively.

Also, the various ui fixes (menus, cmd0.c, cmd-know.c, etc) are supposed to make porting easier, not harder. If this is not the case, we've done something wrong.

[nppangband]

Pete - I am sure it will be easier, once I understand it. You all have done a fine job. Everything I know about C and programming I learned from reading & working with the Angband source code, so all the code cleanup you all have done are completely new concepts to me. My NPP co-developer Diego is the true programmer who usually does the heavy lifting when it comes to new ideas. I usually work on incorporating ideas from other variants, where I have somebody else's written code as a starting point. So I will spend a couple weeks poking around the new Angband source, RTFM, and ask questions and then hopefully I will understand it enough to fully incorporate it into NPP.

But the quests, 4gai and Unangband terrain projects required a re-write of more than half the source code. I will definitely be quicker and easier to put the Angband ui improvements into NPP and then gradually change the code so that it is current with the latest Vanilla releases.

[PowerDiver]

Originally Posted by nppangband

Has anyone ever decided to make the default screen size a little bit larger?

I usually resize my window to cover most of the screen. Others leave room for secondary windows for monster lists etc. Ever since the detection spells were changed to areas independent of the screen size, it is not abusive, so it seems like the obvious thing to do.

[d_m]

Originally Posted by nppangband

One quick question (since you mentioned small screen support). Is Angband still married to a default 80x24 screen support?

Has anyone ever decided to make the default screen size a little bit larger?

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.

[Magnate]

Originally Posted by d_m

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]

Originally Posted by Magnate

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]

Originally Posted by nppangband

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.