Skip to content

A New ZMPP Design

The parts for a new release of ZMPP are slowly coming together. Pichuneke, a spanish ZMPP user, contributed a spanish translation for the user interface, which is now the second user initiated translation (the first being French, done by Eric Forgeot).

This is a point that makes an Open Source project fun: the involvement of its users. At some point I have realized that ZMPP has turned from being my personal pet project to being software that I believe now belongs to its user community which has exceeded my initial goal (being a reference implementation of the Z-machine in Java) by far.

I also realized that “Z-machine Preservation Project” to me means not the Java implementation itself, but it is more my personal idea how a Z-machine could be implemented on a variety of platforms. Having done ports in Ruby and Erlang has deepened my understanding of the general problem of implementing the Z-machine in an implementation language which is on a higher abstraction level than C/C++. The Subversion trunk now contains an extract of the lessons learned mainly during the implementation of the Erlang port (and I am still amazed how well some things can be done in Erlang). The illustration below shows the updated design as it currently exists in both the Erlang and Java versions:

ZMPP Reference Design

As can be seen, an ExecutionControl object controls decoding and execution of instructions, which in turn work on the Machine object’s and screen model’s state. The Z-machine core now runs single threaded only, which simplified the control logic quite a bit, especially the implementation of interrupts, which are now controlled in the user interface. Also, there are now much less core objects the user interface needs to deal with, which in combination with the pause/resume execution facilitates the integration in different contexts.

The most apparent difference in the new ZMPP is the new screen model implementation, which finally uses a JTextPane as it should have been from the beginning. It should be noted that Zinc has taken that route years ago. The way it is implemented is totally different from what I wanted it to be, which is why I chose custom rendering in the first place.

This time around, I took more time to analyze the Z-machine screen model more thoroughly, which led to the decision of implementing the screen model view in a way I think it should be implemented:
This was now done by having two Swing components to represent the upper (a fixed text grid) and the lower (a flexible text area) window. As opposed to Zinc, but like in Zoom, I wanted to have a scroll bar, which spans both the upper and lower window, but only controls the lower window.

This is not easily done using the standard AWT layout managers, so ZMPP implements its own which manages the components in the following way: The main view is a JLayeredPane and the layout manager puts the bottom window, which always spans the whole layout area, below the top window. The upper window is used as a flexible and transparent overlay over the lower window so its output can be rendered overlappingly with the lower window, and its size can be controlled by split commands.

Overall, I happily trashed a good portion of the original ZMPP code, which I credit to a better understanding of the Z-machine. Switching to JMock 2.5 (which is a huge improvement over JMock 1.x) also helped greatly in simplifying the test classes.

Why was this all necessary ? As a short-term goal, I want to deliver on some promises I made: A screen model supporting selection, cut and paste, more reader-friendly margins and resizable windows for example.

Medium-term goal is V6 support, which is still incomplete and currently deactivated for Version 1.5. It was one of the main drivers for the new design, which will hopefully make it easier to overcome some of the problems how the old ZMPP handles V6 games. V6 support is one of the things which I really feel ZMPP should do well, to deliver on the “Preservation” in ZMPP’s name.

Ultimately, the changes made were done in order to provide a baseline for future improvements. I always want to try my best to support this goal. Change is the only constant in our world and as Extreme Programmers (I do not consider myself one) say: “Embrace Change”.

To ZMPP’s users: Thank you for all your support, your suggestions, improvements and criticism. Without you, the changes made and which are going to be made in the future would not have been possible.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*