Memory management problem

[Joel]

Ok, I implemented it, and I seem to be able to save and restore a game ok. However, if I restore a game and then try to shapeshift, unpredictable stuff happens. Once, the screen got garbled. Another time, Windows said the program did something illegal and I should restart my computer. Another time, the game just locked. However, using NAGI I saved and then restored and nothing bad happened.

[Nick Sonneveld]

NAGI's had to work around a few bugs that don't get found as easily in the dos agi.  grr kings quest 4...

Can you trace through the code?  Make sure tracing is turned on (so scrolllock works), and then call trace.on() from inside the shapeshift code?

It might take a few goes but I'd like to know if the weirdness occurs during the logic execution or just after when it does all the graphics and starts logic.0 again.  It'll give me an idea of what to look for in the agi "source".

btw.. nice to see that you've registered.

- Nick

[Nick Sonneveld]

also, call show.mem before and after the discards and make sure the difference in free heap is around the size of the view (they'll be some small differences because of linked list structures as well.)

- Nick

[Nick Sonneveld]

I'm not quite sure where the error's happening yet.. but also, make sure if you're setting a loop for the view, it's set to a number within the range.

Also, i was wrong around script filling up.  it will only add to the script if the resource isn't loaded.  (ie, if you discard and then reload.. then the script gets filled).  that doesn't help if you're discarding anyway.

- Nick

[Joel]

The problem is definitely happening in the morph handler. I can't get it to print out command names for some reason, but the last few lines before the game either goes weird or Windows talks about an illegal operation are (my guesses as to what the corresponding code is are beside them):

41(0,33) - set.view(ego, FORM_NULL)
7(27)     - isset(bDiscardOldViewOnMorph)
2(37,39) - bCurrentEgoView != nEgoViewOnRoomEntry
 (28,9)  - no idea
153(37)  - discard.view.v(nCurrentEgoView);
    (28)  - no idea
31(40,3) - load.view.v(nTargetEgoView)
(press Enter here it screws up)

Code: [Select]


if (nTargetEgoView != FORM_NULL)
{
 if (!bOnEarth)
 {
   if (nCurrentEgoView != nTargetEgoView)
   {
     set(bScriptBufferBlocked);
     load.view(FORM_NULL);
     set.view(ego, FORM_NULL);

      if (bDiscardOldViewOnMorph &&
          nCurrentEgoView != nEgoViewOnRoomEntry
     {
       discard.view.v(nCurrentEgoView);
     }

     load.view.v(nTargetEgoView);
     set.view.v(ego, nTargetEgoView);

     nCurrentEgoView = nTargetEgoView;

     reset(bScriptBufferBlocked);
   }
   else
   {
     print(m1);
   }
 }
 else
 {
   print(m4);
 }

 // reset the target view to NULL so this handler
 // doesn't execute again
 nTargetEgoView = FORM_NULL;
}


[Nick Sonneveld]

it's a bit late, I'll have to look closer tomorrow.. but is there a chance you'd be able to email the game?  even if it's just the room with the morphing code?

I'll be able to go through it with a fine tooth comb then..

- Nick

[df]

how well does it work under sarien, if at all since sarien would definatly use different memory handling that old agi i'd assume nagi does it differently as well...

[Chris Cromer]

It seems to me that NAGI is more lenient memory wise than Sarien. When V still had those memory problems the original interpreter would not run it at all, and Sarien would work for some of the intro but crashed on the skyscraper scene with the 2 ships. NAGI was the only one that was able to run it then. But thanks to Nick the memory problems are gone and V will run on all the interpreters including the original.

[Nick Sonneveld]

I don't think it was a problem with Sarien's memory handling.  Sarien doesn't even use the load/discard commands.. it just loads whenever it needs to.  I'd say it probably was a problem with sarien's sprite handling in that V room.

- Nick

[Nick Sonneveld]

I think it's a problem with the list of animated objects.. somewhere it's getting corrupted and crashes interpeter when drawing them on screen... investigating..

- Nick

[Nick Sonneveld]

ok, found the problem..

it was still the old "load something and then discard something else" bug again.  It was staring me right in the face.. but I went ahead and used debug, printf statements 'n everything.  Actually, after going through the nagi printf statements slowly, I found out where the bug was.

here's the code (there's similar code you had for the save game wrapper as well):

Code: [Select]

load.view(FORM_NULL);
set.view(ego, FORM_NULL);

 if (bDiscardOldViewOnMorph &&
     nCurrentEgoView != nEgoViewOnRoomEntry
{
  discard.view.v(nCurrentEgoView);
}

so basically, you're loading the null view so you can discard the other view.. which means you're technically discarding the null view resource too. (because it's next on the list.. after the current view resource that's about to be discarded).

so what I did:

1) in the new.room section of logic.0, I load the null view resource there.  that way it's always available if you want to discard another view object
2) remove loading the null view resource in logic.0 for saving and in logic.90 for morphing..  It still sets the ego to null view though.. just doesn't load it again.

and it works.  I've quickly tested it, saving and restoring and there's no problems.

you might want to test a bit more to see if memory or script runs out but I think it's working fine.  I did a quick test with "show mem" and the max script level didn't rise.

So I hope that ends the chapter of AGI Memory Management Problem.

- Nick

[Nick Sonneveld]

btw.. I love it how you can have Jen walking, but still morph while she's walking.

- Nick

[Joel]

It seems to be working for me, too. Thanks for looking at it and for all your help.

I do have a couple more minor questions to make sure I don't run into more errors down the road. First, I know this is something I need to be concerned with any time I load a new view, but is it also something I need to be concerned with any time I load ANY new resource? As in, do I need to discard ego's view and reload it if I load a new sound into memory after it has been possible for the player to morph, for example?

Second thing is, when morphing into a view that is smaller than the current ego view (most notably morphing from just about anybody into the fairy from King's Quest), there's occasionally residue left on the screen from the previous view that doesn't go away until something is moved over it on the screen (for example, ego walks over it or a print box covers it up). Any ideas what might cause that? It may be a non-issue, because I don't think I'm going to leave the ability to morph into Sierra characters in the game, anyway. I'm just curious, 'cause it's a little ugly to have the previous view's head floating on the screen after a morph.

[Chris Cromer]

What I usually do to avoid the character from being left on the screen like that when changing the view is:

erase(ego);
set.view(ego,2);
draw(ego);

this will get rid of that ugly problem with the character being left on the screen.

[Nick Sonneveld]

AGISCI's suggestion sounds like the best solution for changing view's.

If you load anything else, you'll have to discard and then reload the view resource too.  It's fiddly so you'll probably have to make sure that you load up all sounds and stuff beforehand.

You could always generalise it, you could have a separate logic function that checks a list of animated objects and their view resources.

If you plan on loading another resource, you call this separate logic to give those specific animated objects (only "morphing ones") a null view, unload all the view resources..  

then open your sound resource

and then call this logic again to load up the views and give them to the animated object.

I dunno how feasible it would be, but you could call it anywhere.

- Nick