I had a bit of time today to finish the new foreground design mechanism, along with the foreground save routines for LN.
I was testing the result when I noticed something was not as I expected it to be. My saved version of the foreground data for level 1 showed that screen 8 did not have any foreground. That is not quite right, but even in edit mode Integrator 2012 was not showing it. Now this is due to the new design logic and to a very innocent mistake that was done on the C64 🙂
The mistake consists in the fact that the foreground list for screen 7 is not properly terminated. As a result of that, there’s an alien foreground bit (framed in black below):
The extra element belongs to the foreground definition of screen 8. So basically the list for screen 7 falls through to the one for screen 8. Once I understood that I was able to modify the read routines to take it into account, even if it is just a mistake. Now the foreground of screen 8 shows as it should (item framed in black again).
What I noticed is that the foreground item for screen 8 is also slightly misplaced so it does not overlap perfectly with the tree it is meant to designate as foreground. Anyway, that is not what this post is about.
The above experience made me think of a third mechanism to designate foreground that would not only minimize the amount of information saved (which would still work with the original game engine), but also allow maximum flexibility as after a foreground list is built for one screen, the trailing part of it would be available to use for a different location where that trailing part would be common to the two screens and complete for the second one.
It is true that the original engine allows this degree of flexibility, but it is also true that the non-terminated list is obviously a mistake and the chances to have a foreground definition that includes another one are slim (identical temple locations at level 1 are not an exception as these are assigned the same foreground definition list).
I will have a thought about this as I think I am pushing it too much now. Besides the extra flexibility would result in a slightly awkward design process and I already commented on the fact I care about usability of the interface.
I guess that in the end I might keep the current design strategy and just report the issue while reading the foreground data, offering users the option to fix it 😀