FreeGameDev

Just wanted to inform that Syntensity builds and works fine on FreeBSD. Minor fixes to the build system were needed, and I'll submit the patch later.
I plan to do a proper port and add it to FreeBSD ports collection, but before that I have some questions:

1) The name - should it be synthensity or intensityengine? In first one is unsed in the web, and the second one in the VCS and sources, so I'm a bit confused.
2) How sensitive is it to the version on boost and v8? I'd like to use boost and v8 from separate ports, so I wonder if there was reason to bundle these with the engine and whether it'll work fine with other versions.

AMDmi3 {l Wrote}:Just wanted to inform that Syntensity builds and works fine on FreeBSD. Minor fixes to the build system were needed, and I'll submit the patch later.

Great, thanks!

I plan to do a proper port and add it to FreeBSD ports collection, but before that I have some questions:

1) The name - should it be synthensity or intensityengine? In first one is unsed in the web, and the second one in the VCS and sources, so I'm a bit confused.

Yeah, the names are a little confusing sometimes, sorry about that. In this case the name should be 'intensityengine', as that is the engine itself, which is what is compiled and run. 'Syntensity' is a website that uses the Intensity Engine, but others are free to use the Intensity Engine for other things entirely. In other words the Intensity Engine is the code, while Syntensity is a website that uses that code, runs its own servers, has a user account system, and also a specific licensing model (content you create in Syntensity is available for other people in Syntensity to play and modify - much like websites like icanhascheezburger - whereas the Intensity Engine has no such requirements, it only has a standard open source license).

tl;dr: The Intensity Engine is like StatusNet, while Syntensity is like identi.ca. Or the Intensity Engine is like WordPress, while Syntensity is like WordPress.com.

2) How sensitive is it to the version on boost and v8? I'd like to use boost and v8 from separate ports, so I wonder if there was reason to bundle these with the engine and whether it'll work fine with other versions.

Boost should not be sensitive at all. We tested 1.35 to 1.40, it all worked fine. The only reason it is bundled is because it was a hassle for Windows and OS X people to get and compile Boost (if only things were as easy there as on Linux and BSD ) Since we really only use some Boost headers and Boost.Python, it wasn't hard to just include it, so I did that.

V8 I am less sure of. I have upgraded V8 from their trunk a few times, and some times there were minor API changes. And they are not committed to a stable API. So, I would recommend just using the bundled V8, unless there is a problem with that.

- kripken

Got it, thanks for clarification.

Here's the patch: http://people.freebsd.org/~amdmi3/inten ... ebsd.patch - there are FreeBSD-related fixes and a fix for better out-of-source build support.
Actually, this can be done in a better way - the code you meant for Linux should work on many many *nix systems, so it should go into the ELSE branch, while IF's are for different platforms like win32 and darwin. This way you won't need separate checks for FreeBSD (and possibly other platforms in future) at all. I can update the patch if you like.

Also, I had trouble with compiling v8 on 64bit FreeBSD - were there any success stories with building an engine for 64bit platform or it's not supported yet and I should not bother?

Thanks for the patch! Can you perhaps check if the latest git compiles on your system, to see if I applied the patch correctly (I made some changes)?

People compiled and ran the engine on 64-bit Linux, and OS X as well. Although OS X required a new version of V8, which I upgraded git to yesterday. So hopefully V8 should now compile on 64-bit FreeBSD (if not, maybe let the V8 people know) and all the rest of the Intensity Engine should work as well.

- kripken

kripken {l Wrote}:Thanks for the patch! Can you perhaps check if the latest git compiles on your system, to see if I applied the patch correctly (I made some changes)?

v8 doesn't compile as some files are missing (at least src/fast-codegen.h)

kripken {l Wrote}:People compiled and ran the engine on 64-bit Linux, and OS X as well. Although OS X required a new version of V8, which I upgraded git to yesterday. So hopefully V8 should now compile on 64-bit FreeBSD (if not, maybe let the V8 people know) and all the rest of the Intensity Engine should work as well.

Ok, thanks. I guess I'll work with v8 guys.

PS. With V8 bleeding edge checked out manually from SVN, it builds fine, thanks (not tested the gameplay yet)! The only thing I've forgotten - it doesn't build with -Werror, so it should be disabled on FreeBSD or warnings fixed. Here's the full build log: http://people.freebsd.org/~amdmi3/intensityengine.log. Not sure about boost-python, but warnings in the engine seems to be easily fixable.

Whoops, looks like I didn't upgrade V8 properly - missed some files, as you said. Should be fixed now though.

I also fixed the engine warnings, but didn't touch Boost. So I disabled -Werror for now.

- kripken

Thanks, now it builds almost out-of-box, with only a single fix required for V8 (which I'll resolve with it's devs). Now another step is systemwide installation - I think I've managed to make it work, but I'm not sure it's fully correct.

It seems like Cube - based games don't support systemwide installation at all and tend to read/write files from/to current directory. In all ports of Cube-based games in FreeBSD, this is fixed by a wrapper script which creates hierarchy of symlinks to game data in the dotdir. I've made the same thing for intensity - there's wrapper script for client which replicates the directory tree, then creates symlinks to all files for

data/
src/python/
src/javascript/
packages/
intensity_client.py
mybrushes.cfg

this seems to be enough, but I'm worried about the fact that the game downloads the data from the net. Can it overwrite data files that were bundled with the game? Seems to me like yes, as I already have files like racing.js~ in ~/.intensityengine_client/packages/library/1_3/mapscripts - looks like racing.js was overwritten and racing.js~ is a backup copy. However, racing.js is a symlink to datadir which won't be writable by a user with real systemwide installation, and the game will fail to update the files in that case.

Any ideas on how to handle this in a correct way?
- not install data that could be downloaded anyway?
- make it rename ${file} ${file}~ before updating a ${file}, so symlinks to readonly data are handled correctly?
- maybe break the tradition and make it properly handle DATADIR and DOTDIR out of box?

PS. Another bug that comes from sauerbraten into its descendants - there's no 1920x1050 resolution, but there is 1920x1080. http://people.freebsd.org/~amdmi3/1920x1080.patch.

This should not be an issue for us. Files are only saved to ~/.intensityengine_client/. So even the wrapper should be unnecessary.

If something is saved elsewhere, that is a bug, please let me know and I will fix it. But AFAIK on Linux it is installed systemwide in some distro's packages with no problems.

- kripken

True. I've overlooked it, though I've should try it right in the beginning - the engine runs fine if started inside its datadir - chdir is the only thing that should be done in a wrapper script.

The port has been added into the FreeBSD Ports collection, thanks for your help!

Ok, great

I also added now a note in the README about systemwide installation, to clarify the issue.

Thanks! I've also seen you've added link to the port here: http://www.syntensity.com/toplevel/download/. It'd be better to use this link though: http://www.freshports.org/games/intensityengine, as it's more user-friendly and provides more info (including that link to CVS).

Updated the link, thanks.

- kripken