George Greer wrote: > > That function is awful for modifying. Note however, that in two recent posts about people modifying that function, they both initially got the mod right for that function, the problem for both of them was in the #defines, they just thought that that function was the problem because that's where the compiler was stopping. The change you made would not have affected them but it may just confuse newbie coders who are trying to follow the older snippet since the snippets will no longer show the correct way to modify the function. <snip> Hrmmm, looks easier to modify, but I can't help thinking there's gotta be a cleaner way to do all that. I'm wondering if the test can be bitvectorized to be able to combine all the testing into one... This is more somethign to ponder over and maybe has out the possibilities on than a real suggestion, as noted at the end of this post it's really not feasable to do (unfortunately). Okay, let's look at what we're comparing... The ITEM_ANTI_* stuff are part of a bitvector, they start at 13 for MAGIC_USER and goto 15 for WARRIOR. The IS_* tests all look like this... (!IS_NPC(ch) && GET_CLASS(ch) == CLASS_WHATEVER) Here at least we can save some CPU by doing the IS_NPC test once at the beginning instead of once per class. If we line up the CLASS_ members with the ITEM_ANTI_ members we can even get away with a simple bitvectorized comparision, something like this... if (!IS_NPC(ch) && IS_SET((obj->obj_flags.extra_flags / ITEM_ANTI_MAGIC_USER), (1 << GET_CLASS(ch))) return 1; return 0; Note that the / ITEM_ANTI_MAGIC_USER part will line up the obj flags so that it corresponds with the class number. This does make for a more efficient test, unfortunately we can't use it (arrgh!). The reason is simple, you can't add more classes and have them remain sequential without shifting ITEM_NOSELL (which would trash the object files). So I guess all this post is for nothing *sigh*. So why did I post it in the first place? Because it might be something to consider if you ever decide that trashing the object files is necessary for a different reason. It would work especially well if you want to move the ITEM_ANTI flags off to thier own separate bitvector in which case you could just force them to line right up with the classes. Regards, Peter -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/04/01 PST