Cross-platform porting

#1 Nothing actually as long as you aren't doing anything particular to your platform, just make sure the project file is up to date reflecting any engine mods you have made, then recompile on the target platform.

The scripts are already crossplatform.

#2 Out of curiosity,
how are filepaths handled ?

ie forwardslashes vs backslashes vs colons ?

#3 In general it's been my experience to treat all file paths like URLs.

exec("./scripts/commands.cs");
   exec("./scripts/centerPrint.cs");
   exec("./scripts/game.cs");

#4 Roger.

what about on the C side ?

#5 Assuming that you don't use any platform specific functions above the layer, and you've followed the suggestions for using platform-guaranteed functions (I admit, this is a little nebulous, but there are actually "confirmed" versions of most, if not all, math functions that have been tested across all 3 major platforms), you actually don't have to make much, if any, code changes between platforms.

You just need to make sure that you properly build up your project for the target build environment, and get a clean make, then test your functionality.

All this is as Dreamer said 4 posts ago, just a bit more verbose!

#6 There are some pitfalls though :

compiled script files don't work out of the box when ported between platforms. So you'll need to copy the source files ( .DSO and .GUI ) and let the specific engine compile them.

You may also have troubles with the line endings ( CR LF ) of those files, so open them in a text editor and save them to change them.

There are some functions that weren't actually copied in the platform layer. I think "copyfile" is one of them.

Also take care about ENDIAN issues. My compass turns on one way in macs and the other way on PCs so I included an #ifdef compiler directive to handle that.

#7 About slashes: DOS and Windows has always accepted the regular Unix forward slash in path names at the API level, so you can use those freely in #include directives and in code. The backslash is only need by CMD.EXE (or COMMAND.COM) because those programs use the forward slash as a switch (option) indicator, a legacy inherited from DOS' CP/M roots. When coding, get used to only using slashes. The only exception I make to this is paths displayed to the user, because they don't know about this history. A big bonus of staying with forward slashes is that you don't have to double them as you would with backslashes.

If you use a revision control system, it may have an option to always check out files with platform-specific line endings. For Subversion, you just need to give all the text files the svn:eol-style property of "native". (See the Subversion docs for how to do that.) (Hint to GG: Since you're using Subversion internally, and you know which files are text, give us a script to set this property and any others (like mime-type) on all the files in the drops.)

#8 I'd second Kenneth's idea about eol-style native. Let me know if you have any questions on setting properties across the board!