Scene Builder

[troflip]

Nice update! However, this is actually worse from a memory standpoint; you create instances dynamically (View new:) then throw them away. This will leak memory and cause fragmentation. Rather, my idea was to have a single instance in the room script and then reuse it.

EDIT: Hmm, I see that the system actually does add addToPics to a list. This is odd, and would furthewr complicate matters. I can't investigate now, though.

In my testing (from my post last week about memory usage), it did create some minor fragmentation. But the game code does clean everything up, so there aren't actually any leaks. I feel like using a single instance might cause issues, but I haven't tested it.

You might just be able to create PV objects directly though, rather than Views?

[gumby]

I'll do some testing on memory consumption of the resulting game scripts.  Never used a PV instance before, after looking at the class it looks like it would consume less memory than a view (less class properties, less methods) and it has everything I need.  I'll see if using PVs will improve the memory footprint more.

[troflip]

PV instances are what get created with you addToPic a View. The View is disposed of, and a PV (which does take a little less memory) is created in its place so that there is enough information around to redraw the views when you restore a game. The advantage of creating one directly is that you would avoid a bit of memory fragmentation (caused by allocating and deallocating memory for a View).

Looks like LSL3 uses them directly extensively, if you want to look at that decompilation. Looks like it declares instances of PV (which was PicView in the original source code), and then explicitly adds them to the gAddToPics in the room's init.

[gumby]

I couldn't get PVs to work initially, but decompiling LSL3 did help me work through it.  I tested three different scenarios, with 19 different views for each test:

1) Creating a new View instance on-the-fly (no instance reuse).  This was the worst scenario, with 18,862 bytes of heap remaining.
2) Creating a new PV instance on-the-fly (no instance reuse).  Better, with 19,414 bytes of heap remaining.
3) Created a single PV instance & reused it.  Best, with 20,062 bytes of heap remaining

So there we have it.  Looks like I'll be sticking with #3.

[troflip]

I suspect #3 won't work when restoring from the saved game.

The information needed to draw the view to the screen needs to go somewhere in the heap (which is what is saved in a save game), and that place is the PV instance. So if there's only one, then only one will be drawn when restoring a saved game (via the gAddToPics doit: call in Game's replay method).

[gumby]

Sure enough, the single instance doesn't work upon a restore.  Guess I'll need to go with option #2 then.