Right, more fun redundant code from the master of timewasting.

Flag Handling Beta

In Sully:

int grueFlags[1000];

In Parallel 7:

#define maxflags 	1000


int flag[maxflags];

In Duskbane:

int flags[100];

In Milk:

int nFlags[100];

Basically, all this redundant data, for what is pretty much just a bool, was offending my sensibilities. So I wrote some bitwise flag handling. Now you can have 1000 flags for the price of 32, and 100 for the price of 4. (Yes, I know a few ints aren't really that important... but I CARE)

So, you don't set a value anymore (and flags are bool only - use multiples for more complex situations), but there are four simple functions to deal with them, for each you pass a flag number:

int FlagLook(int flgl_num) // Returns 1 if the flag is on, 0 for off


void FlagSet(int flgs_num) // Sets a flag to true


void FlagClear(int flgc_num) // Sets a flag to false


void FlagToggle(int flgt_num) // Toggles the value of a flag

I'd recommend having a big list of flag defines, with the name explaining the situation of each flag, so you don't forget what each number does.

Zip

Man, you're (as in 'you are', rather than the possesive 'your', or the noun 'yore', or the film 'Yor') talking to the guy who made a define for minus one here. The brain knows, but the heart don't care.

Zip

or don't: weeee!

Way back in the day I also thought this would be a good idea. Like the v2 day. I forget why I never created a flag system based on string handles.

I, or anyone really, could probably whip up a functional system with a fair modicum of foolproofing to avoid some potentially clumsy situations involving misspelling ;)

Using numbers and a list of flag defines is preferable in my book, as any errors the compiler will spit at you, rather than just doing funky shit in game.

#define FLAG_REACHED_4LVL 22





if (FlagLook(FLAG_REACHED_LVL4)) ... // Compiler spits

However:

FlagSet("Reached level 4");


...


FlagLook("Reached 4th level"); // Always returns false in game

Add spelling errors, case sensitivity and the rest, I see a world of pain if the number of flags gets large. Plus the fact that the set/check would be far more complicated, and probably require a tree.
With this system, you can just have one header file with all your flags neatly listed, and it's just as clear what the flag does.

Zip

Yeah, but I'm used for mockery for doing silly things. I did thoing about the multiple state thing, but decided the how point of a flag was you can do a basic true/false query on it. Anything requiring multiple states should have extra flags instead:

#define FLAG_DAVE_MET 56


#define FLAG_DAVE_JOIN 57


#define FLAG_DAVE_LEFT 58

Or something...

Zip

Rights for machines! They have feelings too! Anyway, I disagree, the debug of string would easily lose any time you gained by not typing a few defines. A bool is a bool, making it a string just causes all sorts of complications you shouldn't have to face. Sure, a nice text dump would be a bonus, but far from a clinching feature. Feel free to write one if you want though - I'm bored of defending such a chuck-away project.

Zip

Quote:Originally posted by resident


Meh, you could trap that pretty easily at startup - just check to see if there are any flags checked that have never been defined. Anything that's never been defined is probably an error, and should be reported.

Yes, that'd be about the long and short of it.

Cue the debate on exactly when you should stop optimising your code and how convenient a game should be to make.

Bitshifting and whatnot is all good and well but NOTHING beats the convenience of "flag[22] = 1;". I mean, it's less than ten LETTERS for chrissake, plus easy to remember and a DODDLE to check for errors. Zip, there is such a thing as trying too hard, dude!

Human resources are much more valuable than machine resources. :)

If the computer has to do more work, so be it. Easy way, all the way.