Although there are published specs for writing 3rd party After Dark modules (Those also work with Tom Dowdy's "DarkSide of the Macintosh"), some of the more treasured ones are commercial offerings that
violate the rules, published by Berkeley Systems themselves.
Berkeley Systems, in “Star Trek”, “Disney”, and “AfterDark v3.0” and later, used custom shared libraries and custom loaders and such, and were multimodule incompatible as a result. Some of the sharing of libraries was to allow source code to compile on Windows or Mac, some was to aid in loading stacks of art taken from Macromedia (Adobe now) Director (Shockwave eventually) that were then tweaked in Equilibrium's 400 dollar DeBabelizer :
http://www.manifest-tech.com/ce_photo/debab_batch.htm
So to run ALL the modules under OS X no matter what, an engineer tasked with the big puzzle needs to probably just select a full OS to emulate, then to make it work to feed into an output area when requested, and to have the system "booted" and idle until summoned by this OSX consumer task.
Color Quickdraw has "bottleneck" interception points, and the wide range of issues in performing a partial port end up being as much work as porting a full emulator of a machine.
Emulating PowerPC to emulate 68020 is foolish (Apple only ever wrote a 68020 emulator with one extra opcode MOVE16). Therefore the best solution is to emulate a 68040 or 68020 and run a system old enough to run EVERY normal commercial After Dark module. This omits the few that require PowerPC (terrains?), but allows the largest total number of modules.
For speed on slow PowerPCs, the emulator should probably be a tweaked emulator that can dynamically "recompile" 8K (or 4k) pages marked as "modded" or "still-unmodded" similar to most modern 68020 emulators. It allows self modifying code, though rarely encounterred. Some might call this speed up “JIT” (dynamic translation).
http://en.wikipedia.org/wiki/Just-in-time_compilation , as created and proposed by the famous Tom Pittman for mac users. In fact Apple's cruddy 68020 emulator by Gary Davidian used in Mac OS was sped up triple-speed by ideas from Tom Pittman's award winning paper at 1994 Mack Hack computer conference :
http://www.mactech.com/articles/mactech/Vol.10/10.09/Machack94/index.html
Truthfully, a modern CPU would not need a super-optimized 68020 emulator with Dynamic Translation but
it would need to avoid the abomination of attempting to emulate a PowerPC emulating a 68020.
A Mac OS x program would be fed data when a ‘Gestalt selector’ being monitored in the emulated environment indicated that a screen saver was active and finally rendering to screen buffer (the SAVC gestalt). Screen doubling and quadrupling would be needed to fill out modern large screens. Some blurring and upsampling would be welcome.
Color Table cycling from the emulated world would "just work" and 60 FPS should be possible.
Saving CPU cycles could be achieved by having emulator mark "dirty" horizontal pixel buffer lines needing update since last transfer out to destination graphics buffers. It could do so by forcing access errors on the pages, but this overhead might be far too much to bear, and instead full screen xfer waste might be unavoidable.
Modern GPU can be used for the scaling, or the same code used in VLC for stretching could be used.
Decoupling the output from the emulator allowing dropped animation frames, while preserving proper timing animation+music heartbeat is preferred, to avoid the insidious "Flash Animation" atrocity of stuttered-velocity of objects being affected by dropped frames. Therefore consumer-producer screen buffer tasks should be decoupled in this project.
I propose using OS 7.5.5 through 7.6.1 (or 8.1) in the emulated environment, mainly because later versions are biased against 68K in some ways for performance. Additionally, T/MON debugger works fine in versions of mac before 8.0, and without Viacom Cable's T/MON (T-MON, TMON), hacker work gets done a lot slower. Way slower than when forced to use Motorola’s MacsBug.
An emulator comes to mind that is easy enough to use, and capable of OS 7.5.5 through 7.6.1, and uses 68020 : Basilisk 2, and Gwenolé Beauchesne's sometimes problematic "JIT Basilisk II". It will allow 128 megabytes of system RAM to play with, does 68040 (possibly patches roms for 68060 too, and Amiga, UNIX, BeOS, Windows 9x, Windows NT (win2000, XP etc) Linux/i386, Linux/x86_64, FreeBSD/i386 and MacOS X for Intel.
So basically we are looking at highly customizing and resubmitting patches back, to a copy of the May 2006 Basilisk 2 fork :
http://gwenole.beauchesne.info//en/projects/basilisk2
Because it is a 68K being emulated the speed of the screensavers will be very fast on Intel hosts. PowerPC hosts is another problem, because JIT Basilisk 2 fork was not targeted for it, from what I recall, but original Basilisk 2 source for BeOS used PowerPC, so maybe something is possible.
For now we will concentrate on Intel, because a very fast Hackintosh can be built to run OSX on 500 dollars of hardware. I will not forget PowerPc though.
For simplicity we will run the emulator on one task (one cpu) and the assistant feeder to the OpenGL/CoreGraphics scaler output on another.
For amusement sake, we might want to run two emulators (or more) on other tasks (cpus) and multiplex their outputs together in a blend to create our own brute force MULTIMODULE for naughty arrogant screensaver modules that are not Multimodule-capable.
As a crowning achievement, we might run other peoples modern OS X modules as well, adn blend them over or under the old Mac OS 7 modules.
So much to think about.
The remaining annoying aspects are mouse interaction, and picking a proper after dark engine product capable of running everything ever written, but still able to be hacked on a bit, but thats OK.
Because screensaver modules have access to the Macintosh OS, and all of Quickdraw, the only solution to run all screensaver modules is in the form of color capable Mac OS emulation.
But full emulation containment allows one thing I always wanted since before 1990 :
running AfterDark compatible screensavers as a desktop layer, and running AfterDark compatible screensavers very very early boot during the entire Grey-Screen boot screen.
Because of that showstopping feature (OSX boot time screensaver effects), I predict NEW people will start writing "Darkside of the Mac" and "After Dark" modules in 2008 / 2009 following the old MacOS 7 After Dark SDK. I know I would. We can’t call it “Before Dark” because that product name was taken already by a popular desktop pattern tool. We could call the feature “Before Darkside” though.
Please excuse the phrase 'ScreenSaver; thoughout my post. I call them “ScreenWasters” and have all my life, even when I wrote them for a living. Though while at work on company equipment I had to run them and not fade the screen to black as part of testing other peoples work for QA testing. Nowadays I do run “screen savers”, but also kill the screen to black after about an hour of the screenwaster running. (I am not "cool"). But I understand others are, and seek more coolness. Boot-time After Dark modules I deem to be ultra cool.
The Mac needs some more coolness added, people just need to envision it.