It's the beginning of 2026, the start of a whole new year. Lets hope it's a good one. The last year was somewhat trying for me. Not only was there a lot of effort into getting the second M4 engine game, Ripley's Believe It Or Not: The Riddle of Master Lu working, I transitioned straight into working on supporting the other Bagel engine game as well, Hodj n' Podj. And that.. oh that.. it was a game made using the Microsoft MFC Framework.
Since it was a collection of minigames tied together by an overall boardgame, I initially had some hopes of refactoring the codebase to not need MFC code. This would keep things simple and clean, and since each minigame was discrete, it would keep the refactoring complexity down. At least, that was my thinking. I had started doing so with a few minigames, and it worked well. However, it came unstuck when I tried to work on the boardgame "metagame". The code was just too complicated to easily refactor, particularly it's heavy use of various drawing surfaces, bitmaps, and various palette handling code.
In the end, I had to implement a whole new MFC replacement sub-system for ScummVM that could simulate both the core MFC and the underlying Windows control classes so that we could get the original game code to work. And boy did it take a long time to get right. So many special cases to handle. Finicky special cases, such as handling different drawing modes between bitmaps, or palette translation logic that depended on whether a bitmap had a palette assigned to it or not. And the whole event handling. Sigh. Months and months of work getting to a point where Hodj n Podj could finally be run using the original code mostly as-is.
Even now, the MFC layer isn't perfect. Ideally, each MFC window should have it's own drawing surface, but in ScummVM everything blits onto the single screen surface. This causes minor problems in a few places, such as in the Poker minigame, where rendering of the poker buttons can appear partially on top of a foreground dialog being shown. I did experiment in a branch with adding support for separate surfaces that only blitted the visible areas of windows to the screen.. but that caused issues with the "scroll" dialogs, where the transparent sections on the left and right hand sides of the scroll no longer transparently showed screen content behind it any longer. Thankfully, the overlaying issue is just a minor problem, so I've shelved experimenting with it further for now. I've just been too burned out on MFC to want to keep working on it.
Since then, at the end of the year, I've finally felt free to work on other stuff at random. As has been my practice, I spent the Christmas holidays working on porting an existing open source project to ScummVM. And for this year, given some time constraints, I decided to work on a simple one that implements the game Akalabeth: World of Doom. The pre-cursor to the Ultima series:
The project in question was implemented by Paul Robsin, and a backup of the source can be found here. The code was somewhat rough, so I had to polish it up, and fix some bugs. I also re-wrote the code using our view-based engine framework. So in this cleaned version, each screen like the overworld map or the dungeon has it's own view class for drawing, and a centralized event handler and dispatcher that sends events to the views, and makes it easy to switch between them. This saves a lot of framework that Paul's project had to do to control program flow, and simplifies the implementation. The code has been merged into the ScummVM master as a sub-engine under the Ultima engine. It's mostly complete. I just need to do some fixes to the dungeon rendering and combat systems before I call for public testing.
Apart from that, previously at the end of the year I've been reveling in the freedom from Hodj n Podj to flitter between several other projects I may return to once the remaining Akalabeth code has been cleared up. These include:
- I started on an import of the oldest available AGS2 codebase to see if I could get it up and running. This is part of a longer term plan that with an clean stand-alone AGS2 engine without all the code bloat of later versions, it will be easier to disassemble some of the earliest unsupported AGS games to figure out what previously deprecated weird s**t they did and add support for it. Kind of like how the various plugins had to be disassembled so they could be implemented as source.
- Despite my protests about being burned out on MFC, on a branch I made it part of common/ as a enable-able feature, and used it to import the available source code for the game Spycraft. The game doesn't directly use MFC, but it does use raw Windows controls. So it was fairly easy to create a dummy MFC CWinApp application class for the game, and change the game's window creation to use an MFC window class. Currently, the entire codebase is compiling, but something's happening during startup and data loading before anything is displayed. I'll likely return to this first after Akalabeth, since it feels like it's almost to a point where everything will just start working.
- I also made a tentative restart on importing the AESOP32 source code for playing Eye of the Beholder 3. The import is only part way done, so there are still various code files remaining. Primarily some low level code files, which I have the vague recollection had assembly that would need to be converted to C code. Maybe ChatGPT can help.
- Also did some compilation fixes and review of my Wasteland engine.
- One of these days I'll get back to working on it.
- Though come to that, I do still have my Legend engine languishing around - both for the early text parser based games, as well as the later graphical ones of Companions of Xanth, Shannara, and Death Gate.
- That reminds me that I still have a compiling implementation of the Freedink engine, but which has graphical display issues. I was working on a few years back when I suffered a serious accident, and although I logically know it's unrelated, I've just been leery of returning to working on it.
