The thread that was up until recently called the Seanachai is Challenged OS X thread

[aka_tom_w]

Port to Mac OS X information

gamasutra how to Port to Mac OS X

Porting Games to Mac OS X

With the release of Mac OS X, the Macintosh platform gains a new path to easy-to-use and high-performance gaming. This article will address how you can easily port your current game over to the Mac and the APIs in Mac OS X that you can use to do so. Many of the issues involved with porting to a new operating system are common to porting to any new OS, not just the Mac.

snip

Finally, moving your code to another platform can help uncover many latent bugs in your code. In this case, the extra effort involved in supporting multiple platforms can actually reduce the amount of work at the tail end of a project by ensuring that the base you are building your game on is as stable as possible.

Planning Your Game

As with any complicated task, large gains in productivity can be had if you plan your effort before embarking on it. The first step in planning a project is deciding where you want to end up after all your effort has been expended. This applies to both the features you want in your game and the platforms on which it will run. The earlier you decide on your supported platforms, the easier it will be to achieve your goals.

The decision of which features your game will include is related to the platforms you will support. For example, if you are planning on supporting wireless gaming, you probably won't be using Open GL for at least a couple of years (beyond that, who knows?). Likewise, if you are going to write games that are going to run on the Mac, you need to pick foundation technologies that are available there. This excludes proprietary technologies like DirectThis and DirectThat (and Mac proprietary technologies such as Core Graphics, Cocoa, Carbon, and so on if you are going to run on Windows).

There are many well-known software techniques for multi-platform development. I'll assume you are familiar with these for the purpose of this article, and I'll focus exclusively on Mac OS X-specific techniques. Some of the arrows in your quiver for multi-platform development should include separating code using ifdefs based on the platform, using custom data types to steer clear of standard type system dependencies, avoiding depending on bitfield order, steering clear of compiler- and linker-specific behaviors, and of course using a good source code control system and open APIs.

Porting Games to Mac OS X

Mac OS X Technology

Mac OS X has two primary high-level toolboxes, Cocoa and Carbon. Mac OS X also has two object file formats, Mach-O and CFM. There are some choices to be considered when choosing between these. In this article, I'll be talking about the Cocoa/Mach-O approach. This choice is primarily due to the fact that fewer lines of code are necessary to accomplish similar functionality in Cocoa, and Cocoa requires Mach-O.

Cocoa is Apple's advanced object-oriented application toolkit, which is based on the technology it acquired from Next. Carbon is a distillation of the classic Mac OS toolbox APIs that removes a bunch of the less commonly used functions which were not easily implemented in the new world. This includes removing things such as direct access to the hardware, completely obsolete APIs, and so on. The remaining APIs have been modified to work in terms of the new underlying OS. So, a Carbon application can run on both OS 9 and OS X (as long as it doesn't make use of any new OS X services).

The foundation of Mac OS X is the Mach kernel. Mach provides the hardware abstraction and lowest-level OS services. This includes interprocess communication, protected virtual memory, threads, symmetric multi-processing, and driver services. The BSD/POSIX layer sits on top of Mach (so a BSD process is really a Mach task with a little extra goo, and a POSIX thread is really a Mach thread with some of its own goo). All of the API sets are accessible from a user program written using Carbon or Cocoa, but the vast majority of users will be able simply to use the high-level APIs or maybe occasionally use the intermediate BSD APIs. Only in special cases is it necessary to access the Mach API directly, so most of the time Mach sits in the background, providing a rock-solid OS infrastructure. As an example, Mach provides an API for pausing a thread, getting or setting its registers, and then allowing it to continue. Programs don't need to typically do this, but if you were writing a debugger, this would be very important.

Screenshot from Quake 3: Arena.

Platform-Specific APIs

There are a few platform-specific APIs that most games depend on. These are APIs for performing the following tasks:

System functions (file and network access, memory management, threading, code loading and unloading)

Display management

3D graphics rendering

Music and sound effect playback

Reading input devices.

I'll address each of these functional groups in turn.

System functions

Mac OS X has a BSD 4.4 API layer as part of its Mach-based kernel. Apple has stated that their goal is to be POSIX-compliant. This means that a large portion of the platform-specific APIs can be addressed via both BSD and POSIX APIs.

The Windows stdio interface is very similar to the BSD functionality from which it was copied (except for Windows' strange notion of binary versus text files). The stdio API can be used for all file I/O, with the option of accessing the Mach API for memory-mapping files.

Likewise, the BSD sockets API served as the template for the Windows version. There are some minor differences here (select() versus WaitForSingleEvent() and the list of supported socket options), but nothing terribly surprising.

Unlike on many systems, the standard memory allocation package on Mac OS X performs very well. Still, for portability with other platforms you may choose simply to use malloc to allocate large chunks of memory for your internal memory allocator.

For threading, Mac OS X uses the POSIX threading library (pthreads). The implementation of this library isn't 100 percent complete, but the items which aren't implemented are more esoteric. If your game uses threads at all, you likely only want to create threads, mutexes, and conditions -- this portion of the API works fine. If you do want to do anything more interesting, there is the option to use the underlying Mach thread APIs (each pthread corresponds to a Mach thread).

Mac OS X uses a dynamic linker called "dyld," which handles both launch-time linking of shared libraries and run-time linking of code modules. While it is possible to call dyld directly for your code-loading needs, it is probably easier to use the "dl" API defined in Linux, Solaris, and other Unix platforms. A wrapper for dyld that provides the dl interface can be found as part of the open source Darwin kernel that resides underneath Mac OS X (see For More Information).

The input to the dl wrapper API should be a Mach-O "bundle" file (as opposed to a dynamic library, or "dylib"). Using Project Builder, the IDE that ships with Mac OS X, or whichever IDE you prefer (Codewarrior, for example), you can easily build a bundle file. Bundles are typically file wrappers, which simply means that they are directories that contain a variety of resources, one of which is code to be loaded. The path to this code is what should be passed to the dl API functions.

It is also possible to load CFM libraries into Mach-O processes using the Carbon Code Fragment Manager APIs. You might choose to do this if you want to use a toolkit that is only available in CFM format for the Mac (for example, the Bink video library).

[aka_tom_w]

I have posted WHOLE chuncks of text here, because you need a log in and password to read those pages on gamasutra (its free but its a bother.)

How to Port to OS X

web page gamasutra

Porting Games to Mac OS X

Power PC Specifics

The code snippets in the example programs are sufficient to build a game that runs on the Mac, but in order to make a game that runs as well as possible, there are a few Power PC-specific issues that you may need to address, depending upon the architecture of your game.

Pitfalls

The Macintosh does not have the memory bandwidth that Intel boxes have. This is less true on the newer machines, but if you are targeting older iMacs, you will need to be aware of this. There are things that you can do to help avoid this problem. First, stay away from back-to-back load and store operations. Instead, load several values, operate on them, and then store them. The Power PC chip has a huge register file compared to Pentiums. You can avoid a lot of memory operations simply by putting more values in registers. The Power PC also provides a set of cache control instructions that allow you to preload cache lines, flush them, or zero out entire cache lines (much faster than doing it yourself, since you avoid the read to load the cache line).

Converting between floating-point and integer formats is expensive on the Power PC. There are two reasons for this. First, since the Power PC is RISC, the floating-point and integer units are only connected via memory through the load and store unit. Additionally, the Power PC (prior to the G4 Altivec instruction set) does not have architecture-level support for converting from integers to floats. Casting between float and integer is never free on any architecture, but it is definitely more expensive on the Power PC. You can often get large performance increases by eliminating needless casting back and forth between int and float.

If your game engine is in C++, you will not be able to mix Objective-C code snippets as listed into the same files as your core C++ code. This isn't a huge problem, since all the platform-specific code should be isolated in its own files anyway. Currently, the simplest way to call between C++ and Objective-C is to use a vanilla C interface. If you design your platform support library interface in pure C, you won't even notice this problem. Apple is devoting engineering resources to this issue, however, and was scheduled to report on their progress at the 2001 Apple Worldwide Developers Conference in May.

Optimizations

The Power PC has a few instructions that deserve to be pointed out for possible optimizations.

If your engine uses the square root math library function, you might be able to use the frsqrte instruction. This instruction computes an estimate of the inverse of the square root. Depending upon your precision needs, you can use multiple Newton-Raphson refinement steps to extend the precision of the result. The frsqrte instruction can in practice be up to 16 times faster than 1.0 / sqrt(x). In addition to using this instruction for the reciprocal square root, you can also use it to compute a normal square root by simply multiplying its result by the original value, since x / sqrt(x) = sqrt(x).

The Power PC provides an fsel instruction for performing simple if/else assignments. This can eliminate branches in inner loops, which not only reduces the total number of instructions issued, but also frees up branch prediction slots and eliminates the possibility of an incorrectly predicted branch.

Another interesting group of instructions is the lwbrx family (load word byte reversed indexed). This family of instructions allows you to load or store two- and four-byte values and also perform endian swapping. This is much faster than loading the value and then performing bitwise operations in order to swap the value around manually.

Performance-Monitoring Tools

Mac OS X ships with a full set of developer tools. Included in this are several performance monitoring tools. The Sampler application (and the "sampler" command line tool) will periodically stop all the threads in your application, record their stacks, and then let them continue. This provides you with a tree of wall clock time spent, easily allowing you to find the portions of your program that are using the most time. You can also invert the tree, putting the leaves at the root, allowing you to find small leaf routines that are taking a large amount of time.

Omni also provides the OmniTimer framework (see For More Information). This allows you to insert instrumentation calls into your application at key points (typically determined by running Sampler) in order to get very high precision timings. OmniTimer uses the Power PC TBR (time base register) in order to minimize the overhead of collecting the timestamps.

Advanced topics

The Power PC G4 ships with what is considered by many to be the best SIMD instruction set in a consumer CPU. With the right type of task, Altivec can provide huge performance gains. It is also possible to store floating-point (X, Y, Z, W) vector data in single Altivec registers and operate on those registers using macros or inline functions. Care must be taken to keep the values in the vector registers to yield performance gains. The jury is still out on the feasibility of this approach, but it is worth considering.

Mac OS X provides full symmetric multi-processing. If you have the right sort of tasks (that is, very few synchronization points and low data flow), you can break them up into separate threads and Mac OS X will automatically schedule them to different CPUs (if available).

Mac Attack

In the past couple of years, Apple has increased its focus on gaming, and it shows. The Macintosh is now a great gaming platform and only looks to improve in the coming years. By porting to the Mac you can experience increased portability and robustness for all platforms.

Even better, by adding the Mac enthusiasts to your customer base, you can increase your revenue stream while continuing to produce excellent games.

[aka_tom_w]

another opinion:

web page blog and a good one

Programming games for OS-X is difficult. You need to take into account endian issues (for the old processors), operating system issues, support for a bunch of screen resolutions, the fact that many of the computers have only one mouse button, OpenGL vs. Direct-X issues, etc. Using a cross platform game engine such as Torque Game Engine or Torque Game Builder, there are still issues, mainly due to the single mouse button. Beyond that issue, probably the largest problem that any game on the Mac faces is the Mac UI snobbery that all Mac users seem to have. Even though there are few games on the OS-X platform, if a Mac user even sniffs of a “port” they will complain.

Apple has purposely disdained games. Games are not considered a “real” use of computers, while graphics, music, and videos are true art. Talking to pro gamers inside in the company, they are frustrated with Apple’s commitment to games.

On the opposite end of the spectrum Microsoft totally “gets” games. They realize that games are a driver of hardware sales and one of the biggest uses of computers in the home. Bill Gates announcing his retirement last month was bittersweet for me. In the early days, I was a total Microsoft groupie, rooting for them in their big fight against Apple on UI issues, then I was a Microsoft opponent at the height of their monopoly power a few years ago, now I’m back in the MS camp as their gaming vision is paying off for so many companies. Regardless of what you thought of MS through the years, they have been the glue that has allowed games to even exist on the PC. From the earliest days of Microsoft producing games like Olympic Decathlon and Flight Simulator to the days of Direct-X to shipping XBox consoles, Bill Gates has understood that games drive hardware sales. For that I have to thank him. It will feel strange to not have Bill Gates in the industry.

So, back to the question of whether or not to make games for OS-X. You can make some money there since the market is fairly game starved. If you use a cross platform game engine, and your additional costs are not too high, the ROI is worth it. However, in the future, I am not so sure. Since all Macs are now Intel based, your users can all use Boot Camp to play PC games on their OS-X machines. Of course, you won’t get the Cocoa UI snobs, but anybody else that wants to play games will be able to take advantage of all that Bill Gates has done for gamers over the years.

Apple could change this. Since they control all of the hardware, they could easily add in controller support. Standardized controllers annointed by Apple would quickly become ubiquitous and cheap. Apple could make sure their computers ship with better graphics hardware than the built in GPU of the recent Mac Mini, so developers are assured of a minimum graphics standard that will not go down. Apple has wonderful design and awesome software engineers. They could easily add game download support into iTunes. What is more important, games or podcasts? I love podcasts, but the answer to the question is obvious.

Come on Apple, make me a believer again.

-Jeff Tunnell, Game Maker ::: Make It Big In Games ::: GarageGames

[aka_tom_w]

Current news Feb 15 2007 on the state of mac Gaming:

Apple still quiet on game strategy @ Cnet news.com

Some believe Apple might have some enhancements planned for Leopard, the next version of Mac OS X that's scheduled to arrive this spring. Last year at Apple's Worldwide Developer's Conference, Steve Jobs demonstrated some graphics-friendly technology such as Core Animation, which will make it easier for developers to create high-powered graphics. It's also possible that Jobs has other surprises in mind for this year's show, scheduled for June.

One development that has given Mac developers a rosier outlook is the switch to Intel's processors. Unfortunately, developers still have to do a lot of work porting games over to Mac OS X because most games are created as universal applications, ensuring they can also run on older Macs with PowerPC chips. But going forward, developers are encouraged by the relative ease of creating Intel-only Mac OS X applications, and the switch also ensures that there are a lot more machines out in the market with a defined level of performance, Morrison said.

The switch to Intel has also paved the way for Apple to release Boot Camp, a piece of software that lets Intel-based Macs run Windows. Boot Camp will be included along with Leopard, allowing those who want to keep their Macs but have a hankering for the latest and greatest video games to run Windows games the day they are released. Virtualization technology from companies like Parallels might make this even easier in the future.

When Boot Camp was first released, Destineer Studios was a little worried that Mac users would eventually stop buying Mac versions of games and just run the Windows versions, said Al Schilling, general manager of Destineer's MacSoft label, which ports games to Mac OS X. But Mac game software does not appear to have been affected by Boot Camp, and Schilling doesn't believe that will change with the release of Leopard.

Programs like Boot Camp and Apple's quiet approach to Mac gaming seems to indicate that the company has made a decision to let the Windows companies pursue the hard-core gamer, said Stephen Baker, an analyst with The NPD Group.

The Windows-based world loves gamers, especially those who spend thousands of dollars on new PCs and related equipment in hopes of having the best score on the block. Smaller PC makers like Falcon Northwest and Velocity Micro cater almost exclusively to this group, but the big guys want in on the action, too. Last year, Dell bought Alienware and Hewlett-Packard bought Voodoo PC in hopes of capturing more of these customers and learning how to reach that profitable segment.

[aka_tom_w]

Has anyone looked at "Cider" yet?

Cider's web page

TransGaming's brand new Mac portability engine, Cider, gets Apple users to the core of gaming.

No longer will Mac users be forced to wait months or years for the few top tier titles to get into their hands. With Cider, video game developers and publishers will finally have access to the rapidly growing Mac market, quickly, easily, without the costly price tag of traditional, arduous porting. Thanks to Cider, video game developers and publishers can extend their content to the Intel Macs quickly, cost-effectively, and with little to no effort on their part.

Stemming from the same technology foundation as TransGaming’s technical sensation, Cedega, Cider empowers game developers and publishers to release Mac editions of their titles. Cider is so effective that publishers will be able to simultaneously deploy the Mac and Windows versions of their titles, even for new games already in development. With Cider, whole catalogues of games can be easily brought to a brand new audience starving for games. Another great benefit is that games migrated to Intel Mac using Cider will also run on Linux under Cedega, forging a path to another game hungry market.

How Cider Works

Cider Screenshot

Cider is a sophisticated portability engine that allows Windows games to be run on Intel Macs without any modifications to the original game source code. Cider works by directly loading a Windows program into memory on an Intel-Mac and linking it to an optimized version of the Win32 APIs. Games are simply wrapped up in the Cider engine and they work on the Mac. This means developers only have one code base to maintain while keeping the ability to target multiple platforms. Cider powered games use the same copy protection, lobbies, game matching and connectivity as the original. All this means less work and lower costs. Cider is targeted at game developers and publishers and, unlike Cedega, is not an end user product.

The Intel-Mac Explosion

Cider Screenshot

Why should developers and publishers consider the Mac market? In the last quarter alone, Apple shipped almost a million Intel Macs, outpacing iPod sales for the first time in 2 years. Ben Reitzes for UBS Investment Research expects Apple to sell over 1.3 million Macs next quarter and between 5.1 and 6.7 million units over the 2006-2007 fiscal year. A poll of Mac purchasers conducted by Apple shows that nearly 50% of buyers are “new to Mac”. This means more and more Windows users are switching to Mac. Furthermore, analyst Charles Wolfe of Needham & Company expects Apple to triple its share of the home computer market. With only a small collection of games available, the Mac gaming market is a void waiting to be filled.

To get your games available to Mac users today contact TransGaming at: cider@transgaming.com

web page Cider FAQ

Cider is TransGaming's answer to the lack of Mac gaming. Based on the same core technology found in TransGaming's flagship Linux product Cedega, Cider is able to run Windows games on the Intel Mac OS.

2) How does Cider work?

Cider works by directly loading a Windows program into memory on an Intel Mac system and linking it to an optimized version of the Win32 APIs. TransGaming's Cider implements common multimedia Windows APIs such as Direct3D, DirectInput, DirectSound and many others by mapping them to Mac equivalents. This allows games to run with equivalent game play and performance but without the typical brute force porting effort typically required to bring games to Mac.

3) Who is Cider for?

Cider has been created for use by game developers and publishers to release Mac versions of their products. By integrating their games with Cider, developers and publishers will be able to easily provide a Mac version of their game in conjunction with the Windows release. Cider is a business to business application is not available to end-users.

4) How long will it take to get my game to market?

Since Cider encapsulates the original source code to make it work on the Mac, your game will be ready for market in record time. TransGaming works with the game developers and publishers to optimize the game for Intel Mac but this process takes hours to a mere few days. Thus, games currently in production can be ready in time for a simultaneous release as the Windows versions. Cider can also be used to revitalize already released games by offering them to a brand new market, quickly and easily.

[ February 18, 2007, 06:48 AM: Message edited by: aka_tom_w ]

[grunt_GI]

Just my two cents..echoing other folks, the days of the Power PC mac are numbered whether anyone wants to acknowledge it or not. I made the move to Intel machines and hated to abandon all the OS9 games I played on my G4 powerbook, but took the plunge knowing the Intel machines were the new commers. I am glad I made the decisions, even though I had to (happily) buy a copy of the Windows CMBB and CMAK to play under Bootcamp. I hope Steve will let us know how CMSF plays under Bootcamp, because I REALLY want to try it out, and will buy it whether I have to play it under Bootcamp or an OS X Intel native version.

BTW, Aspyr has already made the decision that their new Star Wars game will be Intell only, so it is really only a matter of time before the PowerPC is no longer really supported.

My biggest worry is (sighhhh) will CMSF play (at all, even minimum eye candy) on the MACBOOK with the Intel GMA chipset?

[jeffsmith]

OK another $0.02

BFC has a single coder

they are in most likelyhood NOT about to invest in anyone elses software solutions

and they are going to do things the way they see is Best for them and their customers

They know our wishes Re Mac porting

and have responded very warmly and openly

BFC's track record for working with their customer base is simply unequaled

So...

Posting alternate software solutions and reports and statistics about Mac trends while helpful info

Probably is not going to sway their decision process in any appreciable way

[gibsonm]

Well for what its worth, please count me as a vote for a Universal Binary version.

I have a MacBook Pro (Intel) which I’d love to run CMSF on.

I have a G5 (10.4.8 Server) which I’d love to run CMSF on.

I have a 1GHz G4 PowerBook that I run CMBO, CMBB and CMAK on as it boots into OS 9 (or OS X).

I have a 867MHz G4 “Mirror Door” desktop that I run CMBO, CMBB and CMAK on as it boots into OS 9 (or OS X).

I’m not too worried that the last two wont run CMSF - suspect it would be very slow if it did, plus no doubt there would be issues with the graphics cards.

And I have a Windoze junk box (XP Pro SP2 - not touching Vista) which has CMBO, CMBB, CMAK and a swag of other Windows only simulations / games installed on.

I don’t really want to have to use BootCamp and “waste” 50 odd Gb of hard drive space for Windows and a Windows version of CMSF. Why 50Gb? Well if I’m going to put Windows and “CMSF for Windows” on the MacBook Pro I might as well put the other simulations on too.

So ideally I’ll be buying two copies (one to run on the MacBook Pro and G5) and one for the PC.

If I’m forced to then I guess I’ll just buy the one Windows copy but I wont be installing it on the MacBook Pro.

I appreciate that you can’t restructure your business model just for me but as I say in an ideal world (which you guys have been pretty close to for a while now) we will have a Windows version and a Universal Binary Mac version.

Happy to join the Mac Alpha or Beta test team

[GNFAN]

I would like a Mac OS version as well. While I intend to get one of the new Intel Macs, I don't really want to buy a copy of XP as well to play the game if I don't have to.

I also boot into OS 9 on my iMac to play the CM1 games but I don't play them as much as I used to because of having to reboot.

David

[Battlefront.com]

The current plan is that after a few months post CM:SF release he'll start experimenting with movnig the code over to OSX. The post release demands on us are always huge, which means effectively nothing else gets done for a period of time (probably 1-2 months). He wants to program on the Mac as his primary machine, like the old days, so it's worth investigating at least. If it seems to be too much of a hassle, we'll probably try to find someone to do the port for us. That's an iffy thing for many reasons, but theoretically viable.

If everything goes right there should be a native MacOS X (universal binary) within 4 months of CM:SF's release. So for those of you who G5s or Intel Macs without Windows will likely (not assured) eventually have a universal binary CM:SF. Lower end machines, almost certainly G4s and absolutely G3s, are going to be out of luck no matter what.

That's the plan as we see it now!

Steve

[aka_tom_w]

Thanks Steve for all your very prompt and informative replies!

[gibsonm]

Great news!

Get the Windows product out the door and then focus on the Mac side.

Happy to wait 1 - 2 months (or 3 - 4 for that matter). No doubt this later Mac version will incorporate any “issues” (bug fixes, updates etc.) that are developed for the Windows version so the first Mac release may well be the same as release 1.01 for Windows.

[Fly Pusher]

Originally posted by Battlefront.com:

The current plan is that after a few months post CM:SF release he'll start experimenting with movnig the code over to OSX. The post release demands on us are always huge, which means effectively nothing else gets done for a period of time (probably 1-2 months). He wants to program on the Mac as his primary machine, like the old days, so it's worth investigating at least. If it seems to be too much of a hassle, we'll probably try to find someone to do the port for us. That's an iffy thing for many reasons, but theoretically viable.

If everything goes right there should be a native MacOS X (universal binary) within 4 months of CM:SF's release. So for those of you who G5s or Intel Macs without Windows will likely (not assured) eventually have a universal binary CM:SF. Lower end machines, almost certainly G4s and absolutely G3s, are going to be out of luck no matter what.

That's the plan as we see it now!

Steve

Excellent news.

I hope it all works out.

Good luck...

[Wicky]

Cheers Steve for the update.

[Kilroy Lurking]

Hi!

The Macintel market maybe smaller than you think - I understand that a large proportion of Macintels are the ones with only the onboard graphics chip which is lousy for 3D accelerated games (I know, my wife has a Macbook). IMHO it would be a waste of effort and $s to run Windoze on such machines as seeing the way the game is looking they probably will not run them. (Though I would like to be pleasantly surprised).

If you are a lucky lad with a MacPro plenty of space, horse power and cash makes installing XP a no-brainer.

With a high-end Macintel iMac or Macbook pro running XP from an external Firewire drive would solve the space problem - cash though is something else. This is the (Macbook Pro) route I am thinking of taking sometime after CM:SF, ToW and Napoleon are released. As the latter two will not likely be OSXitiesed its.... XP for me,

Please note Battlefront, a "Combo release" of CM:SF with CMBB & CMAK at an insanely bargain price would probably snare quite a few Macmen who are having to bite the bullet, grit their teeth and think of England all whilst running into the clutches of Billy G in order to enjoy quality gaming.

David

[grunt_GI]

Steve.

I also wanted to thank you for all the prompt responses. As another poster reminded us, what about the new Cider technology? I have heard and read a bit about it, it if it would minimize the porting requirement, would that make things easier to bring us a Universal Binary version...also haven't heard anything about the issues with the Intel GMA chip on the MACBOOKS...I know it works like a champ for CM on XP..and even does a pretty good job on newer OS X games like AOE III and Imperial Glory...I think it gets a bit of a bad rap becaue it doesn't handle FPS type games well, but for something like CMSF what does your gut tell you?

Thanks for all your good work and support for us lonenly Mac Wargamers.

[wildboar]

Please make this game playable on a Mac Intel.

I still have an old powerbook runnig Mac OS 9.2.2, just to play CM. I have been addicted since Beyond Overlord, Barbarrosa and I am now actively playing Afrika Korps.

Please support the Mac Fammily!!

"Cheers"

[aka_tom_w]

Originally posted by grunt_GI:

Steve.

I also wanted to thank you for all the prompt responses. As another poster reminded us, what about the new Cider technology?

Steve said no thanks to Cider in the "Running on Intel Mac Thread:

re: Cider

There have been development kits like this in the past, though with the Intel hardware in place it has become a lot more viable. We're not interested in such a solution. It's likely easier for us to just port the game and probably cheaper too. Especially since this is not a one off game engine. If we use a 3rd party product we have to pay them for each release we do. If we do a port we don't.

Steve

[John Kettler]

I'd much rather play CM:SF in OS X (run Tiger 10.4.8) than have to do the whole fenestral drill. Am already having too much "fun" swapping back and forth between OS X and OS 9. That said, my present rig might be able to run a fireteam in the new game: dual OS 800 MHz lampshade iMac with 512 MB SDRAM and 32 MB VRAM.

(edit)

Forgot to add that I feel profoundly conflicted in that no Mac version of Histwar: Les Grognards nor TOW is apparently in the cards, yet I'd really like to be able to play both.

Regards,

John Kettler

[ February 18, 2007, 11:58 PM: Message edited by: John Kettler ]

[Battlefront.com]

FYI, CM:SF is running on a dual core Power Book Pro under XP without problems. Initially there was a huge problem, but it turned out to be a bug in Windows having to do with power management (for laptops) and dual core setups. The gist of it is high demands on the processors (from 3D intensive games, for example) ran into conflicts with power conservation concerns. There is a patch for this but I don't think Microsoft wants many people to know about it. Why? Because it basically disabled power management, which means millions of laptop owners would see their batteries run down very quickly even when using non-intensive applications. It's the kind of engineering fix we have come to expect from Microsoft

Anyway, it works and works well!

Steve

[gibsonm]

Well with a bit of luck we can avoid such “fixes” (and save the cosot of a copy of Windows XP [which you probably can no longer buy] with a Universal Binary version

[Battlefront.com]

I hope so too You can still by XP. Heck, I think if you look around hard enough you can still buy 95! I picked up my full copy of XP for $95. It sounds like a lot, but for people who play games it is a drop in the bucket. That's the price of two AAA title games. Considering it opens the door to thousand of games that would otherwise be unavailable, it really is a small investment. A lot cheaper than buying a decent PC!

Steve

[gibsonm]

Originally posted by Battlefront.com:

A lot cheaper than buying a decent PC!

Steve

Of course the wag might suggest I already have.

But I do understand your point.

[Kilroy Lurking]

Hi!

CM:SF is running on a dual core Power Book Pro under XP without problems.

Great news,,,,,,,,,,,but I don't suppose on a Macbook?

David

[Pzman]

Since there never was a Powerbook Pro, I'm guessing he means Macbook Pro. To be honest, the Intel graphics in the Macbook is about on par with a Radeon 8500 (6 year old GPU) so I doubt CMSF will run very well, if at all, on that.