Howdy, all. Hope this blog post finds you well. No fun introudction today and we're, moreover, back into more technical territory for this entry.
It was blessedly little work to finish importing the remaining “thing” data, so I knocked that out in a few minutes. The rest of the day I worked on getting callbacks working and polishing up the export tools. I say "polishing" with a heavy dose of irony because the code is quickly becoming a single large, messy Python script.
In the exporter, the handlers are stored as either a filename to an assembly file or the raw assembly itself (in which case a temporary file is created). In either case, the file is passed to cl65 to be assembled and linked into a raw binary file (no header). There are a few labels that are likely to be of use to the handler code: the item’s name, description, and sprite address. These are computed by the export code prior to assembly. They are written to a temporary file (something like “__thing.inc”), which can be included by the handler code. An address listing of the engine is also included so that any public engine function is accessible.
Finally, if the assembly was successful, the output file is opened and read. The binary is prepended with a word containing its length and then the whole blob is appended to the “thing” in the room file.
I haven't actually gone into the format of the data for the tools, so I'll get into it here with a complete “Thing” example. As you can see, the data is actually stored as code. Each Room and each Thing are actually a subclass of an object that represents the respective entity. The "self" parameters assigned in the constructor override the defaults provided by the base class. This makes the exporter and the data very seamless.
The handler, as you can see, is simply a string of 6502 assembly. The include file "__thing.inc" is the aforementioned file generated upon running the exporter. It contains the computed addresses for the object's name, description, and sprite data. The other file included in this test example, "engine.inc", is also generated by the tool. To produce it, the tool simply takes the VICE label file that is generated when the engine code is linked and reformats each lable into constants that can be used as call addresses for the various subroutines that the engine provides.
It all works fine
class Bone(Thing):
def __init__(self):
super().__init__()
self.x = 65
self.y = 95
self.name = "bone"
self.pic = "sprites/bone.png"
self.description = "The bone has been licked clean"
self.handler = '''.include "engine.inc"
.include "__thing.inc"
.include "macros.inc"
inc $900f
rts
'''
That's all I got for you today. Stay safe. Stay healthy. Don't let THE MAN get you down. You are a valuable human being.