Of course, not every function from the original is implemented - some simply don't make sense with BeOS. Others have been replaced with BeOS versions that accomplish the equivalent objective.
At this point the following examples have been successfully converted. If all you need is what are in these examples, then either porting your MacOS SpriteWorld 2 application (the SpriteWorld part of it at least) or creating a new SpriteWorld application for BeOS should be fairly straightforward.
The current implementation has only been tested for PPC. An Intel version may be simply be an issue of compiling. SpriteWorld 2 for BeOS requires R3.
The other option would be to absorb the SpriteWorld mechanics into a BeOS "native" implementation, e.g. use classes, some even derived from the Interface Kit. This is in fact how I ported the v2.0 sources. It has the advantage of fitting right in to the BeOS and a BeOS application.
For v2.1 I have decided to go to the first option of being as true to the original code as possible for a number of reasons. For one, I really do want to keep the code current with the MacOS side with as little effort as possible. Also, I would like to encourage people who have written MacOS apps with SpriteWorld to move them to BeOS. It is also still possible to create a nice BeOS class (derived from BView perhaps) which makes the use of SpriteWorld more transparent and BeOS like, so I don't think much is lost in that respect.
The biggest drawback I can see is performance. Putting in stub functions for things like SetGWorld() rather than removing the calls will add a little overhead. However, the way I see it, anyone using this for real performance is going to be tailoring the code to make performance modifications specific to their app anyway, so they can take care of this type of stuff then.