That's right.. the game logic for the first screen setup is still hardcoded, but the engine now properly implements all the necessary code to handle the calls to register a sprite sequence animation, and drawing elements on the screen; so animation sequences are now properly animated.
I consider that this reperesents a great step forward, since the entire game is based on the display of graphics - so I finally have a working core from which to build on further functionality with. This includes areas such as the logic for the player character itself.
The graphics core in the MADS engine has been more complicated then I've previously dealt with - the functionality is split between a main sequencing list for scheduling animations, graphics display logic, and various suppport classes, such as for dirty area handling. There's a whole mess of inter-relating code, which meant that I had to disassemble a lot of the code before I was able to implement something that works. There are still some fields that I've yet to figure out that handle certain special cases, such as the ability of dynamic hotspots to move their position, but that'll come in time.
If there's one thing that annoys me about the MADS engine it's the number of data variables that seem to get set everywhere. I'm presuming the original engine was designed to be generic for multiple games, but there seems to be a ridiculously large number of data values being set throughout the engine. It'll be interesting to find out whether the the majority of them are part of the 'core' MADS engine, or represent a whole lot of game-specific hacks for the Rex Nebular game.
I've included a screenshot from the first game room from Rex Nebular below. It may not be obvious from a still picture, but the various status displays now display flashing lights, and bubbles are escaping from the hull into the water.
