6 Replies Latest reply on Sep 13, 2011 10:55 AM by Adam-C

    D11.5 Unload

    edb00 Level 1

      I'm still having trouble with a D11.5 projector and memory management on Mac OSX Snow Leopard and Lion after importing data.

       

      calling unload() does not clear enough memory for Director to keep in memory the globals I have created for the project.

      The only errors are when trying to access the globals that should be there.

      There are no errors while creating those globals.

      The movie must have a preload() in the start or there will only be black screens after the import.

       

      I have resorted to a script that opens a new movie closing the current movie after the data import. The data is processed and saved in cast members.

      The new movie simply opens the original movie.

      Now all the globals are constructed from stored cast members and the project functions properly.

      Of course the opening and closing slows things down and looks lame.

       

      This project system had worked until now through D9 - 10 MX with no problems.

       

      Thanks

        • 1. Re: D11.5 Unload
          Adam-C Level 2

          calling unload() does not clear enough memory for Director to keep in memory the globals I have created for the project.

          What are you storing in your globals to make them so huge that they overflow your system memory?

          • 2. Re: D11.5 Unload
            edb00 Level 1

            At first I thought it was the creation of many (2000 or so) cast members some with 1-2 MB of text.

             

            But after triming down my import to just a few and then just two student records it seems like just creating as few as 50 new cast members with minimal text causes problems.

             

            Anything that was not loaded before the import will not load afterward -- ie I preload the movie to be able to even see the graphics on various screens.

            But some variables have to be created using the loaded cast members text and they just don't work.

             

            And yet I can save and close the project after the import and it will run without any problems when reopened.

             

            Currently working a bit on recreating the whole project for Web based with cgi's and JavaScript .

             

            Anybody else creating cast members in an app?

            • 3. Re: D11.5 Unload
              Adam-C Level 2

              Ah yes - creating cast members on the fly at runtime is a no-no - it always creates memory problems. Only create cast members in author mode.

               

              Here's what to do:

               

              Think of the text cast members as display fields - don't use them to store data, just use them to display it. This will mean you only need a few dozen text members, all of which are created at author-time (and therefore won't cause memory problems).

               

              Think of your data as exactly that - data. It is just a bunch of 0s and 1s, and you can store oodles of it within variables (and if you start running out of RAM then you can easily free-up the memory by voiding the variable).

               

              Create a global list (or property list) variable at start-up and then read the required text into the list when the program runs. The text could be contained in an XML document (or documents) that you then read into a Director XML Parser object (from where you can do various things with it), or you could have the text stored in lots of text files which are read into memory at start-up. Or any number of other methods - the point is that you're reading this stuff into variables, not creating cast members to store it all.

               

              Finally, you will need to devise a way of locating any text from within the global list that you want to display - presumably you already have a way of identifying and displaying specific cast members, so you just need to adapt this to search a list rather than a cast (it'll be a MUCH faster search than searching against cast members too). Once the required text is located it's a simple task to pass it to the text cast members / sprites that display the text.

               

              If for some reason your project absolutely demands that you create text fields on the fly then do it with an embedded Flash SWF object - Flash is more-than happy to create - and destroy - text fields on-the-fly (there's a limit I think, but it's in the thousands).

               

              Hope that helps - come back to me if you have questions or want more detail.

              • 4. Re: D11.5 Unload
                edb00 Level 1

                I actually built a version where the cast members were created in advance in authoring mode then made into a projector with a few thousand empty cast members to hold the data.

                On import the data was put into these preexisting cast members. There was no difference in the behavior so apparently its not the act of creating cast members but putting data into them that mucks up the memory management.

                 

                I know Director manuals denegrate the creation of cast members but it has worked for previous versions of Director starting with version 8. Its only since Director 11 that memory mangement is so wacked that it no longer works. Also its only a problem for the Mac version the Windows version still works as expected in spite of creating cast members on the fly.

                 

                The fact that Windows Director deals with memory mangement in this case but not the Mac version tells me there's some underlying flaw that's not being addressed.

                 

                If I'm forced to rewrite and redesign my application to get Mac Lion compatibility it certainly won't be in Director.

                • 5. Re: D11.5 Unload
                  brahim_ayi

                  Why don't you import your members only when you need them on the screen and remove them when you don’t use them ?

                  You can store them in external folders near your projector. And no more memory problems....

                   

                  Brahim AYI

                  • 6. Re: D11.5 Unload
                    Adam-C Level 2

                    it has worked for previous versions of Director starting with version 8.

                    You're lucky then - I have always experienced problems when creating cast members on-the-fly in projectors, and I started on Director 8. Maybe not as extreme as what you're experiencing with Director 11, but certainly problems nonetheless... but then I never tried to create / use so many cast members.

                     

                    I actually built a version where the cast members were created in advance in authoring mode then made into a projector with a few thousand empty cast members to hold the data.

                    You know what you're trying to achieve and I don't, but IMO I can't envisage any situation where using cast members in this way would be preferable to using variables. Perhaps you've got a point that such things should be possible, but given that there are much better solutions then why keep flogging the proverbial dead horse? Media cast members and their associated sprites are best-used for displaying data/content, not for storing the data that drives your application.

                     

                    The fact that Windows Director deals with memory mangement in this case but not the Mac version tells me there's some underlying flaw that's not being addressed.

                    Just the one flaw?!!

                     

                    If I'm forced to rewrite and redesign my application to get Mac Lion compatibility it certainly won't be in Director.

                    A sentiment being echoed by many Director developers. Check-out LiveCode - it has a lot in common with Director so makes for a pretty simple migration. IMO, though, any development package will give you problems if you don't use its framework in the way in which it was designed to be used.