I know it's slow going, but over the weekend I had a couple of hopeful experiences:
 
1. I saw TAFA running unmodified (except that I had to remove an EXE packer that I use) on Wine on Linux.  There were some issues with OpenGL overlaying the button bar, and there may be some performance issues with audio, but this isn't the way I'd actually try a Linux version.  I'm looking into using Winelib to recompile TAFA as a native Linux ELF executable, at which point I can wedge in pieces that need to behave differently for Linux.  (Stick with me, this does actually apply to the Mac   )
 
2. Though my attempts with Darwinelib (Winelib for Darwin/Mac OS X) have met with failure at trivial points, I've seen posts from another user with a similar problem who did get compilation to work.  Darwinelib is nearly up-to-date with the main Winelib code source, so if I can build a Linux build, it seems reasonable I can go through the same process to make a Mac OS X version.  And since it's a recompile, it'll be a universal (PPC or x86) build at full speed.  Also, with any luck, the GCC 4.0 autovectorizing optimizer will be able to give Mac users faster performance (at high subdivision, profiler programs claim that about 80% of TAFA's time is spent on vector addition, so an auto-vectorizer should be able to make use of Altivec/SSE2 instructions to run 2-3 times faster)
 
The path I had started down was to write my own mini-Darwinelib, but if I can piggyback on the last decade's worth of work, this'll go MUCH faster.  Winelib already supports the Platform SDK, GDI, OpenGL, DirectInput, and DirectSound, which is the entire set of Windows APIs that I use.  I remain hopeful, but do apologize for the slow progress.
 
Mac

There is one scary issue -- Wine bug # 2398 (I think).
 
Back in '05, they completely rewrote their subwindow handling, and that has created a problem where OpenGL rendering always occurs to the top level window and overwrites menus/buttons in that window.  If I were going to try to release Windows-TAFA and just telling users to use Wine, that would be a problem -- I'd be subject to whatever level of support they had at the time.
 
Fortunately, I intend to use Winelib for porting, and that gives me an option.  Slightly ugly during window resizing/moving, but a workable temporary solution until they get this hammered out (and they do appear to be working on it reasonably seriously).
 
I only have one real OpenGL viewport -- the one in the main view window.  That window is created as a subwindow (child window) of the main view window.  I can "simply" change it into a borderless top level window, at which point the OpenGL part will be fine.  I'll have to sort out some depth sorting issues between it and the main view window, and when you resize/move the main view window you'll probably get some jittering as the OpenGL window lags behind (in the worst case, I'll have to rely on a timer to notice that the main view window changed and move the OpenGL window appropriately).  None of this will affect normal usage, once you've got your windows where you want them, though.  So I think I can cover this problem, and if/when they get OpenGL child windows working properly, I can switch back to my current logic pretty easily.
 
Mac

Hey Mac,
 
I pretty much thought that a MAC version was a dead issue so I haven't been checking back. I imagine my assumptions are right..but I'll keep checking back one in a while, just in case!
 
As far as your window space question went...I'd ba happy with anything that works!
 
Pete

Really?  It sounded like Mac was well on the way with Darwinelib.  However, since there still isn't one available, it does seem pretty disheartening.
 
A Mac UB version of TAFA would probably sell "well", since Mac is an untouched market, where Windows LW has to be pretty filled up w.r.t. LW owners buying TAFA, I'd think.
 
Any chance the issue might get re-examined?