Haha.
- DYLIB support in CS: Not going to happen. Whereas a set of .a files would not need to provide complete linking, a mac build for dylibs would have a different link process to plugins and provide a single .dylib instead of multiple dlls. If dynamic object building ever worked, it would only work on platforms where the dynamic library is identical to the plugin bundle in construction. This is major work to change.
- On further analysis, libtool\'s insistence that it is unable to link .a ar files into a shared library or bundle are incorrect; the g++ linker in GCC3.1 in the toolchain provided by December tools from Apple are more than happy to provide linkable, workable tools. In order to enable this, where libtool normally gets built to build with a test, set it to pass_all; further details on this change will be documented in the build process and passed on to the fink developers for inclusion in the fink distro and passed up to the libtools developers for inclusion in 1.4.4.
- This means that planeshift now links, and builds .so files; however, these are of course incorrectly named, and need to be renamed .csplugin files; the build process needs to be changed to do this correctly; again, this requires further help from cs\'s config system.
- In order for ./psclient to pick up keyboard events, MacOS requires that the command be present inside of a .app wrapper; a directory file structure that tells the system it\'s an AppKit GUI application and prepares it with a windowed environment. Building this .app allowed it to work without any problems; however, for some reason, ps still seems to expect a $CRYSTAL directory. CrystalSpace itself has been modified to use the Mac/NeXTSTEP defaults mechanism for reading application-specific defaults information, and ps will need to be modified to use this. In addition, a shipping strategy for how to provide a drag-and-drop .app application which has the correct filesystem structure in that directory to ship the whole of the CS/CEL/PS system is needed. Once we come up with this, we\'ll have an application which you can drag to your desktop from a .dmg which will be a complete and runnable version of PS.
- Performance problems persist with CS. Initially, I tracked this down to a glDrawArrays() call seeming too expensive. Replacing instances of glDrawArrays() with glBegin()->glVertex()->glEnd() style calls does not improve the problem; however, it DOES make it clear that the problem appears to be with heavy calling of texture loading APIs; it seems we\'re not being efficient, in the old renderer, with texture reuse. This is, to say the least, difficult to track down; it may be some time.
- A bug in CS that causes problems on FreeBSD 5.0 and MacOS X, though we\'re not sure exactly why, makes it impossible to load a paletted PNG. This appears to be a problem with the alignment of the csRGBpixel structure, and the resulting array being a different length than is expected. Matt Reda provided a patch to me which proved it was an alignment problem; after much discussion in the CS dev channel with some of the developers, I provided a patch which causes libpng to load fully-qualified 24-bit files; it translates paletted files into full 8-bit RGB channels, and transforms paletted transparency into alpha channel.
So, where am I now?
- I have a basic .app which I can call from a commandline and, apparently, run the client and create a user up to the point of connecting to a server.
- The engine appears to work predictably and reliably, and CS seems happy.
Now I\'m afraid I\'ll need the assistance of a member of the audience for the final bit of magic - I need a server running TOT on an intel-based system with which to test the networking. I\'ll worry about running a local server last; as this isn\'t the intended use of shipping a client and will need more setup than a simple .app wrapper to deliver as a binary.
