[Echelon9]

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!

Code: [Select]

  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 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 complete solution 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.
• GLSL Shaders are still running in software rendering mode momentarily, before going to the correct hardware rending mode.
• It is a known bug that Apple incredibly forgot to implement array initializers in GLSL. 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 for memory management bugs.
• Valgrind's public releases currently does not fully support OS X 10.6, but there are a set of patches against trunk 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?

[portej05]

• 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 complete solution 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 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!

[blowfish]

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...

[Echelon9]

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

[chief1983]

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?

[taylor]

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.

[Echelon9]

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.

[chief1983]

Yeah the inline assembly is the only thing I've heard of recently blocking a native 64bit build on Windows.

[taylor]

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.

[portej05]

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;

[neoterran]

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 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).

 

[taylor]

_asm int 3;

Should be easily replaced by DebugBreak().  Is that the only line of ASM still active in the code?

[chief1983]

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.

[portej05]

_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
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
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.

[neoterran]

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 ! 

[Echelon9]

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.

[chief1983]

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

[Galemp]

I've been running FS2 Open on SnowLeopard for a few weeks now, and I'm glad to report that nothing's broken.

[blowfish]

Not sure, but AFAIK changing the SDK will probably break backwards compatibility.

[sanchox]

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
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!