Back to Bytecode

After getting Bug Garden working, I began implementation of the bytecode versions of parent scripts and factories. For those not familiar with the Director engine, there are two ways we load Lingo scripts. From Director 2-3, Lingo was stored in Director movies as source code, which we parse and compile to custom bytecode. Starting in Director 4, Lingo was compiled to a bytecode which is similar to our own, but it has a good number of differences. This bytecode is stored within movies’ Lscr chunks, which also contain script metadata, much of which we don’t yet handle. Due to the bytecode differences and unhandled metadata, parent scripts and factories only worked when the Lingo was loaded from source code, not from Lscr.

For this, I needed to get back to my Director roots, which started with reverse-engineering Lscr for the development of ProjectorRays, a Lingo bytecode decompiler. I already knew how to handle parent scripts from ProjectorRays, but factories were a mystery, so I needed to go back to the old strategy of incrementally changing test movies and watching what data changes. I’ll spare you the fine details of how factories are stored, but basically scripts which contain factories are split into multiple Lscr chunks, with one chunk for each factory, and there’s some metadata which ties these chunks together. With that work done, parent scripts and factories can now be loaded from bytecode.

I also did some more work with events, which I will continue this coming week. Last week I said that only one object is supposed to handle each event, which is only partially true. Sev pointed out that an event handler can call pass, which will pass the event to the next object in the chain of potential handlers, so I needed to make further changes to event delegation to handle that. Now I’m in the process of checking event execution order against different versions of Director, and then it’s on to implementing windows.