Did I hear my name?
Personally I think the loading screens should be entirely blank, as it's meant to not break the immersion of the Linking process, yet I can admit the necessary compromise of an indicator for the player that the game isn't hung up (as it does). That said, good arguments could be made for making the screen more interesting and less IC with any number of tasteful additions (vague images, or some nice flyby of the Age you're linking to...?) and of course you're free to do whatever you like. I'd love to see something to change my mind on that whole blank screen thing, because it's frankly somewhat dull.
Anyway, I didn't change much of the client code itself, as I was trying to get the new content in with minimal fallout. That means a lot of things are still similar to their original hard-coded values; this can and should be improved at some point.
Right now, there's essentially three major steps:
- Generate the images - We're using SVG for this because it makes it easy to source-control the originals so anyone can improve them, and I prefer the capabilities of using vector art which allows us to easily re-use the art in other ways later, but if you have something else (like modified screenshots) you can basically skip this step, or make your own export from another standard format. The current render script mostly just fiddles with enabling/disabling various layers on render to simplify the editing of the actual image (you only have to make a particular component once).
- Combine the images - I've used a simple, naïve script to build the resource.dat file, but you can use any tool made for managing Myst V's resource.dat as I adopted the same format for compatibility. I generally used my own m5crypt.py for this, though PlasmaShop supports them as well, AFAIK. If we need more flexibility, it's trivial to bump the resource version and add new capabilities in plClientResMgr. The format itself is very simple: just a list of files and their data all clumped together. Now that I look at it, we should probably add a more complete read/write api to that class itself so tools can be written directly from it as a reference (this was not a primary concern at the time it was introduced, as we wanted to reduce the reliance on the low-res and questionably-licensed resources provided by Cyan). Just add your images to the list of files given to the script as input and they'll be available.
- Use the images - Everything in the resource.dat is loaded automatically on start by plClient, and they're accessible through the singleton to anything which wants them. In this case, the sequence of images for the spinning logo are displayed one at a time (as each frame was pre-rendered) and changes every so many frames. Currently this means you can display one or more static frames of an image or animation without many changes. If you want something more complicated, plProgressManager.cpp will need some modifications.
Hopefully that's clear. It's fairly simple overall, at least for the current usage. It would be nice to make some of it more generic, but other more important areas of the code have taken precedence.