tiny little unimportant DJA bug that's been bugging me

[will_asher]

There's a very unimportant bug that's been getting on my nerves and it involves a piece of code which is gibberish to me so I'm asking for help:

The "C" line in p_race text lists recommended classes for that race. The recommended classes show up in a brighter color in the birth menu, but this doesn't work. No recommended classes below the alchemist (class index 7) ever show up in a brighter color.

The relevant piece of code (I think) is this little function in birth.c

/* CLASS */
static void display_class(menu_type *menu, int oid, bool cursor,
							int row, int col, int width)
{
	byte attr = curs_attrs[0 != (rp_ptr->choice & (1L << oid))][0 != cursor];
	c_put_str(attr, c_name + c_info[oid].name, row, col);
}

I have no idea what (1L << oid) means so I can't fix the bug.

I looked in init.c where it reads the C: line in p_race.txt and it uses a similar thing:

		/* Hack - Parse this entry */
		pr_ptr->choice |= (1 << atoi(s));

Does this put a limit on how many C: entries there can be?
"atoi" isn't defined as a function anywhere so I assume it's an innate C thing that I haven't learned.

[d_m]

Here's the idea:

1 << 1 == 2
1 << 2 == 4
1 << 3 == 8
...
1 << 8 == 256

the "L" means that 1 is long, so it has more bits. This is important because if you shift the bit over too far it will fall off the end (I think).

Also, atoi is translating a string representation of a number into an int.

atoi("10") == 10
atoi("3") == 3

Hope this helps.

[PowerDiver]

Originally Posted by will_asher

I looked in init.c where it reads the C: line in p_race.txt and it uses a similar thing:

		/* Hack - Parse this entry */
		pr_ptr->choice |= (1 << atoi(s));

Does this put a limit on how many C: entries there can be?

That's the bug. For some absurd reason, there are lots of things defined as bytes or chars that should not be. That variable is only 8 bits, so if you have more than 8 choices it will not work.

The simple change is to define choice to be a different size, say unsigned int, but that may break savefile compatibility if the value is written and reloaded from the savefile.

[d_m]

Originally Posted by PowerDiver

That's the bug. For some absurd reason, there are lots of things defined as bytes or chars that should not be. That variable is only 8 bits, so if you have more than 8 choices it will not work.

Angband does *love* bit-encodings. I guess 640k should be enough for anyone, huh?

[will_asher]

Thanks, it works as it should now.
BTW, 'choice' isn't used in savefiles, but I've already broken savefiles in other ways.

[PowerDiver]

Originally Posted by d_m

Angband does *love* bit-encodings. I guess 640k should be enough for anyone, huh?

It's one thing to try to save space in a structure that is used 1000 times. But to worry about space in a variable that is only used once is insane. It makes more sense to use a long than a byte if you think anyone might ever want to extend things in the future.

[Magnate]

Originally Posted by PowerDiver

It's one thing to try to save space in a structure that is used 1000 times. But to worry about space in a variable that is only used once is insane. It makes more sense to use a long than a byte if you think anyone might ever want to extend things in the future.

Don't forget the age of the codebase. Angband wasn't written from scratch - I'm not even sure if Moria was, but even if it was we're talking mid-eighties here. In those days you saved space in every variable, however rarely it was used.

[konijn_]

Originally Posted by Magnate

Don't forget the age of the codebase. Angband wasn't written from scratch - I'm not even sure if Moria was, but even if it was we're talking mid-eighties here. In those days you saved space in every variable, however rarely it was used.

Plus, bitflags are inherently cool

T.