[{"content":"I recently had the interesting task of getting some interesting data off a 100 MB Zip disk for my Media Station project. Yes, that Zip. The Click of Death kind.\nSomeone gave me lovely Tangent tower for free the other day - that\u0026rsquo;s another topic - and there was a Zip drive in it. It was manufactured in 2000. I just hoped there weren\u0026rsquo;t many hours on it. I didn\u0026rsquo;t have a spare disk to check if the drive was good - I probably should have gotten one to test with.\nAfter carefully inspecting the disk to try to ensure the surface wasn\u0026rsquo;t torn, I put the disk into the drive and started up Windows 98. The disk seemed to load okay, but I got the dreaded \u0026ldquo;This disk needs to be formatted\u0026rdquo; error. However, I had good reason to suspect this was a Mac disk. So, the age old question, how to image a Mac disk on Windows 98?\nIf I\u0026rsquo;d had an ATAPI-to-USB adapter, connecting the Zip drive to my modern system would have been easy. But I only have a plain IDE adapter. So, I tried some other things instead:\nWinImage 6.0. Crashed on clicking \u0026ldquo;Read Disk\u0026rdquo;. I suspect this function was only designed for reading floppies and didn\u0026rsquo;t know what to do with a 100 MB disk 🙃 WinImage 8.0. The drive made a funny \u0026ldquo;scrubbing\u0026rdquo; sound that sure sounded like head bashing to me. It didn\u0026rsquo;t sound like examples of the Click of Death that I listened to online, but I was still really worried that the disk and or/drive were toast. Norton Ghost 2003. The Zip drive didn\u0026rsquo;t even show up when booting from the Ghost CD-ROM :( I\u0026rsquo;d spent two hours on this and was really mad. So I pulled out a CD-R and did what I probably should have done in the first place - burned an ancient Linux distro from 2005. That seemed like a good fit for my 500 MHz, 384 MB RAM system. Thankfully, it was recent enough to enable booting from CDs in the first place.\nThis old distro didn\u0026rsquo;t have ddrescue, but thankfully good ol\u0026rsquo; dd did the trick. I was dealing with an ancient version of dd that didn’t have status=progress. So my trusty AI friends recommended using the USR1 signal, which I didn’t know about.\nThe imaging completed fairly quickly with no apparent errors, so I copied the image to the the CompactFlash disk in the tower, then to my modern machine. A quick inspection in the hex editor revealed this was in fact an HFS disk!\nSo it just needed to be mounted in SheepShaver. Unfortunately, the contents were pretty boring - no engine source code. But the process was interesting!\nWhat have your experiences been with ZIP disks? Ever experienced data loss due to the dreaded Click of Death?\n","permalink":"/posts/no-click-of-death-here/","summary":"\u003cp\u003eI recently had the interesting task of getting some interesting data off a 100\nMB Zip\ndisk for my \u003ca href=\"https://npjg.github.io\"\u003eMedia Station\u003c/a\u003e project. Yes, \u003cem\u003ethat\u003c/em\u003e Zip. The \u003ca href=\"https://www.grc.com/tip/codfaq4.htm\"\u003eClick of Death\u003c/a\u003e\nkind.\u003c/p\u003e\n\u003cp\u003eSomeone gave me lovely Tangent tower for free the other day - that\u0026rsquo;s another\ntopic - and there was a Zip drive in it. It was manufactured in 2000. I just\nhoped there weren\u0026rsquo;t many hours on it. I didn\u0026rsquo;t have a spare disk to check if the\ndrive was good - I probably should have gotten one to test with.\u003c/p\u003e","title":"No Click of Death Here!"},{"content":"Last week was the last official week in the GSoC work period. I plan to submit my final evaluation after I post this. There you will be able to see some of the highlights from my time with ScummVM this summer.\nIn the past week, though, I didn\u0026rsquo;t start work on any new features. I spent a while understanding the data path location mechanism that the Mac version of Journeyman Project 2: Buried in Time used, and I ultimately discovered some buried XFCNs. (As @djsrv helpfully explained, XFCNs are external functions from (HyperCard)[https://en.wikipedia.org/wiki/HyperCard] that can often be called as regular Lingo.) One of these just looped through all the volume names on the system, looking for the proper CD name. This Journeyman Project is split across three CDs, so some more additions will be needed.\nI also fixed an obscure issue decoding the hex format strings for our Macintosh text implementation. Now, the main screen of Majestic looks almost perfect \u0026ndash; with proper cursors, which I also patched to load properly \u0026ndash; and consistent text formatting.\nAdditionally, I investigated and fixed several bugs with my good old friends the widgets. Now Chop Suey also looks very accurate, and there is no more flashing cursor or cut-off text boxes. Text borders are now (almost) working properly again, which makes the Lingo Dictionary movies more pleasant to look at.\nFor being the rendering guy this summer I haven\u0026rsquo;t posted nearly enough pictures, so I put those two here for you to enjoy. I\u0026rsquo;ve enjoyed working with ScummVM, and I plan to start contributing again once I get comfortable in my university schedule.\n","permalink":"/posts/gsoc-2020/finishing-up/","summary":"\u003cp\u003eLast week was the last official week in the GSoC work period. I plan to submit\nmy final evaluation after I post this. There you will be able to see some of the\nhighlights from my time with ScummVM this summer.\u003c/p\u003e\n\u003cp\u003eIn the past week, though, I didn\u0026rsquo;t start work on any new features. I spent a\nwhile understanding the data path location mechanism that the Mac version of\n\u003cem\u003eJourneyman Project 2: Buried in Time\u003c/em\u003e used, and I ultimately discovered some\nburied XFCNs. (As @djsrv helpfully explained, XFCNs are external functions from\n(HyperCard)[https://en.wikipedia.org/wiki/HyperCard] that can often be called as\nregular Lingo.) One of these just looped through all the volume names on the\nsystem, looking for the proper CD name. This \u003cem\u003eJourneyman Project\u003c/em\u003e is split\nacross three CDs, so some more additions will be needed.\u003c/p\u003e","title":"Finishing up"},{"content":"Last week, I finished implementing the direct-copy mode for our Macintosh window manager. Now, with the Director engine, there is no intermediate blitting onto a screen surface that is then copied to the physical screen. This restored transition speed and avoided duplicate work on every frame. Here\u0026rsquo;s the opening of Spaceship Warlock with the new interface and transitions:\nFor a while I was stuck on implementing border transparency without an intermediate surface, but @sev helpfully reminded me of g_system-\u0026gt;lockScreen(), which no longer has performance issues on some systems.\nI also looked at several long-standing bugs this week. As @djsrv probably noted, in investigating one we discovered that the goto Lingo should not run the exitFrame event. In the opening scene of Majestic, the two middle bitmap text channels previously held the mouse-over highlighting for \u0026ldquo;Restore Old Game\u0026rdquo; and \u0026ldquo;Exit\u0026rdquo; in the main menu. Clicking \u0026ldquo;Start New Game\u0026rdquo; went to the correct place, but not before the main menu\u0026rsquo;s exitFrame event disabled visibility of those channels again. Now, though, everything looks right:\nTomorrow, it will be time to figure out why the cursor implementation I made doesn\u0026rsquo;t work with Majestic\u0026hellip; and also why the bitmap cursor in Chop Suey still has a strange flashing behaviour.\n","permalink":"/posts/gsoc-2020/a-short-week/","summary":"\u003cp\u003eLast week, I finished implementing the direct-copy mode for our Macintosh window\nmanager. Now, with the Director engine, there is no intermediate blitting onto a\n\u003ccode\u003escreen\u003c/code\u003e surface that is then copied to the physical screen. This restored\ntransition speed and avoided duplicate work on every frame. Here\u0026rsquo;s the opening\nof Spaceship Warlock with the new interface and transitions:\u003c/p\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/7S03CkwXK08?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003cp\u003eFor a while I was stuck on implementing border transparency without an\nintermediate surface, but @sev helpfully reminded me of\n\u003ccode\u003eg_system-\u0026gt;lockScreen()\u003c/code\u003e, which no longer has performance issues on some\nsystems.\u003c/p\u003e","title":"A short week"},{"content":"Hey there!\nLast week, I added palette support for Director 3 movies, so several more games had their colouring issues on their opening movies resolved. Then, I spent much of Tuesday and Wednesday fixing issues with our path-loading code that prevented several of @trembyle\u0026rsquo;s testing titles from running \u0026ndash; no less than 7 when you account for Windows and Mac versions. Lingo provides several ways to interact with the filesystem. Some games asked you for a drive letter and would just loop endlessly if they would not find the file they wanted. Others were a bit smarter \u0026ndash; on Windows, for instance, they would look for a hardcoded file name on all the drive letters and crash if there was no match.\nIn some cases, our file finder was not trying all the possible Director movie extensions on Macintosh, and others had filenames improperly converted from Macintosh long file names to the FAT 8.3 format. I actually just now saw that @trembyle notated several new titles with path/file errors, so I will probably look at those once I finish my current set of tasks:\nBefore @djsrv implemented the desktop mode, the Director transition drawing code was taking direct control of the screen (via copyRectToScreen). In the desktop mode, however, this would pay no respect to window layering or positioning. So I am working on improving screen access through the window manager. Currently the WM keep a copy of the screen as a surface, but I am exploring how to avoid this extra copying. This can cause performance issues, even in non-desktop mode, since the surfaces must be copied twice \u0026ndash; from the Director sprite, onto the _screen, and from _screen onto the display device. Fixing this duplication will help the effort to support QuickTime video from Director movies.\nIn the last part of the week, I got distracted by my starting in earnest my first from-scratch RE of another engine. This is not for GSoC, just to satisfy my own curiosity. It\u0026rsquo;s the engine used by the one title in the Living Books series (D. W. the Picky Eater) that doesn\u0026rsquo;t use Mohawk. I understand the file format fairly well, and so the next task is extracting resources and then working toward the script bytecode. See my repo for more information.\nHave a great week!\n","permalink":"/posts/gsoc-2020/on-the-right-path/","summary":"\u003cp\u003eHey there!\u003c/p\u003e\n\u003cp\u003eLast week, I added palette support for Director 3 movies, so several more games\nhad their colouring issues on their opening movies resolved. Then, I spent much\nof Tuesday and Wednesday fixing issues with our path-loading code that prevented\nseveral of @trembyle\u0026rsquo;s testing titles from running \u0026ndash; no less than 7 when you account for\nWindows and Mac versions. Lingo provides several ways to interact with the\nfilesystem. Some games asked you for a drive letter and would just loop\nendlessly if they would not find the file they wanted. Others were a bit smarter\n\u0026ndash; on Windows, for instance, they would look for a hardcoded file name on all\nthe drive letters and crash if there was no match.\u003c/p\u003e","title":"On the right path"},{"content":"Hello!\nThis will be short, as last week was rather slow. I mostly finished shoring up all the areas where Director palettes can be tested and set \u0026ndash; in the frame palette channel, with the puppetPalette command, with the movie-wide default palette, and also with the palette of cast Lingo. As I look back at my commit log, I realize that this took me many more commits than I expected. There are still some issues that some of our new test targets, including the 1991 title The Riddle of the Maze, recently revealed. As of this morning, though, this game\u0026rsquo;s elegant artwork has been restored:\nApparently, before Director 4, palette castmembers were forced into the same order that they are stored. If you reorganize them in the cast window, they will actually revert to a default position on save \u0026ndash; and this position seems to be in the order of palette creation. Also, Director 3 Macintosh format has a slightly different way of storing palette channel information in the frame. (I have still to push the patches for titles that have this variation.)\nI also finally got some of the titles that @trembyle had mentioned on the Director wiki, including the aforementioned Maze. @trembyle has done some immense work testing many new titles for us, and today I enjoyed investigatinCEg some new bugs in new titles. Playing with these new games was a nice breath of fresh air from the targets that we had been testing since the beginning \u0026ndash; like Spaceship Warlock and Chop Suey and The Apartment.\nMy other big task last week was working on the text selection interface. When I think back, I believe my first experience with Director happened when I was pretty young; it was a typing game that also depended heavily on text selection. I remember this game as Director because it crashed once and I distinctly recall the Director projector icon. @sev had done most of the algo work in the MacGUI side, but I needed to write a bit more interface and do lots of testing to discover what was behind a selection offset offset bug.\nOnce I finish up the palettes and add a few new targets that I found, I will be working on supporting movies that have \u0026gt;8-bit colour. If you look in the graphics code, there are tons of const byte * declarations everywhere, so those will be changed out for a more general implementation. There are also bitmap decoding issues with greater colour depths that I need to look into. This task, a fairly big one, will be a nice way to round out my GSoC work on our Director engine.\n","permalink":"/posts/gsoc-2020/fresh-air/","summary":"\u003cp\u003eHello!\u003c/p\u003e\n\u003cp\u003eThis will be short, as last week was rather slow. I mostly finished shoring up\nall the areas where Director palettes can be tested and set \u0026ndash; in the frame\npalette channel, with the puppetPalette command, with the movie-wide default\npalette, and also with the \u003ccode\u003epalette of cast\u003c/code\u003e Lingo. As I look back at my\ncommit log, I realize that this took me many more commits than I expected. There\nare still some issues that some of our new test targets, including the 1991\ntitle \u003cem\u003eThe Riddle of the Maze\u003c/em\u003e, recently revealed. As of this morning, though,\nthis game\u0026rsquo;s elegant artwork has been restored:\u003c/p\u003e","title":"Fresh air"},{"content":"This week, I worked on implementing a few Lingo commands that required some significant backend work, but not much in the rendering code where I have spent so much of my time. I mentioned that I had worked on a custom cursor implementation, and I spent the first part of the week fixing bugs there. Now cursor bitmaps like the starfish on the island are properly displayed at the proper position, whereas after my initial work just a black box showed.\nEarly in the week, I fixed a subtle rendering bug that had plagued Spaceship Warlock for a while. You\u0026rsquo;ve seen how the Stambulian policemen in Warlock were bright green; well, this was about the same as the keying colour that the MacGUI was using for border transparency. Once I spotted this, the fix was easy \u0026ndash; and also prevented a redundant surface copy. (Yay for performance improvements!) Here you can see how the erroneously applied transparency actually gave a nice look to an otherwise bland wall in Stambul:\nI also finished the implementation of custom colour palettes. For a long while the opening to Chop Suey looked all psychedelic. It turns out that a recent refactoring swapped around the order of palette loading so ScummVM was given the wrong palette to use. My partial fix for this revealed that our recently-added target Majestic used a castmember palette, which had been loaded before \u0026ndash; albeit improperly. So over the weekend I expanded our Director palette manager to support custom palettes alongside the half-dozen default Mac ones. This also brought along basic support for the puppetPalette command, which controls the palette from Lingo. Now, Chop Suey and Majestic are looking quite handsome:\nThis project came later in the week, however. I first implemented sound fading, which more intense than I first knew. Since multiple movies can be running at once, my knee-jerk blocking fade loop didn\u0026rsquo;t work out. Instead, I needed to integrate the sound fade with the existing score stepping methods. I\u0026rsquo;m amused that that this was one of my largest commits for the week. (Thankfully, though, transitions do seem to block in the original \u0026ndash; that would be a pain to refactor.)\nFinally, I scratched my head for a while on an issue that @sev has since begun looking into. An interesting Director target is Macromedia\u0026rsquo;s own guided tour, which takes you \u0026ldquo;behind the scenes\u0026rdquo; at their studios to introduce new features of Director. Our renderer implicitly assumed that bitmap sprites had the same dimensions as the underlying castmembers, unless the dimensions had been modified from Lingo. Well, our smartly-dressed friend from the guided tour dismissed that theory:\nWhat\u0026rsquo;s on the left is the original sprite (plus arms), and on right is the original castmember. ScummVM draws them both the same size. I would never have noticed, except that the sprite for his moving mouth appears all out of place when he isn\u0026rsquo;t the right size. Director does indeed have an option to scale individual sprites in the score, and we were reading this information in for bitmaps\u0026hellip; but when I tried to use it there were puzzling discrepancies in the dimensions we expected and what the file clearly said. I still haven\u0026rsquo;t figured out why.\nIt\u0026rsquo;s been a good week over all, with interesting tasks both in and outside GSoC. You\u0026rsquo;ve perhaps seen on my bio that I like playing music. One of my friends recruited me to play piano for her upcoming violin competition, so when I need a break from coding I spend a few hours with the interesting sonorities of the great American composer Samuel Barber. And, at university on the weekends, I am working on using machine learning to control dielectric elastomers \u0026ndash; smart materials that show much promise for soft robotics.\n","permalink":"/posts/gsoc-2020/below-the-surface/","summary":"\u003cp\u003eThis week, I worked on implementing a few Lingo commands that required some\nsignificant backend work, but not much in the rendering code where I have spent\nso much of my time. I mentioned that I had worked on a custom cursor\nimplementation, and I spent the first part of the week fixing bugs there. Now\ncursor bitmaps like the starfish on the island are properly displayed at the\nproper position, whereas after my initial work just a black box showed.\u003c/p\u003e","title":"Below the surface"},{"content":"Hey there!\nMy big showcase for the week\u0026rsquo;s work is a few scenes from the kids\u0026rsquo; game Chop Suey, one of our primary Director 4 test cases:\nJust a few weeks ago, Chop Suey ran at an almost unplayable crawl in ScummVM. Part of this was its reliance on Matte inks, for which I implemented a simple surface caching scheme and shaved about 20% off our buildbot\u0026rsquo;s target test time for Spaceship Warlock. This also made Chop Suey run much faster, though it still consumed CPU.\nLast week I called Chop Suey a Lingo-heavy game, and I was referring to how much it controls animation via puppets and the updateStage command. Because, as you saw, its cursors are bitmaps and certainly do not fit in the standard 16x16 Macintosh cursor box, Chop Suey introduces its own mouse update code and calls for the stage to be updated several dozen times each frame. Most of the inefficiencies were here.\nI spent the early part of the week in much trial-and-error, working out the pieces of the renderer that were most inefficient under such repeated application. The idea is to do a little bit of work up front \u0026ndash; checking flags and so forth \u0026ndash; so the expense of redrawing a region of the screen is saved. (As I have realized, even when working on Chop Suey, very subtle bugs can arise from forgetting to check a rendering flag.) Even at usual framerates without much Lingo that doesn\u0026rsquo;t matter very much, but Lingo-heavy games like Chop Suey have shown dramatic improvement.\nI also implemented another feature that is notable in Chop Suey by its absence. I said that Chop Suey does its own cursor handling. Well, the window manager was still drawing a regular cursor atop the bitmap, which looked pretty ugly. Near the end of the week, though, I added a flexible cursor class for the three cursor types Director can use: built-in cursors, cast (bitmap) cursors, and resource cursors. The last type is important for Majestic: Alien Encounter, but I haven\u0026rsquo;t seen custom cursors used much elsewhere. It was fun to implement, though. As a nice byproduct in Chop Suey, the default cursor is now properly turned off.\nOh, and I also spent most of a day trying to discover why some textboxes in Spaceship Warlock weren\u0026rsquo;t rendering properly, along with some other nettling MacGUI issues. The issue actually lay in the cast loading code, which I hadn\u0026rsquo;t touched much, but it\u0026rsquo;s always satisfying to squash a bug and learn more about the codebase in the process \u0026ndash; even if your \u0026ldquo;fix\u0026rdquo; breaks other stuff. :)\n","permalink":"/posts/gsoc-2020/lots-of-chop-suey/","summary":"\u003cp\u003eHey there!\u003c/p\u003e\n\u003cp\u003eMy big showcase for the week\u0026rsquo;s work is a few scenes from the kids\u0026rsquo; game Chop\nSuey, one of our primary Director 4 test cases:\u003c/p\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/kGMHHfJx8AU?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003cp\u003eJust a few weeks ago, Chop Suey ran at an almost unplayable crawl in ScummVM.\nPart of this was its reliance on Matte inks, for which I implemented a simple\nsurface caching scheme and shaved about 20% off our buildbot\u0026rsquo;s target test time\nfor Spaceship Warlock. This also made Chop Suey run much faster, though it still\nconsumed CPU.\u003c/p\u003e","title":"Lots of chop suey"},{"content":"Hey there!\nAfter last week\u0026rsquo;s post, I nearly finished with the last major piece of the ink types \u0026ndash; applying foreground and background colours on the fly. We had some idea of when this colour-application process took effect, but deducing the rules and working out the patterns took a while. I have gained a new appreciation for the power of bitwise operations through this process. My next step will be extending all this logic to other colour depths, but I probably won\u0026rsquo;t get to that this week.\nIt\u0026rsquo;s getting late now and I can\u0026rsquo;t find the test movie I had made to demonstrate this work. I\u0026rsquo;ll look at it tomorrow and post a video demonstration of my work then.\nThere is still some optimization that must be done, including eliminating my reliance upon the window manager\u0026rsquo;s slow colour finder and implementing some sort of colour caching. (The inked operations are often not applied directly to the colour value; it must first be split into its components and then recombined in the palette space.)\nI also performed some fine-tuning on the data structures used for rendering, to ensure that our pixel-based callback is quite fast. Lots more refactoring went into that. Finally, last week I implemented some obscure features, like the constraint and stretch of sprite. The latter allows a sprite to be arbitrary scaled to another bounding box, and implementing that feature largely finished my goal of having self-contained blitting routines for our engine.\nMany of the tasks currently in my Trello channel are concerns with MacGUI elements that don\u0026rsquo;t impact most real games. These bugs will still take some work, but as I am working on those I also want to get the graphics in Chop Suey (and other Lingo-heavy titles) running smoothly and efficiently. Today I chased bugs and inefficiencies in the rendering pipeline. This is a hefty task, as Chop Suey often uses about 70-75% of my system\u0026rsquo;s CPU when it is running in ScummVM. With the discoveries I made today, however, taking the slack out of the renderer should be eminently doable.\n","permalink":"/posts/gsoc-2020/rendering-my-progress/","summary":"\u003cp\u003eHey there!\u003c/p\u003e\n\u003cp\u003eAfter last week\u0026rsquo;s post, I nearly finished with the last major piece of the ink\ntypes \u0026ndash; applying foreground and background colours on the fly. We had some idea\nof when this colour-application process took effect, but deducing the rules and\nworking out the patterns took a while. I have gained a new appreciation for the\npower of bitwise operations through this process. My next step will be extending\nall this logic to other colour depths, but I probably won\u0026rsquo;t get to that this\nweek.\u003c/p\u003e","title":"Rendering my progress"},{"content":"Another week has gone by quite quickly. After taking some time off for Independence Day here in the US, I can\u0026rsquo;t believe that another Monday has passed. Last week I talked about a major update to our renderer, and I finished that pretty early last week. There was some major refactoring involved, but my work \u0026ndash; splitting out our renderer into a Stage class and moving to traditional dirty-rects handling \u0026ndash; worked well with some of the major refactoring that djsrv had been wanting to do for a while. Going into this week, our engine\u0026rsquo;s code is far more modular (thanks primarily to djsrv), and the graphics are looking good. All this we showed off to John Henry Thompson last Thursday.\nFirst, I finished implementing the puppetTransition command, which allows you to call transitions from Lingo. As part of this, I reworked the transitions pipeline to support only drawing a transition on the changed area of the screen. This took a lot more work (and many paper sketches) more than I was expecting, as some of the transition algorithms had interesting behaviour when I tried to clip them.\nI also did some more work on the ink types, including making an efficient interface for the ink types that use implicit mattes or masks. Over the weekend I worked on what was for a long time a big irritation of mine \u0026ndash; sprites with scripts did not highlight (or, in Director parlance, hilite) on click. When I tried to work on this before, I found that simply testing for a script on the sprite was far too broad; there were many erroneous inversions. It turns out that for bitmaps there was a special flag, and for shapes (as far as I could discern) only one ink type where this effect showed. I hadn\u0026rsquo;t looked much at the Director file format before, but I found where that flag was and also uncovered some other unknown fields in bitmap casts (primarily palette information). Working there led me to some nice condensing of our sprite code, which I pushed this morning. That\u0026rsquo;s one more step to making The Apartment realistic!\nOverall, though, last week felt like mostly under-the-hood changes and small optimizations to individual movies. Right now I\u0026rsquo;m working on the graphics code for efficiently setting the foreground and background colour of puppeted bitmap sprites, and rendering this on-the-fly.\n","permalink":"/posts/gsoc-2020/that-was-fast/","summary":"\u003cp\u003eAnother week has gone by quite quickly. After taking some time off for\nIndependence Day here in the US, I can\u0026rsquo;t believe that another Monday has passed.\nLast week I talked about a major update to our renderer, and I finished that\npretty early last week. There was some major refactoring involved, but my work\n\u0026ndash; splitting out our renderer into a Stage class and moving to traditional\ndirty-rects handling \u0026ndash; worked well with some of the major refactoring that\ndjsrv had been wanting to do for a while. Going into this week, our engine\u0026rsquo;s\ncode is far more modular (thanks primarily to djsrv), and the graphics are\nlooking good. All this we showed off to John Henry Thompson last Thursday.\u003c/p\u003e","title":"That was fast!"},{"content":"Hello again!\nThis week wrapped up the fourth week of coding, which means that there are about 8 weeks left until GSoC finishes and it\u0026rsquo;s time for me to go back to school. This week, I spent the early part of the week fixing up our rendering pipeline. It is fun to work on, since it\u0026rsquo;s so fundamental to the engine, but many bugs are quite difficult to track down. A big part of this was more closely integrating Director\u0026rsquo;s internal state memory, now kept in the Channel class that I wrote, with the \u0026ldquo;widgets\u0026rdquo; that the window manager knows about. A tight interface with the window manager will become essential quite soon, when we implement MIAWs (movies in a window).\nWhen I got tired of tracking down obscure artifacts and bugs near the middle of the week, I revamped the interface that we use to draw Director transitions. There are about 50 different transition types, which sev had implemented before, but rather than having to keep a copy of the old frame and then draw the new frame back over it \u0026ndash; as we had to do before \u0026ndash; I put in a more natural approach of rendering the next frame over the current one, in accordance with the transition. This cut out some unnecessary surface blitting that was happening every frame. Working with the transitions took way longer than I expected, and I\u0026rsquo;m still not quite sure why.\nI also spent some time reviewing our Trello board and picking out easy tasks for a break or marking complete those reports of broken movies, etc. that some side effect had fixed along the way. A nice 5-minute fix was enabling our text renderer to use different colours in each chunk (font run). Now, Warlock is looking even more realistic, and just that little bit of white text helps so much.\nI hear that later this week sev, djsrv, and I will do a catch-up meeting with John Henry Thompson, the inventor of Lingo. In this meeting I plan to show off some of the work I have done with Director\u0026rsquo;s ink types. That was the other major project I worked on last week. The inks are all the different ways that Director can draw and composit sprites on the screen. They range from a simple copy of the whole bounding rectangle area to mattes to an inversion and composition with what\u0026rsquo;s underneath. Many of them have poorly documented behaviour, at least in edge cases, and when transforming colours the depth must always be kept in mind. Director itself had different render loops depending upon the colour depth. I don\u0026rsquo;t think we will quite need that, but the bitwise operations I put in will require much more testing and fine-tuning across the spectrum. I\u0026rsquo;ll be working on this more in the next few days. Here\u0026rsquo;s a little demo of the ink types in action. There are still some bugs in here.\nI\u0026rsquo;d better get back to work now, because I am preparing another update to the renderer that should deal with many of the issues that have lurked in the background in the last few weeks. Stay tuned for some news on that!\n","permalink":"/posts/gsoc-2020/third-way-done/","summary":"\u003cp\u003eHello again!\u003c/p\u003e\n\u003cp\u003eThis week wrapped up the fourth week of coding, which means that there are about\n8 weeks left until GSoC finishes and it\u0026rsquo;s time for me to go back to school. This\nweek, I spent the early part of the week fixing up our rendering pipeline. It is\nfun to work on, since it\u0026rsquo;s so fundamental to the engine, but many bugs are quite\ndifficult to track down. A big part of this was more closely integrating\nDirector\u0026rsquo;s internal state memory, now kept in the Channel class that I wrote,\nwith the \u0026ldquo;widgets\u0026rdquo; that the window manager knows about. A tight interface with\nthe window manager will become essential quite soon, when we implement MIAWs\n(movies in a window).\u003c/p\u003e","title":"A third of the way done!"},{"content":"Hey guys!\nI 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\u0026rsquo;s origin and destination. Even though I haven\u0026rsquo;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.\nMoreover, 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.\nI also modified much of my code from the previous weeks to get a major part of our benchmark kit, Macromedia\u0026rsquo;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\u0026rsquo;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 \u0026ndash; 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.\nIt 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\u0026rsquo;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.\nOn 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 \u0026ndash; and even then, it was my choice to stop and not a misplaced null pointer\u0026rsquo;s. :) This is an exciting progress milestone for us. Ah, the beautiful Belshazzar!\nOn Friday, I didn\u0026rsquo;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\u0026rsquo;t use Mohawk. Strangerke warned me a few weeks ago that the executable was very complicated, but I found some success using moralrecordings\u0026rsquo; Mr. Crowbar to peer inside the assets. They seemed like easy RIFF, but nearly all the chunks seem to be named some variation of \u0026ldquo;igod\u0026rdquo; and there\u0026rsquo;s some extra structure hidden inside the chunks. Bitmap and waveform data is clearly visible, though, so there\u0026rsquo;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 \u0026ndash; plus Director, of course.\nAnyway, I\u0026rsquo;d better get back to Director. I\u0026rsquo;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.\n","permalink":"/posts/gsoc-2020/making-progress/","summary":"\u003cp\u003eHey guys!\u003c/p\u003e\n\u003cp\u003eI started off last week attempting to get the infamous \u003ccode\u003ezoomBox\u003c/code\u003e working with the\nnew rendering pipeline I wrote for our Director engine. A zoomBox effect is the\nclassic window movement animation in classic Mac OS: When you open or close a\nwindow, you see many spectral rectangles in between the window\u0026rsquo;s origin and\ndestination. Even though I haven\u0026rsquo;t seen any games actually use it, this function\nwas the first motivation I was given reworking the rendering pipeline. Before,\nwe could not look ahead into the next frame to get the dimensions of a sprite.\u003c/p\u003e","title":"Making progress"},{"content":"Last week, I finished up the tasks that had dragged me down, and then I moved on to sundry other topics. Now our Director engine renders The Apartment, a demo movie that MacroMind and later Macromedia developed for the early Directors, in greater fidelity. One of the issues that took a while to figure out was that, in the Director 3 version of The Apartment, GUI buttons had a special type that were not stored in the usual place. To our engine, they just looked like regular texts, but they were not. I also realized how tedious it is to fiddle with a few magic numbers until the GUI elements came out looking right. I still need to get QuickDraw shapes fully transported over to widget-based rendering, which I plan to do later this week.\nAfter my PR was merged, sev granted me write access to the repository, so I could commit fixes on-the-fly. This was very helpful because, as you can see, I have fixed many little bugs in my code since then. Over the latter half of last week, I grew well acquainted with the technical methods in the Mac text-rendering class that sev wrote, and I did some major refactoring to merge the two editable- and non-editable variants. Then, with this, I began implementing some Lingo entities that permit some Director-based customization of text fields. Some of this, such as changing fonts and line widths and such as a movie plays, I have not yet pushed.\nAn issue that I spent several hours investigating last week involved text background colours in Spaceship Warlock. Ultimately, with sev\u0026rsquo;s help, it turned out that our loading code was not reading the palette information for text cast members correctly. Thus, the hack had been to give all texts the background colour of the whole Director stage. This worked well sometimes \u0026ndash; but sometimes individual movies in Warlock had a white stage covered by the black rectangles, and sometimes they had a black stage. So, I confronted strange inconsistencies like this:\nOnce we got to the root of the issue, texts rendered correctly, no matter the underlying stage colour:\n(I was confronted by those cops so many times one day, I had a dream about them.)\nTracking down strange rendering bugs like these has been the majority of my work over the past few days, and I will get back to it again today in tracking down some long-standing issues in The Apartment. Debugging is often frustrating, especially when I judge myself for going too slowly, but it is quite pleasant to see my fix for an issue pushed \u0026ndash; and often the solution was far away from where I thought it would be. Well, I\u0026rsquo;d better get to it for this week.\n","permalink":"/posts/gsoc-2020/busy-week/","summary":"\u003cp\u003eLast week, I finished up the tasks that had dragged me down, and then I moved on\nto sundry other topics. Now our Director engine renders The Apartment, a demo\nmovie that MacroMind and later Macromedia developed for the early Directors, in\ngreater fidelity. One of the issues that took a while to figure out was that, in\nthe Director 3 version of The Apartment, GUI buttons had a special type that\nwere not stored in the usual place. To our engine, they just looked like regular\ntexts, but they were not. I also realized how tedious it is to fiddle with a few\nmagic numbers until the GUI elements came out looking right. I still need to get QuickDraw\nshapes fully transported over to widget-based rendering, which I plan to do\nlater this week.\u003c/p\u003e","title":"A busy week"},{"content":"Last time, I promised I would give an update on QuickDraw and the Macintosh GUI emulator. This second major part of reworking the rendering pipeline, which i thought I could finish in the first week of coding, has taken more time and gone deeper than I expected. When I am coding I am well aware of wasting time in shaving the yak. I mentioned in our Discord the other day that I might have experienced mission creep. Let me explain.\nMY initial goal was to move over Director\u0026rsquo;s text rendering to the enhanced Mac text class that sev wrote for us earlier this year. I spent the early part of that week implementing the different kinds of text properties that Director permits putting on text \u0026ndash; straightforward effects like shadows, framing, and proper text alignment. (I now realize what complex work goes into graphics management for even a simple text editor.) Then, I created a new class (widget) specifically for buttons and did the similar work for the classic Mac\u0026rsquo;s three button styles. This took me to about Wednesday last week, and this part of my work went fairly quickly. I even got several movies mostly working, including the stageColor movie (a simple one that flashed the emulator background color very quickly \u0026ndash; I won\u0026rsquo;t show it because I myself am photosensitive). This showed off saveral pieces of the work I had done: Drawing text with transparency and extra features, as well as reading button states properly.\nI then realized that in order for the window manager to process widget events in the proper order, it needed to have some concept of priority \u0026ndash; a mirror of channels in Director. So then, I thought, we have only four major visual cast types in our Director engine: text, buttons, shapes, and bitmaps. Why not have all those be known to the window manager as widgets? This would accomplish another of the refactoring tasks I had been given, reducing the bloat of the Stage class by moving drawing methods away from there.\nThen, I got rather bogged down later in the week in understanding the minutiae of the window manager, and I realized that much of the outward-facing code in our Director events manager could be handled better in the MacGUI manager instead; this was added to my list of items to finish. (You see what I mean about shaving yaks.) There were a few other version-specific irritations that I also tried to figure out; this took me into the weekend.\nI soon had a lot of deeply connected tasks that seemed rather overwhelming as the first week ended; I realized that I had expanded the range of my next PR far beyond where I initially started. Until the weekend, I thought I was making good time. After I did not do much over the weekend to catch up with mechatronics research lab at where I work at university, I realized that trying to change everything at once is an excellent way to get behind. I do not want this to happen, so I talked to sev yesterday to help get me back on track.\nI will post some screenshots later this week, once my improvements are complete enough to merge at least some of them. I believe our prime test move, The Apartment, will soon yield some good results in previously broken movies. I have known for a while my tendency toward over-engineering and trying to \u0026ldquo;go solo,\u0026rdquo; so confronting such mission creep in the very first week of coding was quite helpful for me.\nDon\u0026rsquo;t worry, you\u0026rsquo;ll hear from me again soon!\n","permalink":"/posts/gsoc-2020/widget-weeds/widget-weeds/","summary":"\u003cp\u003eLast time, I promised I would give an update on QuickDraw and the Macintosh GUI\nemulator. This second major part of reworking the rendering pipeline, which i\nthought I could finish in the first week of coding, has taken more time and gone\ndeeper than I expected. When I am coding I am well aware of wasting time in\n\u003ca href=\"https://en.wiktionary.org/wiki/yak%5Fshaving\"\u003eshaving the yak\u003c/a\u003e. I mentioned in our Discord the other day that I might have\nexperienced mission creep. Let me explain.\u003c/p\u003e","title":"In the widget weeds"},{"content":"Google Summer of Code 2020 officially started today, although throughout May I worked regularly on the Macromedia Director engine\u0026rsquo;s rendering pipeline. In the middle of May I replaced the long-standing frame-based renderer \u0026ndash; which redrew the entire screen every frame \u0026ndash; with a channel-based approach. This first part of the project brought me in touch with most of the other ScummVM Director devs, which was a nice touch for GSoC\u0026rsquo;s Community Bonding Period.\nModern operating systems use a desktop metaphor, with folders and notepads and option drawers. Director uses a cinematic metaphor, which works like this: Each movie has some cast members (shapes, bitmaps, text, etc.) which can be instantiated as sprites to appear on the stage (user viewing area). Each sprite inhabits a channel in the score. Rather confusingly, in fact, the terms sprite and channel are almost used interchangeably. One channel can display many different cast members throughout a movie. As you can see, this jargon (I dare not say lingo) departs from the usual understanding of sprite.\nJust as its musical connotation implies, the score compactly describes the activity of each sprite and provides ready access to Lingo scripts and other customizations.\nAs you might imagine from this screenshot of a Director 4 (1994) score, scores can be viewed as large matrices indexed by frames on the vertical and channels on the horizontal. Each entry (cell) of this matrix thus describes one item on stage at one point in time. On each frame, Director draws the sprites in ascending channel order.\nAt first, I naively thought that like Photoshop I could just toggle \u0026ldquo;layers\u0026rdquo; and be on my way. I quickly discovered, however, that in Director this convenience was exactly the functionality that we lacked. The score needed keep track of exactly what sprites were on stage at any given moment. It would no longer be enough to blindly draw whatever the current frame said its sprites were. Our engine needed to think more horizontally, rather than vertically.\nAfter creating numerous test movies to understand Director\u0026rsquo;s rendering rules, I devised a simple mask-based approach. I took stock of all the dirty areas of the screen and just iterated over the channels to redraw the parts of sprites that intersected there. Nothing could be simpler, but it took me quite a while to understand all the eccentricities of the code and complete the refactoring required to get the engine alive again.\nMy approach gives fairly complete consistency with the original. Many difficult commands, like zoomBox, can now work properly. Moreover, my work enabled puppeted sprites \u0026ndash; sprites controlled by Lingo, and not by the instructions in the score \u0026ndash; to work properly. If a sprite is puppeted, its channel in the score is simply not updated with sprites from new frames. The same sprite stays on stage until its puppet is disabled. This was not possible when every frame brought a new set of sprites to draw. But it was trivial when the score kept track of channels and sprites and chose when to update and redraw them.\nMy changes did not enhance much visually \u0026ndash; in fact, there was a regression that drew hideous white boxes instead of transparent hotspots. However, this morning I got to the bottom of those issues, and now Captain Hammer looks as fearsome as ever.\nStay tuned for my adventures with QuickDraw and our Macintosh GUI emulator!\n","permalink":"/posts/gsoc-2020/settling-the-score/","summary":"\u003cp\u003eGoogle Summer of Code 2020 officially started today, although throughout May I\nworked regularly on the Macromedia Director engine\u0026rsquo;s rendering pipeline. In the\nmiddle of May I replaced the long-standing frame-based renderer \u0026ndash; which redrew\nthe entire screen every frame \u0026ndash; with a channel-based approach. This first part\nof the project brought me in touch with most of the other ScummVM Director devs,\nwhich was a nice touch for GSoC\u0026rsquo;s Community Bonding Period.\u003c/p\u003e","title":"Settling the score"},{"content":"This summer, I will be helping bring the Macromedia Director engine to maturity as my project for Google Summer of Code 2020. Tonight I found myself quite deep in a major rewrite of the core rendering pipeline, and when I got tired of that I decided to finally learn how to use Hugo. That\u0026rsquo;s why you are reading this now.\n","permalink":"/posts/gsoc-2020/macromedia-mysteries/","summary":"\u003cp\u003eThis summer, I will be helping bring the Macromedia Director engine to maturity\nas my project for Google Summer of Code 2020. Tonight I found myself quite deep\nin a major rewrite of the core rendering pipeline, and when I got tired of that\nI decided to finally learn how to use Hugo. That\u0026rsquo;s why you are reading this now.\u003c/p\u003e","title":"Macromedia mysteries"},{"content":"Introduction When I was ten, I first started programming with QBasic. Quickly thereafter, I switched to Visual Basic and C.\nWhen I\u0026rsquo;m not hacking away on my beloved ThinkPad 450s, I can probably be found engrossed in Chopin or studying a Vaughan Williams score.\nComputer Archaeology I was first introduced to reverse engineering at Google Summer of Code 2020, where I worked with ScummVM to improve the engine for Macromedia Director.\nDespite COVID, I learned so much at GSoC. My experiences there have defined my primary pastime for the past few years - what I call computer archaeology. I like preserving old software (usually PC games) by reverse engineering their logic/file formats and documenting them in open-sourced code. I call this archaeology there\u0026rsquo;s lots of interesting information from computer generations past, but it\u0026rsquo;s \u0026ldquo;buried\u0026rdquo; in proprietary formats. My job is to \u0026ldquo;dig up\u0026rdquo; this information and put it \u0026ldquo;on display\u0026rdquo; for this generation.\nMainly from the influence of mcrcrowbar, whose author was also contributing to the Director engine in summer 2020, I write most of these archaeology projects in Python. I probably should write these things in C++ for better porting to ScummVM someday, but I haven\u0026rsquo;t changed my habits yet.\nI\u0026rsquo;m also interested in preserving older Microsoft Home software and After Dark modules.\n","permalink":"/about/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eWhen I was ten, I first started programming with QBasic. Quickly thereafter, I\nswitched to Visual Basic and C.\u003c/p\u003e\n\u003cp\u003eWhen I\u0026rsquo;m not hacking away on my beloved ThinkPad 450s, I can probably be found\nengrossed in \u003ca href=\"https://www.youtube.com/watch?v=kHXxWfSAxik\"\u003eChopin\u003c/a\u003e or studying a \u003ca href=\"https://www.youtube.com/watch?v=7R9RA%5FBR%5Fp0\"\u003eVaughan Williams\u003c/a\u003e score.\u003c/p\u003e\n\u003ch2 id=\"computer-archaeology\"\u003eComputer Archaeology\u003c/h2\u003e\n\u003cp\u003eI was first introduced to reverse engineering at Google Summer of Code 2020, where I worked with ScummVM\nto improve the engine for Macromedia Director.\u003c/p\u003e\n\u003cp\u003eDespite COVID, I learned so much at GSoC. My experiences there have defined my primary pastime for the past\nfew years - what I call \u003cem\u003ecomputer archaeology\u003c/em\u003e. I like preserving old software (usually PC games) by reverse\nengineering their logic/file formats and documenting them in open-sourced code. I call this \u003cem\u003earchaeology\u003c/em\u003e there\u0026rsquo;s\nlots of interesting information from computer generations past, but it\u0026rsquo;s \u0026ldquo;buried\u0026rdquo; in proprietary formats. My job is\nto \u0026ldquo;dig up\u0026rdquo; this information and put it \u0026ldquo;on display\u0026rdquo; for this generation.\u003c/p\u003e","title":"About"},{"content":"I am a collaborative pianist, accompanist, and vocalist based in northern Virginia. I regularly play for church, weddings, funerals, and other special events.\nHere\u0026rsquo;s a demo of my choral accompanying: And a demo of me playing piano in a musical theatre pit orchestra: And a demo of me singing a gospel solo: Demos from church and weddings are coming soon!\nMany other arrangements and projects can be found on my YouTube channel.\nContact requests@natgentry.com for more info. A formal résumé is available upon request.\n","permalink":"/music/","summary":"\u003cp\u003eI am a collaborative pianist, accompanist, and vocalist based in northern Virginia. I regularly play for church, weddings, funerals, and other special events.\u003c/p\u003e\n\u003cp\u003eHere\u0026rsquo;s a demo of my choral accompanying:\n\n      \u003cdiv\n          style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n        \u003ciframe\n          src=\"https://player.vimeo.com/video/234249423?dnt=0\"\n            style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" allow=\"fullscreen\"\u003e\n        \u003c/iframe\u003e\n      \u003c/div\u003e\n\u003c/p\u003e\n\u003cp\u003eAnd a demo of me playing piano in a musical theatre pit orchestra:\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/GXNzfgeHZZE?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\u003c/p\u003e","title":"Music"},{"content":"I graduated with a B.S. in Mathematics in 2021, and I have been a professional software engineer since then.\nIf you would like to see my full résumé, please get in touch at requests@natgentry.com.\n","permalink":"/tech/","summary":"\u003cp\u003eI graduated with a B.S. in Mathematics in 2021, and I have been a professional software engineer since then.\u003c/p\u003e\n\u003cp\u003eIf you would like to see my full résumé, please get in touch at \u003ca href=\"mailto:requests@natgentry.com\"\u003erequests@natgentry.com\u003c/a\u003e.\u003c/p\u003e","title":"Tech"}]