Speeding up this handler

[Scott Rossi]

Recently, Shari wrote:

> I'm trying to shave the first handler down to about 150 milliseconds.
> Handler 2 was just a test to see how quickly Metacard could set the
> filename of 99 images.  I've tried several variations, but so far the
> 620 is the fastest, but it isn't fast enough.
> 
> Imagine a grid of images, and at any given time, you need to take the
> info from a non-contiguous block of these images, and use their
> filenames to set another block of images.  So you have a huge square.
> And with this handler, you carve out a square from inside the bigger
> square.

I assume the code you posted relates to a tile-based game that you've
mentioned previously on the list.  IMO (could be wrong), setting filenames
of so many images to external references will never be fast until everybody
is running a minimum of 5GHZ machines.

If possible, you might want to consider a "holding bay" approach to handling
your images and see if it runs any faster.  Create two sets of objects: a
"master set" of image objects which is located offscreen or in a substack,
and a "slave set" of button objects which is the grid of images the user
actually sees.  At startup (or between game levels or other times that
loading would be acceptable), set the filenames of the master images as
needed before actual game play.  When it comes time to display the level,
set the icons of the slave buttons to the IDs of the master images.

I don't know if the setup of your game lends itself to this arrangement, but
the theory is that setting the icons of buttons to internal image references
may be faster than setting the filenames of images to external file
references.

-----

On a different note, does your game require scrolling?  I'd be interested to
know how your app performs when scrolling 99 objects.  I remember doing
game/scrolling experiments years ago in SuperCard, and trying to move groups
of image objects around inside a smaller window.  It worked, but the
performance was nowhere near acceptable commercial game quality.  I wound up
creating a "jump" treatment for the background: when a character moves from
one screen to another, the background instantly updates with a new image, as
opposed to continually scrolling the background to match the character's
position.

Regards,

Scott Rossi
Creative Director

Tactile Media, Multimedia & Design
Email: scott at tactilemedia.com
Web: www.tactilemedia.com