On the right path (Domograms)!

I've documented the Domogram code. I had to revisit the function in the SUB CPU that adds the Domogram object information as I hadn't fully RE'd that either.

Not surprisingly, Domograms follow a pre-canned path. The path information in the SUB CPU object data table comprises a variable number of (length, vector) pairs. The length is self explanatory. The vector byte is an index into another table in the MAIN CPU ROM, which specifies delta Y and delta X values.

There is a circular buffer in shared RAM for the path data of up to 12 active Domograms. When a Domogram is added to the object tables, the path data (up to 64 bytes, or 32 vectors) is copied into the tail buffer entry. The address of the data is copied into the Domogram's object (what I've called for now) 'extra' table, and the length of the data also initialised in one of the tables.

The Domogram object handler then processes all the path entries by updating the object dX & dY values and timing each vector length. If/when the Domogram path entries are exhausted, it is left to continue on that vector until it scrolls off-screen (or is destroyed).

One thing that had me stumped for a little while is the re-purposing of the object type table as a third timer! A reminder to me that the type table is essentially defunct as soon as the type-specific object handler has been hooked into the object table. FTR the Domogram requires timers for shot frequency, path vectors, and animating the launching of bullets. In hindsight I'm wondering why the latter wasn't incorporated into the shot frequency timer?

Now to bite the bullet and unwravel the directional calculations. I have a sneaking suspicion that some of them may also incorporate some AI parameters that effect the accuracy of the calculations. We'll see..