The CS::Threading::ThreadID problem should be addressed by commit r33845 in trunk (http://trac.crystalspace3d.org/trac/CS/changeset/33845). Unfortunately, this fix slipped through the cracks and has not yet been merged into the 1.4 branch, although I just added it to the list of patches which should be applied:

I merged fix r33845 into the 1.4 branch via r34876.

There also is a fix for CEGUI detection still pending: http://thread.gmane.org/gmane.comp.graphics.crystalspace.devel/3003/focus=3027. This is pending since I am waiting to hear if the patch actually works. (If you happen to test it, please report your results.)

Hi T00n3,

I did not see this thread since I do not check the forum very often anymore, however, kickvb pointed it out to me. Some people read the forum primarily, and some read only the mailing lists, so it can be difficult to know where to post. I usually follow only the mailing lists and the issue tracker. Also, there are several Mac OS X users subscribed to the crystal-main and crystal-develop mailing lists, so it might be useful posting there. At least one of those persons is actively extending CS (for GSoC), so he presumably has a working installation of CS on Snow Leopard. (He filed several of the bug reports mentioned below, which we have since fixed).

The CS::Threading::ThreadID problem should be addressed by commit r33845 in trunk (http://trac.crystalspace3d.org/trac/CS/changeset/33845). Unfortunately, this fix slipped through the cracks and has not yet been merged into the 1.4 branch, although I just added it to the list of patches which should be applied: http://trac.crystalspace3d.org/trac/CS/wiki/Version14Plan#Candidatesfor1.4.1

The -bundle issue has been raised several times (most recently in this thread http://thread.gmane.org/gmane.comp.graphics.crystalspace.devel/3003/). My understanding is that this flag merely needs to be dropped when building with Snow Leopard. In each case I suggested that we should automate detection of Snow Leopard and conditionally remove the -bundle flag, although there was never any follow-up to my inquiries. If you would like to work with me to resolve the issue, that would be ideal.

Setting MACOSX_DEPLOYMENT_TARGET probably should not be necessary since the project itself should still be deployable on older Mac OS X releases, so no need to restrict deployment only to Snow Leopard.

The NSOpenGLContext issue was the subject of ticket #810 (http://trac.crystalspace3d.org/trac/CS/ticket/810) and resolved in trunk by r33867 (http://trac.crystalspace3d.org/trac/CS/changeset/33867). The fix was merged into the 1.4 branch with r33868.

The size_t vs Uint32 compilation failure in driver_coreaudio.cpp was the subject of ticket #811 (http://trac.crystalspace3d.org/trac/CS/ticket/811) and resolved in trunk by r33872 (http://trac.crystalspace3d.org/trac/CS/changeset/33872). The fix was merged into the 1.4 branch with r33873.

Did you ever resolve the problem with vfs plugin not being found? Typically, this would occur if zlib was not installed or detected at CS configure time.

Regarding the build system, jam and make are equivalent in CS. They both invoke the same build commands, so there is no functional difference between the two. Whether you use "./configure; make; make install" or "./configure; jam; jam install" is a matter of personal preference.

Was the shaderweaver crash from 1.4 or pre-2.0 CS? Perhaps this problem also has been fixed in the trunk.

Generally speaking, unless there are constraints which force you to use the 1.4 release (or branch), I would recommend instead using the pre-2.0 (trunk) version directly from Subversion since it has advanced a lot from when 1.4 was released, and many bugs have been fixed in the trunk.

Perhaps this item might be helpful:

http://www.ittvis.com/services/techtip.asp?ttid=3092

Moved to Crystal Space bug tracker:
http://www.crystalspace3d.org/trac/CS/ticket/355

Posted to Crystal Space Trac as ticket 163:

http://trac.crystalspace3d.org/trac/CS/ticket/163

It would be a good idea to post as much information as possible, such as what version of CS you have, from where you downloaded it, how you unpacked it, etc. It also would be very helpful to show your exact command-line session so that we know precisely what you are typing and what error messages you receive.

P.S.: I'm not sure but I guess using the reference counting mechanism for self-written classes could be something more people are looking for. Maybe it's worth creating a FAQ or manual entry suggesting the usage of csutil/refcount.h?

The csRefCount utility class is mentioned in the "Correctly Using Smart Pointers" section of the CS manual (presently section 4.4.2) in the first paragraph.

http://www.crystalspace3d.org/docs/online/manual/cs_4.4.2.php#4.4.2

Curious. Very odd. The snapshot script (CS/bin/snapshot.py) just grabs the two copies of the repository for the respective dates and performs a normal 'diff' on them.

If you don't have root access, you can also set your LD_LIBRARY_PATH environment variable to point at /usr/local/lib.

That probably means that you didn't precisely follow the instructions in the article mentioned by dingobloo.

You already answered your own question. As long as your class provides IncRef() and DecRef() methods, you can use it with csRef<>. You will also need to add a variable to your class in which you store the actual count of references, and that variable will be manipulated by IncRef() and DecRef(). DecRef() is slightly special in that it also has the responsibility of destroying the object when the reference count falls to zero. If you don't want to code this up manually, you can inherit from csRefCount, which is a simple base in <csutil/refcount.h>, implementing this behavior on your behalf.

It looks like you forgot to link against the CS library, which is named 'crystalspace' in CS 0.99. If you're using CS 0.98, then you will instead link with csutil, csgeom, cstool, csgfx.

Which tutorial, exactly? Anyhow, if you don't have a configuration file, you can pass in NULL in place of the configuration file name.

This error occurs when your application is unable to find its own configuration file, which is AppTest.cfg, in this case. The actual cause could be any of several reasons, such as the fact that AppTest.cfg is not present in the appropriate VFS directory, or that the VFS plugin failed to load, or that VFS failed to find its vfs.cfg configuration file(s).