Hey guys!
I started off last week attempting to get the infamous zoomBox working with the new rendering pipeline I wrote for our Director engine. A zoomBox effect is the classic window movement animation in classic Mac OS: When you open or close a window, you see many spectral rectangles in between the window’s origin and destination. Even though I haven’t seen any games actually use it, this function was the first motivation I was given reworking the rendering pipeline. Before, we could not look ahead into the next frame to get the dimensions of a sprite.
Moreover, before, we had to cache a copy of the screen so it could be restored after the animation was finished. I used the same trick that it seemed Mac OS used with many interface elements, though. As the animation was drawn, the pixels of the rectangle were inverted, and then on a second pass they were inverted back. Just like matrices, invertible animations are quite nice.
I also modified much of my code from the previous weeks to get a major part of our benchmark kit, Macromedia’s own The Apartment, working properly. Normally, when a sprite is puppeted, its position is not updated from the score. So animated puppeted sprites are impossible, which made my job a bit easier. There is another case, however, that required a major rework of the rendering code I had already written. I didn’t realize that with a sprite simply declared moveable, rather than a full puppet, it can be animated. Thus, we could no longer store the current point in each sprite as it flew by over the playback head – that would give us very strange jitters. Instead, location information needed to be consistent across frames. So, another level of abstraction was needed, a Channel class that would keep track of this intraframe information.
It feels strange to summarize into a single sentence a task that took me several hours to complete. But, I suppose this is the very nature of software engineering. Over the past weeks, I have learned very much about being patient with myself and taking breaks when I need to. I’m going to try to be a bit better about working for a long time on the weekends, even though I find it very enjoyable.
On Wednesday, I think it was, djsrv fixed a Lingo issue and I fixed several rendering\widget issues that allowed me to get more than a quarter of the way into Warlock – and even then, it was my choice to stop and not a misplaced null pointer’s. 🙂 This is an exciting progress milestone for us. Ah, the beautiful Belshazzar!
On Friday, I didn’t commit much because I got distracted by an engine I had mentioned briefly before, the Media Station engine. Many of the Disney Animated Storybook CD-ROMs were developed with this engine, as well as one of the few Living Books titles that didn’t use Mohawk. Strangerke warned me a few weeks ago that the executable was very complicated, but I found some success using moralrecordings’ Mr. Crowbar to peer inside the assets. They seemed like easy RIFF, but nearly all the chunks seem to be named some variation of “igod” and there’s some extra structure hidden inside the chunks. Bitmap and waveform data is clearly visible, though, so there’s probably not far to go to understand the format. After GSoC is over, I would hope stay on and keep working with this engine – plus Director, of course.
Anyway, I’d better get back to Director. I’m now working on getting all of the inks (blitting modes) playing nicely together. Graphics programming has proven pretty neat, even if it often goes slowly.