2 Replies Latest reply on Aug 31, 2009 6:48 AM by Steveorevo

    Linked Director Movies or Leak Director Memory?

    Steveorevo Level 1

      I was wondering if LDMs are officially supported by Director? I ask because I'm thinking of reporting this as a bug.

       

      Every game, application or usage of LDM based projects have always started out ideal. Beautiful in fact. But they ALWAYS end in complete disaster for me. I often end up having to combine all the code into one huge file/mess. I thought Director supported LDMs because of the combo box 'Link to external file', the 'Enable Scripts' checkbox, and the fact that Director files can appear in the cast.

       

      But for me, it only 'appears' to work until memory gives way. Then KA POW!

       

      To reproduce the problem is simple. I'll provide this example in JavaScript, as I hoped the beauty of OOP Javascript with LDMs would create the ultimate reusable and flexible IDE or at least a fast prototyping design environment... Fair enough? That would put Director above PowerPoint in my arsenal of day to day application concept tools (which is still above a sketchpad and paper). To my dismay it just works for a little while and I've already ended up with egg on my face trying to publish anything using an LDM.

       

      I'd gladly pay triple the price of Director or more, say $10,000 bucks if this would just work.

       

      Create a child movie with an oval sprite on it and on the last frame in the script channel of the movie add the a-typical behavior:

       

       

      function

      exitFrame(){

         _movie.go(_movie.frame);

      };         

       

      Now add a behavior to the oval sprite:

       

      function

      beginSprite(){

         this.parentSpriteNum = 0;

      };

       

       

      Save it as a childMovie.dir. If your run it, you'll see a static oval where you placed it on the stage and the playback head looping on the last frame. Easy enough, right?

       

      Now create a new Director movie and call it parentMovie.dir. In the cast, import childMovie.dir from above and be sure to select the option "Link to External File" from the combo drop down box. Don't forget to select the childMovie.dir in the cast and check off the checkbox in the property inspector 'Enable Scripts'. Its there next to 'Loop' and 'Audio'.

       

      Now add the childMovie.dir as a sprite on the stage along with the same a-typical last frame script channel movie behavior:

       

      function

      exitFrame(){

         _movie.go(_movie.frame);

      };

       

       

      Now lets say we wanted to do something useful. Like tell the childMovie what sprite channel it appears as in the parentMovie. This is the essential foundation for LDMs to even begin intercommunition. But really, all we are doing here for this example is settings a property. Add a behavior to the childMovie sprite with the following:

       

       

      function exitFrame(){

         sprite(1).movie.sprite[1].parentSpriteNum = 1;

      };

       

      Click run and watch as memory flys into never never land. All we are doing here is just attempting to communicate to the sprite within the childMovie and setting a simple property. Just a number. Thats it.

       

      If you go to your object inspector, you can see "sprite(1).movie" and watch "_movie", its handle changing its address value rapidly, being offset as memory leaks out the door. Director is copying the value, rather then pointing to a shared memory location or overwriting the existing one for that value. Each time orphaning the previous value along with memory. Invoking _system.gc() appears to reclaim a little, but given time, Director will crash (a long time for just a number). Now imagine if you wanted to do something useful, like pass a string, or invoke a method in a childMovie's sprite(1). Forget about passing an object like a reference to the current movie's stage. Think of using sendSprite or sendAllSprites? Same problem. Talking to the LDM just leaks a tiny (or a lot) of memory each time. Now given a decent sized project (say a wizard with 3 pages) and all hope is lost.

       

      I've enclosed the files for your reference and a screenshot. Can anyone else confirm, does Director support LDMs?

        • 1. Re: Linked Director Movies or Leak Director Memory?
          josh_chunick Level 1

          Unfortunately, LDMs are not officially supported by Director; they never have been. Why? Because they're not fully implemented and who knows if the development teams over the years started to implement them and never finished, or LDMs just work because of the DOM (Director Object Model)... I don't have that answer. What I do know is that LDMs work and are used by many developers. I've used them myself and can personally assure you that they work. I'll start off with some links:

           

          1. LDM Article on the DOUG Wiki - http://director-online.com/dougwiki/index.php?title=Linked_Director_Movies

          2. LDM Article discussion by me - http://director-online.com/dougwiki/index.php?title=Talk:Linked_Director_Movies

          3. Example of complex LDM built by Alex da Franca - http://www.farbflash.de/ILtable/index.html


          I'm currently exploring LDMs in order to recreate the OSControls Xtra for D11+... a little project for use by myself and as an OSControls replacement for Director developers in general.

           

          Now, as for why you are seeing a memory link in your example... I downloaded your file and tested, and indeed, there's a memory link... however, I simply changed a couple of lines for the code to do the same and be more practical - and the memory leak is now gone:

           

          var runOnce = 0;

           

          function enterFrame(){
            if (runOnce == 0){
              sprite(1).movie.sprite[1].parentSpriteNum = this.spriteNum;
              runOnce = 1;
            }
          };

           

          also, changing the script syntax to be Lingo, but keeping the same script seems to make the memory leak disappear:

           

          on enterFrame me
            sprite(1).movie.sprite[1].parentSpriteNum = me.spriteNum
          end

           

          Why is this happening? I'm not sure at the moment, but it's clear from your straightforward example that Lingo should be used and not Javascript. The DOM was formalized and cleaned in order to add Javascript (ECMAScript to be precise) to DMX2004, but it still stands that LDMs and the underlying relationship that existed between that and Lingo wasn't broken when the DOM was cleaned up, however, it might not have been possible for the developers to implement the same level of integration between LDMs and Javascript considering LDMs were never supported in the first place. So, that being said, I would stick to using Lingo and definitely check out the examples at the links I posted.

           

          PS. Once I can formalize my own experiments/modifications to LDMs, I'll probably be writing a section at the more active Directorforum collab wiki here: http://collab.directorforum.com/Main_Page

           

          PPS. See the attached checkbox_test2.zip file below to get an idea how I'm structuring the LDMs (I've based it off the article link above).

          • 2. Re: Linked Director Movies or Leak Director Memory?
            Steveorevo Level 1

            Hi Josh! Thanks for writing a reply. Your addition is very practical. My example was to make the memory leak obvious. Hitting the sprite(1).movie.sprite[1] just once reduces the memory leak (in your example to occur just once), but does not remove it.

             

            Unfortunately, in my projects I've passed more then just a single number, sometimes strings, and sometimes objects, repeatedly and I have implemented similar tricks to reduce the problem and then with a very straight face, tell my clients to reboot every 12 hours to 24 hours (thats when I stopped using LDMs).

             

            Its doubly troublesome as It appears to occur with just referencing a property by 'reading' it, not just assigning a value. At one point in my LDM experience I tried just checking an LDM's property before invoking methods, setting additional properties like so, it leaked even worse:

             

            function enterFrame(){

              if (sprite(1).movie.sprite[1].parentSpriteNum != this.spriteNum){

                sprite(1).movie.sprite[1].parentSpriteNum = this.spriteNum;

                runOnce = 1;

              }

            };

             

             

            Real shame. I haven't checked in Lingo, I wonder if my previous woes with LDMs back in Lingo were also leaking from the same bug. I'll have to give it go and watch _movie. It almost appears that memory reference handles to _movie get bumped and never released. Wierd, and sad. Oh how I wished it would work!

             

            One thing that I have not tried is to use is a hashtable or FIFO stack in  a _global memory location and then have each movie talk to the _global vars, polling on idle to invoke events, etc. and leveraging serialization to make it easier to access LDM internals. Its a bit too much to wrap my head around now. But if I need to have an App that doesn't leak and crash in a 24 hour period, perhaps I will invest the time. Please share if you find out more! Thank you again for your reply. Should I bother to submit this as a bug?