Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: Echelon9 on September 01, 2009, 03:49:22 am
-
The most recent Mac OS X version was released last Friday, heralding Snow Leopard's improvements to 64bit, core performance and I'm pleased to say OpenGL as well!
OpenGL Vendor : NVIDIA Corporation
OpenGL Renderer : NVIDIA GeForce 9600M GT OpenGL Engine
OpenGL Version : 2.1 NVIDIA-1.6.10
As with any change like this, there will a number of teething issues while we sort out the FS2_Open codebase on this new platform. I'd like to keep track of these issues here, keeping other developers updated, and seeking others' suggestions.
If you'd like to develop on Snow Leopard please update to Xcode 3.2.6 and OS X 10.6.7 first.
GCC 4.2 support
- By default, Xcode 3.2.x uses GCC 4.2 as its compiler.
- Apple shipped versions of OpenAL.Framework in the 10.4 and 10.5 SDKs that are buggy with the version of GCC 4.2 shipped with Xcode 3.2.1, causing compile errors.
- Please update to Xcode 3.2.2 to fix the GCC 4.2 problems
- For the time being, I've made commit 5556 (http://svn.icculus.org/fs2open?view=rev&revision=5556) that should ensure we can still build on Xcode 3.2.1 (using GCC 4.0 by default).
- Also, the change to GCC 4.2 leads to numerous "deprecated conversion from string constant to 'char*'" warnings.
- The more (http://blog.wolffmyren.com/2008/05/02/g-warning-deprecated-conversion-from-string-constant-to-%E2%80%98char%E2%80%99/) complete (http://groups.google.com/group/comp.lang.c++/browse_thread/thread/43699362bd14b2a5?pli=1) solution (http://www.rhinocerus.net/forum/language-c/583728-deprecated-conversion-string-constant-char.html) to see the FS2_Open codebase comply with this new GCC 4.2 requirement will take some careful commits to ensure we don't break things cross platform.
OpenGL support
Environment mapping occasionally displays a patched, corrupted pattern (http://scp.indiegames.us/mantis/view.php?id=1858).GLSL Shaders are still running in software rendering mode (http://scp.indiegames.us/mantis/view.php?id=1881) momentarily, before going to the correct hardware rending mode.It is a known bug that Apple incredibly forgot to implement array initializers in GLSL (http://scp.indiegames.us/mantis/view.php?id=2084). A work around has been found and is included in the latest unified shader set.
64bit
- Full 64bit is not currently supported (nor on Windows
or Linux).
Valgrind 3.5.0 support for OS X 10.6
- Recently I've begun testing FS2_Open with Valgrind (http://valgrind.org/) for memory management bugs.
- Valgrind's public releases currently does not fully support OS X 10.6 (http://blog.mozilla.com/nnethercote/2009/09/02/valgrind-and-mac-os-10-6/), but there are a set of patches against trunk (http://code.google.com/p/data-race-test/wiki/ValgrindOnSnowLeopard) which will be in the next version of Valgrind that get it working on OS X 10.6.
Mac OS X 10.4 and PPC support (Comment sought)
- Now that OS X 10.6 is exclusively Intel, I believe it is time the community of Mac users had a debate over the future of support for legacy OS X 10.4 and the PPC architecture.
- Apple has discontinued support and upgrades to OS X 10.4 now that Snow Leopard (OS X 10.6) has been released.
- While 10.4 was released only in April 2005, I'd wager that Mac users upgrade more readily that Windows users of late.
- How many Mac Freespace 2 Open users would be inconvenienced if we dropped OS X 10.4 support?
- How many Mac Freespace 2 Open users would be inconvenienced if we dropped PPC architecture support?
-
- By default, Xcode 3.2 (the latest version of Apple's development IDE) uses GCC 4.2 as compiler. This changes leads to numerous "deprecated conversion from string constant to 'char*'" errors, plus a few others.
- The more (http://blog.wolffmyren.com/2008/05/02/g-warning-deprecated-conversion-from-string-constant-to-%E2%80%98char%E2%80%99/) complete (http://groups.google.com/group/comp.lang.c++/browse_thread/thread/43699362bd14b2a5?pli=1) solution (http://www.rhinocerus.net/forum/language-c/583728-deprecated-conversion-string-constant-char.html) to see the FS2_Open codebase comply with this new GCC 4.2 requirement will take some careful commits to ensure we don't break things cross platform.
- For the time being, I've made commit 5556 (http://svn.icculus.org/fs2open?view=rev&revision=5556) that should ensure we can still build on Xcode 3.2 (using GCC 4.0).
That one is known... chief forwarded a (massive) patch to me put together to fix this problem, however it was done against a trunk that was wayyy out of date (don't worry folks, we haven't forgotten!)
Top stuff E9!
-
So I got the chance to test Freespace on my install of Snow Leopard yesterday. Nothing seems broken, which is a good sign. Environmental mapping is still borked, but I guess that's to be expected. One other thing, Snow Leopard seems to make the transition to hardware rendering much faster than Leopard, yielding better performance with shaders. Still maybe not playable, but better...
-
Yep I noticed that too blowfish. Most clearly seen in the Techroom, where the ship model will start spinning smoothly much sooner.
Not playable in mission though with -normal :(
-
Also, those deprecated conversions shouldn't be errors, but just warnings I thought. They happen on linux as well. Is dropping the GCC necessary to finish a compile or does it just produce less warnings that way?
-
They are just warnings and don't affect actual building. I would recommend just disabling the warning rather than actually trying to fix it all. Then fixes can be done slowly over time in order for them to be done properly rather than hastily trying to get rid of the warnings. Some of them are easy fixes, but quite a few get rather complicated and require some light rewrites for a proper fix (I know, I've done it before).
And regarding 64-bit support, it has been 100% supported under Linux for a few years now. As far as I know Win64 works as well (I made changes for it) but I have never heard whether it builds/runs properly. 64-bit OS X support, I believe, is pretty much identical to 64-bit Linux support, so I wouldn't think that many (if any) code changes would really be needed. I could be wrong about that though, since I really haven't checked the docs with regards to proper handling of OS X 64-bit.
-
And regarding 64-bit support, it has been 100% supported under Linux for a few years now. As far as I know Win64 works as well (I made changes for it) but I have never heard whether it builds/runs properly.
I haven't done any win32 development for a while, but portej05 said recently that FS2_Open doesn't compile as 64bit on Windows (due to some inline ASM AFAIK). I just went off that.
-
Yeah the inline assembly is the only thing I've heard of recently blocking a native 64bit build on Windows.
-
I thought that the rest of the ASM had already been ripped out. It may have been something that I did but never committed before toasting my trees though.
-
I thought that the rest of the ASM had already been ripped out. It may have been something that I did but never committed before toasting my trees though.
_asm int 3;
:P
-
I just upgraded to snow leopard by doing a fresh install. And i'm a ruby developer, so it was an extreme annoyance reinstalling macports, postgresql, mysql, all my rubygems, and all my apps and stuff from my previous leopard hard drive (I really needed a fresh start after 2 years on leopard).
But holy crap it's fast. I'm running the 64 bit kernel on a 2008 macbook pro and it really screams, everything just feels alot more responsive. Of course, I did upgrade my hard drive at the same time, so.....
As for Freespace, I would not be inconvenienced by you dropping support for 10.4 or PPC. And I would urge my mac friends who still haven't made the leap to a 64 bit intel platform and a modern version of OS X (10.6) to do so without hesitation. I installed rosetta, so I can still make use of those straggling but necessary apps... (Ultima V Lazarus/Dungeon Siege, I'm talking to you).
:D
-
_asm int 3;
Should be easily replaced by DebugBreak(). Is that the only line of ASM still active in the code?
-
Hey, my copy of the OS X build script runs on a G4. And there are still plenty of G4/G5 macs out there more than capable of running FSO. I wouldn't kill that support just yet, even if Apple is.
-
_asm int 3;
Should be easily replaced by DebugBreak(). Is that the only line of ASM still active in the code?
Depends which build you're doing :P
Without PDB_DEBUGGING, you get all the COFF asm stuff, so any x64 builds need to be done with VS2005 or later (those are the supported platforms for PDB_DEBUGGING)
Also, I'm not 100% sure that we never cast a pointer to an integer :P
There's also the issue of sign extensions - if someone has used 0xFFFFFFFF for -1 instead of (size_t)-1 on a type that can be 64bits, we'll need to do a bit of work.
FRED probably commits the sin of casting to DWORD instead of DWORD_PTR in some of the MFC stuff (e.g. SetItemData), but I don't think that's too important (will anyone really want a 64bit FRED build?).
Other than those thoughts, I don't think there's much in the way.
-
Hey I just wanted to thank you guys for the continued development. I still play freespace from time to time; it's a bit like a nostalgia thing or something, and it's really nice to now be able to play it looking pretty good (with AA even) on my work laptop.
Thanks and keep it going ! ;)
-
No problem! It's always encouraging to hear gratitude.
Many of the recent graphics improvements are being pushed by the exciting upcoming releases which will use the FS2_Open engine, but of course the benefits can be seen now by everyone using the nightly builds and MediaVP Freespace 2 data.
-
Was thinking about making a new topic and then realized it was going to pretty much cover what's in this one. Seems I was the only one who cared about PPC support, and I have an Intel Macbook Pro through work now. So I guess we should probably go straight Intel, or even if we still make universal binarys we need to start taking advantage of newer compiler options. The project is still in 2.4 compatible format, we could at least bump this to 3.0 I think. Even on my PPC G4 I'm using Xcode 3.x. It's also using the 10.4 SDK, but the target OS is a different var, also 10.4. Bumping the SDK to 10.6 won't make code incompatible with 10.4 will it? Although I wouldn't mind dropping 10.4 support either, almost anyone left probably has at least a G5 running Leopard.
Also, could we turn on SSE3/4 optimizations? Any Intel can handle at least SSE3, and it seems to be really helping the Windows builds. It can probably be done so it doesn't break PPC you think?
edited for clarity
-
I've been running FS2 Open on SnowLeopard for a few weeks now, and I'm glad to report that nothing's broken.
-
Not sure, but AFAIK changing the SDK will probably break backwards compatibility.
-
I personally would be affected by the proposed dropping of ppc support, as i have reported an outstanding bug that makes freespace unplayable in 10.5.8 on a ppc g5: http://www.hard-light.net/forums/index.php?topic=65944.0 (http://www.hard-light.net/forums/index.php?topic=65944.0)
while this is a problem for me, i do realize that PPC support should eventually go the way of the dinosaurs... i have seen it happening across the board in the mac app scene. a quick glance at emulation related projects on the mac shows a tendency toward creating a final *stable* build for the ppc architecture and then dropping future support. i totally support this path, as my g5 is a tad long in the tooth.
so, my vote is for locking down a stable and fully playable ppc build and then turning 100% of the developmental energy toward the x86 architecture/10.6+
thanks for all your hard work!
-
Updated to reflect initial testing results of the Valgrind 10.6 patch (https://bugs.kde.org/show_bug.cgi?id=205241).
-
Updated to reflect GCC 4.2 is now compatible with Xcode 3.2.1 in certain configurations.
-
- By default, Xcode 3.2 (the latest version of Apple's development IDE) uses GCC 4.2 as compiler. This changes leads to numerous "deprecated conversion from string constant to 'char*'" errors, plus a few others.
- The more (http://blog.wolffmyren.com/2008/05/02/g-warning-deprecated-conversion-from-string-constant-to-%E2%80%98char%E2%80%99/) complete (http://groups.google.com/group/comp.lang.c++/browse_thread/thread/43699362bd14b2a5?pli=1) solution (http://www.rhinocerus.net/forum/language-c/583728-deprecated-conversion-string-constant-char.html) to see the FS2_Open codebase comply with this new GCC 4.2 requirement will take some careful commits to ensure we don't break things cross platform.
That one is known... chief forwarded a (massive) patch to me put together to fix this problem, however it was done against a trunk that was wayyy out of date (don't worry folks, we haven't forgotten!)
Do you still have a copy of this patch portej05/chief1983? I'd like to work on it as free time arises.
-
Updated to reflect the current state of OpenGL on Mac OS X with the new unified shader code.
-
Big update to reflect the fixes with Xcode 3.2.2 and OS X 10.6.3, and that trunk versions of valgrind now build on Snow Leopard.
-
GLSL seems to be working with no slowdowns, but there is one strange thing I've found...
In GLSL mode, ships don't disappear as they pass through the subspace vortex warping out :wtf:
-
GLSL seems to be working with no slowdowns, but there is one strange thing I've found...
In GLSL mode, ships don't disappear as they pass through the subspace vortex warping out :wtf:
Yes, Mac OS X 10.6.3 has seen big improvements in OpenGL performance from my testing too.
A couple of issues still remain though:
- Environment mapping occasionally displays a patched, corrupted pattern (http://scp.indiegames.us/mantis/view.php?id=1858).
- The issue with GLSL float array constructors (http://openradar.appspot.com/6121615) remains (but we have a workaround in the unified shaders).
- Ships don't disappear as they pass through the subspace vortex warping out (may not be Mac specific)
-
Blowfish, I think that's been a bug on all platforms, not just OS X. But it's good to hear that GLSL performance has been substantially improved. In fact that's great f***ing news.
-
Blowfish, I think that's been a bug on all platforms, not just OS X.
Okay, that's good to hear ... I just assumed that it was probably mac-specific because I hadn't ever heard it mentioned...
-
1866 (http://scp.indiegames.us/mantis/view.php?id=1866) Pretty sure there have been reports of this on Windows, even if not 100% of the time. May be chipset related?
-
Oh I'm so psyched. It was pretty much unplayable for me with GLSL for almost 2 years, so thank god we finally got some love.
Looks real good, and framerate rocks.
-
Probably need to clean up some Mantis issues. And maybe need to tweak the project file. Are we going to need multiple setups now? One for Xcode on 10.5 and one for Xcode on 10.6, so we can take advantage of all the stuff in Xcode 3.2.2 that works now?
-
I haven't been able to compile under the 10.6 SDK, so I think it's just 10.5 for now.
Also one thing I should probably mention - the ogg framework is out of date. I belive Goober updated the windows library for the DEM Interlude release, but Mac builds use a different framework, which crashes when trying to open a cutscene in that campaign.
-
I believe I remember this being brought up already. Be nice to get it patched into the Frameworks file, otherwise we could just wait until the unified one we're planning for Windows/OSX.
-
Probably need to clean up some Mantis issues. And maybe need to tweak the project file. Are we going to need multiple setups now? One for Xcode on 10.5 and one for Xcode on 10.6, so we can take advantage of all the stuff in Xcode 3.2.2 that works now?
I've been examining the merits of having two separate Xcode project files for a little while; one the current and one that employs the latest and greatest (as Visual Studio project files have done for VS2005, 2008 and 2010). You may not realise, but the current Xcode project file is still in an old 2.x format.
I'd want to make sure there are real differentiators between the two that could be unleashed, so a bit more testing is needed. But watch this space...
-
No, I definitely realized that Echelon :)
Would love to have a dedicated 3.2.2+ project file, and one we could just use on 10.5 and 3.1.x. Although I'm not sure how maintained the latter would stay. I know I can't.
-
I've compiled and have been running for a while now a 64 bit/10.6 version of FS2 (version 3.6.11). If anyone would like to try it, I've uploaded a copy here; http://www.mediafire.com/file/imc3gmh4nyj/FS2 3.6.11 x86_64.zip (http://www.mediafire.com/file/imc3gmh4nyj/FS2 3.6.11 x86_64.zip)
-
Wow ... my understanding was that 64 bit would not compile on any platform ... how did you get it to work?
-
I only had to modify for deprecation, change a couple of lines for 64-bitness, and compile. Quite simple. It consumed about 10 minutes of time.
-
More interesting to me is, which trunk revision is this? Can you upload a .patch or diff of your changes?
-
Supposedly Taylor had 64bit building working on Linux for quite some time as well, I think. So OS X probably didn't need much else. Windows though is another story I think.
-
Yep, just tried it today. There are a bunch of conversion warnings, and at least one instance where no conversion is possible (ADDRESS64 vs DWORD64)
-
The conversion warnings are on 32bit too, if you're using the newer GCC with more warnings by default.
-
I've recompiled with a new svn checkout. It compiled without complaint, needing no more than a fixed .xcodeproject & the correct libs (No deprecation errors!). I've zipped the Xcode directory http://www.mediafire.com/file/3lmzwmz5yo0/Xcode.zip (http://www.mediafire.com/file/3lmzwmz5yo0/Xcode.zip), if anyone wants it. I'm using '/trunk/fs2_open' (Assuming that's the correct one.)
-
Revision 6076.
-
Could you provide a diff file? Just cd to the FS2 SVN root directory in the terminal and then type
svn diff > output.diff
(output.diff can be replaced with anything :D)
-
I already diff'd the xcode project...it's really different. He's added two configurations for one, not just made existing ones 64bit.
-
As I only had the libs compiled 64 bit for 10.6 (as opposed to 10.5), I added two extra configs ('Release x86_64' & 'Inferno Release x86_64') along with one new target ('FS2_Open x86_64'), as I didn't know how to make Xcode link with different libs for various configurations.
-
I'm not aware as to whether building/linking 10.6 has any advantages over 10.5, but if someone could build Ogg, Vorbis, Theora, & SDL PPC/i386/x86_64 on 10.5, the .xcodeproject could be greatly simplified compared to what I did.
-
[First post updated to reflect resolution of all remaining substantive issues with Xcode 3. Work has commenced on transition to Xcode 4 (released during March 2011).
-
I wouldn't plan on updating anything in SVN to Xcode 4 any time soon. I certainly don't know if I'm going to be paying for a Mac IDE any time soon. If anything else, I guess having two projects would be ok, if Xcode 4 projects aren't compatible with Xcode 3.
-
I wouldn't plan on updating anything in SVN to Xcode 4 any time soon. I certainly don't know if I'm going to be paying for a Mac IDE any time soon. If anything else, I guess having two projects would be ok, if Xcode 4 projects aren't compatible with Xcode 3.
Yes, there will be an Xcode 3 project file option for a while to come.