Heap Space Fun

[robbo007]

Hi guys,
Is there a way to use the DisposeScript for a certain room number? I have it setup in my main.sc for the scripts that can be safely disposed of but if I add my region_script there it breaks it.

The problem I have is the region_script I use to control the bikini girls walking around the rooms seems to cause one of my rooms to have the out of heap space error when accessed by ego. I only want to dispose this script when accessing this one room, to free up heap space.  Then when leaving the room make sure the region_script is loaded again. The region_script is not needed when ego is in this room, nor is it a room that the bikini ladies walk to.

If this is possible where would I define this? What syntax?
Regards,

[robbo007]

Sorry, I did not think it would be this simple. My mistake.

Unload the regionpath_script in the section (instance RoomScript of Script) in the room previous to the one that was having the heap space issues. As its not needed in these two rooms.

Code: [Select]

(DisposeLoad NULL REGIONPATH_SCRIPT) ; Dispose REGIONPATH_SCRIPT before initialising the room
The regionpath_script seems to load back after exiting the room. So a nice little fix for this issue.

[lskovlun]

At the very least, you'll have to take it out of the regions list, and perhaps disable some other things, such as active scripts. But the right way to remove a region is to override the region's newRoom method (which you should already be doing):

Code: [Select]

        (method (newRoom newRoomNumber)
                (= keep (OneOf newRoomNumber 299 300 305 306 310 315 320 298))
;                (= junctioned (= initialized 0))    ; This is SQ4-specific stuff
                (super newRoom: newRoomNumber &rest)
      )
This is the butte (aka Estros) region. You simply omit the offending room from the OneOf line.

[robbo007]

Thanks Iskoviun,

I did have only certain rooms using the regionpath script as you can see bellow. The room which was accessing the room that had the out of heap space error was not included in this regionpath script but it seems the script is using memory and the only way was to disploseload of it before accessing the problematic room.

Code: [Select]

(method (newRoom newRoomNumber)
(if (not (= keep (OneOf newRoomNumber 26 27 28 29 32 10 13))) ; These are the rooms that the bikini girls will walk to: beach, beach1, beach2, Vivir sin Domir
(gGame setScript: 0)
)
(= initialized 0)
(super newRoom: newRoomNumber &rest)
)
I was also checking the things in memory using the debug by holding down both shift keys, and press the "-" key on the numeric keypad and then pressing o. I see all the inventory stuff is listed. I've gone over my main.sc and added all Print statements to text files to save memory. Including the inventory. What other things should I consider with new scripts to avoid heap space problems? My scripts are getting a little more advanced now so any pointers most welcome. I'm still a n00b at this. 

What sort of things stay in memory? What things get removed automatically when changing rooms? Any ticks worth doing?
Regards,

[robbo007]

Just reopening this as my game advances so does the "Out of heap space" fun...

When I started this debacle  I had a few things I knew I wanted to make sure my game had. Loads of unique responses when a player typed into the parser. And to have a more dynamic gaming world, actors, NPC's etc moving around.

To reduce the size of my scripts I've been following the guidelines here: http://sciwiki.sierrahelp.com/index.php?title=Memory_Management
I use the text resource for all print statements. I've added scripts to the main.sc DisposeLoad section, but this is still not enough.

Do I need to include the template scripts like FEATURE, CONTROLS,GAME, OBJ, REV etc? Or do these all get removed automatically from heap when ego moves into the next room?

Currently I have listed:

Code: [Select]

(method (startRoom roomNum);this disposes these scripts after use to free up heapspace.
(DisposeLoad
NULL
FILEIO_SCRIPT
JUMP_SCRIPT
EXTRA_SCRIPT
WINDOW_SCRIPT
TIMER_SCRIPT
FOLLOW_SCRIPT
REV_SCRIPT
DCICON_SCRIPT
DOOR_SCRIPT
AUTODOOR_SCRIPT
WANDER_SCRIPT
AVOID_SCRIPT
DPATH_SCRIPT
SHOW_STATE
SIGHT_SCRIPT ;this was dded 18/9
DYING_SCRIPT ;this was added 18/9
DISCLAIMER_SCRIPT ;this was added 19/09
TITLESCREEN_SCRIPT  ;this was added 19/09
INITROOMS_SCRIPT

)
If I use a RoomScript or an Actor/Prop script in my room does this need to be manually disposed of? Or will it get automatically disposed when ego moves to the next room? If not, what's the best way to have these dispose?  What syntax do I need to use?

Is the heap space better in the SCI01 (Quest for Glory II) engine? If so, can I use this with my SCI0 template, my resource file and current game? Will I need to convert everything over? Does SCI Companion support this?

Regarding the Heap Space. To better understand it. How can I see a good visual map of the heap space in use. Or draw one like in the tutorials examples of the memory.  Excuse my maths skills but I'm not to switched on with hexadecimal. I see the heap space references with the alt-m debug command are in hex. Do more than one reference here mean the heap space is fragmented? I've included screenshots of the objects on the heap space also. Is this normal to have so many objects in heapspace in a room? Also using O seems to overlap the text. I see my inventory items all there also. Does this take up loads of memory on the heap? Should I be using less inventory items? Or can these be optimised as to not use loads of heap space?

Thanks.

[mnicolella]

Do you have a way to share your game in a state where it's low on memory? Could you share the compiled game plus a savegame that can be loaded? Is it playable in SCUMMVM? That would be the easiest way to write better heap visualization tools if they don't already exist.

[lskovlun]

Ha, one could write a heap visualizer taking SCI0 savegames as input. They aren't compressed, but of course the format is going to vary depending on the version. But I think the main takeaway here is that the heap is not very fragmented, there's just very little memory left. Maybe you'll have to scale back some of the animations/actors.

It's not possible to use the SCI0 template game in SCI01. There was a property lookup table (VOCAB.994?) that provided very fast property lookup for the properties where speed was an issue. That would have to be regenerated, and the standard classes modified to suit. You'd have to switch to the SCI01 template game

But even better? Just switch to ScummVM! Its engine uses a completely different design where this isn't a problem.

[Kawa]

Depending on the version, they are compressed.

[robbo007]

Ha, one could write a heap visualizer taking SCI0 savegames as input. They aren't compressed, but of course the format is going to vary depending on the version. But I think the main takeaway here is that the heap is not very fragmented, there's just very little memory left. Maybe you'll have to scale back some of the animations/actors.

It's not possible to use the SCI0 template game in SCI01. There was a property lookup table (VOCAB.994?) that provided very fast property lookup for the properties where speed was an issue. That would have to be regenerated, and the standard classes modified to suit. You'd have to switch to the SCI01 template game

But even better? Just switch to ScummVM! Its engine uses a completely different design where this isn't a problem.

ok thanks,
What are some of the main things that use up memory more than others? So I can try and optimise more my rooms?

What are the main changes with SCI01? Is it worth converting all my progress over to it and use the SCI01 template?

Unfortunately I want full MSDOS support on vintage hardware so I can use the ScummVM engine.

[lskovlun]

Well, the fact that the object list is garbled is a good hint. It means there are way too many objects. It occurs to me that there is no way to get a similar, complete list in scummvm (even though you can look up objects by name), otherwise I'd say you can still use scummvm for debugging

The main changes are MIDI is differen (and SCI1 compatible), you've got more memory, and there's a pathfinder if you need/want it.anything else of note?

[lskovlun]

Come to think of it, Sierra did have some scenes where they would refuse to save, saying "Not now." That would happen when there was no memory for the Save/Restore scripts, dialogs and so on.

[Kawa]

Another neat memory-saving trick is how Codename Iceman, if I understood correctly, has its inventory items in a few different modules, one per main act of the game. So anything you won't ever need in a given act won't be loaded. Which isn't a lot for inventory items but it's a neat trick to consider.

Also, I was not aware that ScummVM allowed pathfinding on SCI0. Unless I misunderstood what you meant.

[lskovlun]

Also, I was not aware that ScummVM allowed pathfinding on SCI0. Unless I misunderstood what you meant.

I was replying to the question about main new features in SCI01.

[Charles]

How robust is it compared to SCI1 pathfinding?

I recall in QFG2 when walking left/right in the desert ego would walk around large rocks that were in it's path, instead of just coming to a standstill.

[lskovlun]

I don't know that in detail, but I would assume it's pretty much the same? But QfG2 (the game, not the interpreter) does some fairly disgusting things with creating polygons on the fly - corpses and rocks in the desert - (said specs get some hairy treatment as well). Maybe that code is not optimal.