Really nice idea Dbug!. However, I am not sure about implementing the 2nd option... For what I saw even in older SCUMM engines, these offsets are 2 byte long. I don't know if scripts larger than 256 bytes are going to appear, but until I start doing something more complex, I will keep the current layout for the time being (which is the one used in SCUMM BTW). There will be time for changes later, I guess.
Anyway I am not at that point yet. I am afraid that writing by hand all that code will be exhausting. I am really frightened about having to write a kind of compiler for that, but alas! I see myself writing an room editor too! able to handle everything I need, such as AIC graphics but also optimizing for tiles, adding walkboxes, objects and other data, and exporting all these to create the game data. A bit overwhelming, really.
But little steps. I am more concentrated on the skeleton of the engine and, more precisely now, with the user interaction. I know the "cursor" is not beautiful and it is slow and flickering at some times. The speed is something I am concerned with most, because it could ruin the playing experience. I plan to accelerate the movement if you keep the cursor pressed for some time, but I will have to check how that looks like. The flickering is quite inevitable, only hiding it by synchronizing with the vertical retrace is possible.
I also plan to add some kind of highlight of the verb when you move the cursor over it. I need to be careful with using attributes or they will be corrupted by the cursor movement. Maybe highlighting them when the cursor is over them, but removing the attribute as soon as part of the cursor is outside... that won't look good (the center of the cursor could be over the verb while it is not highlighted), but might work.
But that won't work with the inventory, where the selected item should remain highlighted. Maybe using inverse flags here could do the trick.
More importantly I have to implement more instructions of the scripting language but first try to find an optimum way for coding instructions (more precisely their addressing modes). Also the camera can follow a given actor if instructed to do so (there is a script command for that) by scrolling the room. This is working nicely, but is also quite crude: scrolling is slow. I have to implement more camera commands, so you could pan it to a given X position, or go instantly (with no scrolling), but also need some nice effects: fading is not possible, I think, but other effects could be thought of.
I don't know even how to dump a room graphic for a start. Having inverse bits on here and there would make the trick of setting ink and paper to the same value and change it when the room has been drawn, quite useless.
And the thing about loading resources from disk is driving me a bit mad. I have not even started with tests, but I already think there will be issues here. I will probably write you, Dbug, asking for help and ideas about how to organize things on disk. And that is just part of the story. Resources are loaded and discarded on demand, which means memory fragmentation. I have put some extra information on resources to help with compaction, but still need to implement the system. If a resource is moved, some pointers need to be adjusted here and there. I have some ideas, but problems will appear for sure.
Ah, nobody said this one would be easy. It reminds me a lot when I started working on an isometric engine. A lot of time passed from the first tech demos to a working engine and even more to produce a game with it (having to write some tools in the process, such as the map editor :/ ). And good old Twi was there to do the graphics and sfx!