Quote Originally Posted by AthenaOfDelphi
If the list is unsorted, it does indeed use a sequential search, but my understanding is that if the list is sorted, it uses binary chop. The unit I posted speeds this up by replacing the slower ansiCompareText function with plain old compareText which is faster because it doesn't take into account unicode (IIRC).

Obviously adding items to a sorted list is slower, but if you can add all the items and then sort (during a level/map load for example), you may notice a good performance increase.
Actually I've already optimized Delphi AnsiCompareText and CompareText methods with PChar based assembly versions that are MUCH faster. In fact my AnsiCompareText is faster then the default CompareText (thats what direct memory and assembly can do for you).

Unfortunately sorting would really slow things down. In the end I've moved to pointer management instead of string management. This gives an almost 1:n improvement in speed. In fact my lookups are now at 1.2 average (the .2 comes from when a sprite type has never been used before). Guess thats an advantage to a scripted engine, I can change to pointers w/o changing anything else.

Before I was pulling about 120 fps and now I'm back up to my approved 230 fps. While the engine is locked at 20 fps the higher fps makes sure it works on slower and lower end machines. I do wish that the judges would post up info on how each run went and what the average fps produced was so we could benchmark against something .