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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 3:07 AM > To: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
