Is there any kind of real difference between using a truth state variable and using a table of “flags” to determine whether something is true or not? There’s obviously a lot more code involved in using a table, and I can’t imagine that there would be a performance increase for looping through table rows versus grabbing the boolean value of a single variable.
As it stands, I’m leaning toward truth state variables because I still haven’t come to grips with the way tables are created or referenced. Can someone who knows more about this kind of thing (which is pretty much anyone) weigh in on the pros and cons?
If it helps you feel better, I can wander in and demonstrate how much less I know at any time. Just gimme a buzz.
I would expect a truth state variable to be easier AND faster than a table of flags, unless you had a large number of truth states that were closely related enough that they could all be processed with a loop.
I’ve run into this same issue.
I use many truth state variables, and I tried the whole Table idea.
I ended up iterating over the table dozens of times each turn and even though tables are supposed to be fast, there is no replacement for direct access.
Correct me if I’m wrong, but wouldn’t implementing a bunch of truth state variables eat up a lot more precious dynamic memory than implementing a table?
Dunno. Doesn’t seem like it should. I don’t know of a way to test it, either.
I only mention it because I had this problem with lists vs. tables; but I’m not sure whether truth state variables are allocated memory similarly to lists in inform. Mind you, booleans shouldn’t really cost that much anyway; you would need very very many of them to make it a problem.
Well, the problem with lists is apparently that Inform doesn’t know how long they’re going to be at compile-time, so it allocates a lot of memory to each list at startup. (See here.) That doesn’t seem like it should be an issue with booleans.
Oh right. I started that thread but some of the info musta fell out. knocks head Thanks for the reminder, Matt.