Pros and cons of where to store image data

[Chipp Walters]

Peter,

If I were building a Myst style game, I think I would try the following:

I would use a single stack with X number of cards-- with X being the max
number of branches you can go to from any card. For instance, if you could
only go to 3 places at first, but later on go to 12 places, I would create
12 + 1(the card you're on) cards in the main stack.

Then, create an array containing all PLACES and the user's current position
in the game. When you are in PLACE A (card A), you know which other places
you can access from there, along with the filenames of the images which
would go on those cards. The array would also contain the hotspots to take
you there  (I'd build a small hotspot utility to generate the hotspot
list -- hotspots could be invisible polygons and generated on the fly on
OpenCard.)

There would be a blank image placeholder on each card, and you can set the
filename of each image in a background process which starts as soon as you
go to a PLACE(card). In the case the image is not yet loaded (such as a fast
clicker), a preOpenCard handler would know this and interrupt the background
process and immediately fetch the image before showing the card.

This has the speed advantage you would want, along with keeping the memory
requirements low. I would sketch this out, build a demo stack and check the
performance before creating a full version.

Also, you may wish to consider using JPG files at half resolution -- they'll
load fast and scale nicely at 2X. You could of course have a preference
setting to use the 1/2 scale JPG or full scale JPG files. Store each set in
different folders.

Good luck!

best,

Chipp

> -----Original Message-----
> From: use-revolution-admin at lists.runrev.com
> [mailto:use-revolution-admin at lists.runrev.com]On Behalf Of
> peter9.smith at ps.ge.com
> Sent: Wednesday, September 17, 2003 3:07 AM
> To: use-revolution at lists.runrev.com
> Subject: Re: Pros and cons of where to store image data
>
>
> Thanks for the helpful responses on this.  My potential aim is to do a
> simple non-commercial Myst style game.  As you move between the
> rooms of the
> game the game needs to load up the images for the room being
> moved into, and
> unload images for some other room based on a caching algorithm.
> My current
> thinking is to have each room as its own stack embedding the images into
> them.  Room state will be maintained in a central stack.
>
> I don't think I can do this for sounds and movies so they will have to be
> external files (you can't have multiple embedded sounds playing?)
>  I'll need
> to find out how one writes Revolution code and distributes such external
> file resources with tne built application.
>
> Thanks, Peter Smith.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>