Date: Thu, 30 Nov 1995 14:21:27 -0500 From: Robert Stratton <strat@INTERPORT.NET> >I've got a question for the list. I've found situations where preloadCast >does absolutely nothing. As in preloadcast 1, 300 does not preload squat. >As we are working on improving Director, I am interested in finding out if >anyone else has run into anything similar? My setup appears to be system >7.5.1 related. Setup follows: Mac 6100av and 7100. Director partition >16M, at least 8M free, (404), system 7.5.1, movie 40M of internal casts @ >several linked sounds. What is happining is that preloadcast for a range >does nothing even though there is enough freeBlock to accomidate any >castember. Individual preloadcast commands such as preloadcast 2 work.I've read a bunch of responses to this post and wanted to throw my two cents in. In previous CD projects I've completed I have noticed that the preloadCast command DOES preload a range of castmembers when called on my test machine (at the time a MacIIfx) when I did a test with the traceload on. I noticed that it didn't seem to work on my test PC. On the Mac, I preload some castmembers, go to a frame with only those castmembers, and the jump is instantaneous. The same exact code on the PC caused the hard disk access light to go nuts while the animation paused and (I assume) the castmembers where *really* loaded into RAM.
I attended Terry Schussler's Lingo Seminar a couple of days ago and he said that the preloadcast command does not work if there is not enough free memory to load the castmember. In other words Director will not unload anything to make room for the castmembers you are preloading with the preloadcast command. I assume, Alex, you know this, but I took an informal poll of developers I know and none (like me) realized this! I thought about all the preloadcasts I sprinkled into my last CDs and realized, since the Director partition probably fills up pretty quickly when playing the CD, all these commands are USELESS! I don't want to unload or unloadcast because I like the fact that the last "page" is "cached" so that the user can go back to the last screen with a high probability that the castmembers in that screen are still in RAM. The only way to keep this functionality is to track the castmembers for every screen in lists so that you can juggle loading, unloading and calls to the freebytes or freeblock to really manage memory correctly. Terry showed an intricate system he has used to do such a thing, which I thought was a pretty amazing piece of Lingo, but I assume this management requires a tremendous amount of overhead during runtime, not to mention coding, debugging and testing time during development. In other words, I think the situation SUCKS.
The funny thing is that Director's internal memory management seems to me to do some things that are exactly what I'm looking for. Terry told me that Director does use an algorithm to unload castmembers that takes into account both purge priority and (within the same levels of priority) the relative length of time since the loaded castmembers have been used. In other words you partially control what stays in RAM by setting the purge priority of castmembers and after that Director tends to purge things that haven't been imaged in a while. The first part lets you weight what you think are the important, high frequency castmembers during development and the second part is a like a better than average "guess" that Director can do internally about which castmember to unload in a situation where the purge priorities are equal.
I want some of this functionality in Lingo commands to preload castmembers strategically without having to build a really complex memory management system. This is my suggestion: create a Lingo command called something like freeMem that takes an integer argument of the amount of bytes you want Director to free up for you. Director then analizes the castmembers in RAM just like it does when you go to a new frame and RAM is full. Purge priorities and time-since-used are weighed and Director unloads the amount you asked for. Since this is done internally by Director in the case of imaging new frames when RAM is full, it should simply be a matter of giving a Lingo hook into this functionality. You would *then* have a useful, easy (since it doesn't involve a complex Lingo-based meory tracking engine), fast (since it is done internally by Director) way to manage memory in a way that satisfies the most common scenarios. And here is such a scenario:
I want to preload an animation that starts in frame 20 while the user is reading something in frame 10. I determine the ramNeeded to image those castmembers (or I do some math with the size of cast function if there is some puppeting involved). I determine the freeblocks. I freeMem for the difference. I preload the new castmembers. Voila!