If you click on each month, and combine Mac OS with MacIntel, you get the following:
Sep 05: 3.74%
Oct 05: 3.87%
Nov 05: 4.11%
Dec 05: 4.35%
Jan 06: 4.21%
Feb 06: 4.30% (4.28 + 0.03)
Mar 06: 4.37% (4.29 + 0.08)
Apr 06: 4.49% (4.33 + 0.16)
May 06: 4.42% (4.19 + 0.23)
Jun 06: 4.32% (3.92 + 0.36)
Jul 06: 4.29% (3.80 + 0.49)
Aug 06: 4.33% (3.71 + 0.62)
The reported 0.02 decline by the Inquirer is the difference of Dec 05 (4.35) vs Aug 05 (4.33). I'm not sure why Dec 05 was chosen as the comparison month vs. Sep 05 (which paints a rosier picture) or Apr 06 (which paints a bleaker picture) but there you have it.
And that does not take into account the recent announcement from Metroworks that they were going to make a PowerPlant Mac/Intel version of their compiler after all.
Metrowerks is, IIRC, releasing PowerPlant as open-source. However, I haven't seen any announcement from them about an OSX Intel compiler/linker. Do you have a reference for the latter?
How? (serious question).
Do you keep a blog somewhere?
Aspyr's status page only mentions the overall milestones, but even so, once we get to alpha, the system specs should be fairly well-known. I do maintain a blog, but I don't post a large amount of work stuff there, just the odd development article now and then with the usual blog filler about bad movies, good restaurants and the guy who cut me off in traffic. It's at http://www.brad-oliver.com:8081/~boliver/blog
Games like CIV are pretty simple programming wise. For a vendor making stuff like that (considering they mainly use C++ (with boost, e.g.) Python and XML a lot) it would be very easy to develop multi platform.
In fact they likely need one single developer more to ahve a Mac + Windows version out at same time.
Civ4 uses the Gamebryo engine, which is DX9-based and has no Mac equivalent. It also uses the Scaleform GFC library for the UI - also DX9 based, also no Mac equivalent. It further uses the ATL from Microsoft - not only does this not have a Mac equivalent, but it uses some interesting compiler extensions native to Visual Studio. But that's not all - it uses Miles 7. 0 - which has no Mac version (yet). And as a kicker, it uses the MS XML library for schema validation - no Mac version naturally, and OSX's built-in XML library doesn't support schemas, only DTDs. Getting this working will be critical to third-party mod compatibility.
I'm trying to imagine one lone guy at Firaxis trying to crank out a Mac version under these circumstances, and it doesn't really look that easy to me. Of course, they could bypass all the middleware and write their own OpenGL-based 3D engine, write their own OpenGL-based UI toolset, write their own OpenAL-based sound library and gimp their XML stuff, but then they'd likely have a longer development time and a greater cost. But they could do it - and then, yes, they couuld probably have one Mac guy make Mac builds.;-)
Now the only real question is, will Civ4 for the Mac be able to play the Mac and PC World in a multiplayer/networked fashion and will it have all the same features.
The best answer we can give at the moment is "probably". I don't see any technical reason why not, but we're dealing with a number of third-party libraries as well. You never know when a licensing agreement will fall through, or the Mac versions of the libraries will be broken in some strange way. Right now though, it looks very promising in this regard.
First off, is the Mac version going to be crippled, or will it be as feature-rich and mod-ready as the PC version?
We're hoping to cripple it in some obscure and hate-inducing way, but so far it looks like we'll have feature parity. However, there are a ton of third-party libraries used ("middleware") so you never know when one will end up causing some oddball incompatibility. Ask again when we get closer to shipping a few months from now.
Second, am I going to need one of the new double-double G5s to run it, or will my 18 month old Powerbook not choke on it?
Answer unclear. Ask again later.
Third, is it going to be chained to the CD like the PC version?
No, most likely it'll be chained to the DVD.;) However, you should be able to eject it after the game launches, for what it's worth. I believe we'll have a serial # scheme for online play, so I guess there's a remote chance the DVD chain will be lifted, however that's not a decision that I make. I'll pass it along though, for all the good it'll do.
Fourth, STOP READING SLASHDOT AND GET BACK TO WORK!!! AND PUT YOUR BACK INTO IT!
Any expectations of compatibility difficulties for team play with nonMac players?
Development is still pretty early (it's not yet drawing anything sensible) so it's hard to give a definitive answer. However, it seems like cross-platform play will be feasible. Ask again in a month or two.:-)
Ooooh, is it too difficult to comprehend that they can only afford so many programmers working at any one time, and that ports have to be done by the same people who are working on the original platform?
Allow me to interrupt this Sarcasmathon with some facts.;-) I work for Aspyr and am the lead programmer on the Mac Civ4 port.
The port isn't being done by the same people who did the PC version - it's being farmed out to a Mac developer and Mac publisher. This is the typical case with most Mac game ports. It also means that we have to wait for legal hurdles to clear, code drops to arrive, and naturally, for the Mac code to start working and stop being buggy.;-) Now you might think that rewriting a game that depends on several third-party libraries with no Mac version and a dependence on DX9 might be trivial, but alas it is not.
Absolutely not.:-) I should have added that I did not (and do not) work for Firaxis, Atari or Infogrames. I did the original Mac version under contract for MacSoft, the Mac publisher who at the time had the rights to a Mac version of Civ3. There's typically a big legal chain for Mac versions - contracts that go every which way between the PC developer, the PC publisher, the Mac publisher and the Mac developer. It boils down to this: the Mac publisher typically is the one to make the announcement about a Mac version once all the contracts have been signed, so in truth I couldn't say anything even if I knew.
The Mac version of Civ3 left so much to be desired (in terms of AI) in comparison to the Windows version that I finally just stopped playing it.
Disclaimer: I'm the programmer who worked on the Mac port of Civ3.
The AI code in the Mac and PC versions is identical. I've never heard of any AI variances between the 2, and no differences have been pointed out by the Mac fans over at the CivFanatics forums (some of them are cross-platform users). Can you provide a saved game that demonstrates a genuine difference?
But I'm telling you that you can have an entirely native Mac version in a matter of hours. Just create the interface with IB, then write your model to handle file I/O. Use bindings to link them together. Piece of cake. Better solution than trying to port Windows code.
I'm certain you've never tried this with an app of any appreciable complexity.;-)
I ported over an MFC app (the Civ3 Editor) using Objective-C++. Strapping the bindings onto the existing MFC code required some pretty involved use of Objective-C++. Rewriting the app from scratch was never an option. There's no way I could have done what you suggest in a matter of hours - there were over 900 interface elements to connect, for starters.
If you have some experience porting MFC apps to Cocoa, I'd certainly be interested in seeing some of your handiwork. Otherwise, instead of arguing with the developers who actually have experience with these matters, you should listen to them.
Fact is, demand for Objective-C++ from our developers is so close to zero as to be completely insigificant.
Really? That sucks, because Obj-C++ is something I've come to rely on when porting code over to OSX. I know of a number of other developers who use it as well. Are you listening to "your" developers?
Image Units are written in the OpenGL Shading Language. The only thing it has in common with Open GL is the name.
That, and the fact that GLSL is part of OpenGL itself.;-) Seriously, CoreImage uses OpenGL's GLSL/fragment program capability, it doesn't write directly to the GPU or bypass OpenGL or other nonsense. (I'm an OSX programmer, specifically games.)
So far, no major breakthrough was achieved this way - main Macintosh game ports are done "the hard way" by companies like Aspyr Media, that's why it takes so long. Only a handful of Mac ports actually use MacDX.
I work for Aspyr Media, and I've worked on a hair over 20 major game ports for the Mac over the course of the past 5 years. I'm not exactly sure what is meant by the "hard way", but we (along with most other Mac game port developers) have essentially written our own Win32/DirectX translation libraries, which have matured greatly over the years. It's fair to say that our own implementation is probably more robust than that in MacDX by virtue of its being more battle-hardened.
With that said, having a DX/Win32 library isn't a magic time-saving bullet for Mac ports by any stretch. Far too much time is spent dealing with byte-swapping issues ranging from the blatant to the subtle. There are also numerous differences in shader programmability that require some re-engineering, as well as the inevitable Mac-specific optimizations to make sure the game is sending the data in a manner that assures that it's running on the fastest possible rendering path on OSX, which may not be the same way that Direct3D would do it.
Personally, I think it should be at the most an opt-in program: that is, students who wanted to use iTunes would opt-in to the program which would be organized by the college, and the fee would be added to their bill. In that case, any student that did not want to participate in that program would not sign up, and those who did want to participate would sign up.
If you make this an opt-in program, why not make other things you don't care for opt-in as well? Don't like your school's fencing program? Don't want to subsidize football jerseys? And what if your camps is blighted with a Starbucks in your student union? Surely a small part of your tuition has gone to make that possible. Granted I'm exaggerating a little, but when you start complaining about paying for non-essential academic stuff, where do you stop?
The point, as I interpreted it, was that the same songs that were being pirated from P2P outlets like Napster et al. are the ones that are being favored through legal online music stores like iTMS and Real. And that this seemed to put the kibosh on the recording industry's argument that piracy was a problem because it made it so that they couldn't "make sure the artists can still comfortably produce new songs."
If that's the point being made by the original poster, then I don't believe it has any basis in fact as presented. You can log on to the iTMS and look at the top songs and top albums being downloaded, almost all of which are recent. There are the usual older suspects - greatest hits albums and Dark Side of the Moon, by by and large it's all either new stuff or new-to-iTMS stuff.
There are no long-term stats given (i.e. slow and steady sales) but the lack of such statistics certainly does not imply that older songs are selling better. If there's another source for this information that does illustrate that point, it would be worth adding to this discussion.
I heard somewhere approx 60% of the mp3's that you buy now were the exact same ones that your got free from Napster a few years ago.
That can't be correct, given that the iTunes Music Store has (last we heard) 70% of the online music market share, and all of their songs are in AAC format rather than mp3.
As far as GZ, no it can't be trusted as "the best" measure since so many of the Open Browsers (and Opera) can be told tolie about what they are and what they are running on; and many do to get around stupid you must use this browser to access" javascripts.
Indeed, but I would think that would affect all low-marketshare OSes more or less equally. Certainly there are a number of Mozilla/Firebird/Camino users on the Mac that do this, and Safari on the Mac can be configured to behave similarly.
They're talking about sending it out as part of the SMTP delivery failure notification, not as an email message. Spammers will ignore it. Legit senders will get an email generated by their own mail server.
Perhaps I'm not explaining the situation clearly enough. In looking at my spam filters now, over 50% of the messages caught are SMTP delivery failure notifications. I have no confidence that people will be able to configure their SMTP servers to send back these notifications to the real sender rather than the spoofed sender, if that is in fact what you are suggesting will happen.
Try setting up a message in the 'this address does not exist' autoreply.... The bad guys shouldn't get it, and the poor twinks who have their domain name spoofed will probably ignore it.
As a "poor twink" on the receiving end of a lot of spam, I've found that my filters are effective against everything but auto-replies.
Getting a ton of auto-replies from people on vacation, with invalid addresses, support addresses that have changed, and the ever-helpful "you've sent us spam and we've rejected it but our spam filter is too stupid to realize the sender was forged" really gets old after the first week.
Don't use an autoreply and turn your problem into my problem.
The overwhelming number of times when there's a bottlenecked task, it's a single CPU-bound thread. Having multiple processors will provide only nominal benefits. Apple putting multiple processors on-board won't *hurt*, except in the wallet, but it's not going to give Quake 3 double the framerate.
Perhaps not double, but Quake 3 is SMP-aware, and does see a significant frame-rate boost from dual-processor Mac boxes.
...I'm not very familiar with programming Linux GUI apps. And by that I mean I have no clue what it entails. So with that in mind...
Doesn't having two or more GUIs in competition mean multiple APIs to target? If I were developing a Killer Linux Desktop App, don't I as a programmer need to decide KDE or Gnome? Or is this a non-issue?
1.5 apparently breaks the Pinstripe theme on the Mac. This is unfortunate, because it's pretty much the only theme out there that makes Mozilla look like it belongs on the Mac.
I see other posters raving about Firebird, but unfortunately here again Mac users seem to have trouble - there don't seem to be any nightly (or recent) Mac builds of Firebird, so those of us who don't want to suffer through the build process are out of luck.
Slashdot Mirror
Sep 05: 3.74%
Oct 05: 3.87%
Nov 05: 4.11%
Dec 05: 4.35%
Jan 06: 4.21%
Feb 06: 4.30% (4.28 + 0.03)
Mar 06: 4.37% (4.29 + 0.08)
Apr 06: 4.49% (4.33 + 0.16)
May 06: 4.42% (4.19 + 0.23)
Jun 06: 4.32% (3.92 + 0.36)
Jul 06: 4.29% (3.80 + 0.49)
Aug 06: 4.33% (3.71 + 0.62)
The reported 0.02 decline by the Inquirer is the difference of Dec 05 (4.35) vs Aug 05 (4.33). I'm not sure why Dec 05 was chosen as the comparison month vs. Sep 05 (which paints a rosier picture) or Apr 06 (which paints a bleaker picture) but there you have it.
Metrowerks is, IIRC, releasing PowerPlant as open-source. However, I haven't seen any announcement from them about an OSX Intel compiler/linker. Do you have a reference for the latter?
How? (serious question). Do you keep a blog somewhere?
Aspyr's status page only mentions the overall milestones, but even so, once we get to alpha, the system specs should be fairly well-known. I do maintain a blog, but I don't post a large amount of work stuff there, just the odd development article now and then with the usual blog filler about bad movies, good restaurants and the guy who cut me off in traffic. It's at http://www.brad-oliver.com:8081/~boliver/blog
In fact they likely need one single developer more to ahve a Mac + Windows version out at same time.
Civ4 uses the Gamebryo engine, which is DX9-based and has no Mac equivalent. It also uses the Scaleform GFC library for the UI - also DX9 based, also no Mac equivalent. It further uses the ATL from Microsoft - not only does this not have a Mac equivalent, but it uses some interesting compiler extensions native to Visual Studio. But that's not all - it uses Miles 7. 0 - which has no Mac version (yet). And as a kicker, it uses the MS XML library for schema validation - no Mac version naturally, and OSX's built-in XML library doesn't support schemas, only DTDs. Getting this working will be critical to third-party mod compatibility.
I'm trying to imagine one lone guy at Firaxis trying to crank out a Mac version under these circumstances, and it doesn't really look that easy to me. Of course, they could bypass all the middleware and write their own OpenGL-based 3D engine, write their own OpenGL-based UI toolset, write their own OpenAL-based sound library and gimp their XML stuff, but then they'd likely have a longer development time and a greater cost. But they could do it - and then, yes, they couuld probably have one Mac guy make Mac builds. ;-)
The best answer we can give at the moment is "probably". I don't see any technical reason why not, but we're dealing with a number of third-party libraries as well. You never know when a licensing agreement will fall through, or the Mac versions of the libraries will be broken in some strange way. Right now though, it looks very promising in this regard.
We're hoping to cripple it in some obscure and hate-inducing way, but so far it looks like we'll have feature parity. However, there are a ton of third-party libraries used ("middleware") so you never know when one will end up causing some oddball incompatibility. Ask again when we get closer to shipping a few months from now.
Second, am I going to need one of the new double-double G5s to run it, or will my 18 month old Powerbook not choke on it?
Answer unclear. Ask again later.
Third, is it going to be chained to the CD like the PC version?
No, most likely it'll be chained to the DVD. ;) However, you should be able to eject it after the game launches, for what it's worth. I believe we'll have a serial # scheme for online play, so I guess there's a remote chance the DVD chain will be lifted, however that's not a decision that I make. I'll pass it along though, for all the good it'll do.
Fourth, STOP READING SLASHDOT AND GET BACK TO WORK!!! AND PUT YOUR BACK INTO IT!
Can do. :)
That's the plan. We need some third-party libraries to be universal as well to pull it off, but my fingers are crossed.
Development is still pretty early (it's not yet drawing anything sensible) so it's hard to give a definitive answer. However, it seems like cross-platform play will be feasible. Ask again in a month or two. :-)
Allow me to interrupt this Sarcasmathon with some facts. ;-) I work for Aspyr and am the lead programmer on the Mac Civ4 port.
The port isn't being done by the same people who did the PC version - it's being farmed out to a Mac developer and Mac publisher. This is the typical case with most Mac game ports. It also means that we have to wait for legal hurdles to clear, code drops to arrive, and naturally, for the Mac code to start working and stop being buggy. ;-) Now you might think that rewriting a game that depends on several third-party libraries with no Mac version and a dependence on DX9 might be trivial, but alas it is not.
Absolutely not. :-) I should have added that I did not (and do not) work for Firaxis, Atari or Infogrames. I did the original Mac version under contract for MacSoft, the Mac publisher who at the time had the rights to a Mac version of Civ3. There's typically a big legal chain for Mac versions - contracts that go every which way between the PC developer, the PC publisher, the Mac publisher and the Mac developer. It boils down to this: the Mac publisher typically is the one to make the announcement about a Mac version once all the contracts have been signed, so in truth I couldn't say anything even if I knew.
Disclaimer: I'm the programmer who worked on the Mac port of Civ3.
The AI code in the Mac and PC versions is identical. I've never heard of any AI variances between the 2, and no differences have been pointed out by the Mac fans over at the CivFanatics forums (some of them are cross-platform users). Can you provide a saved game that demonstrates a genuine difference?
Those cities (including your favorite, Surprise) don't border Tempe - Guadalupe does.
I'm certain you've never tried this with an app of any appreciable complexity. ;-)
I ported over an MFC app (the Civ3 Editor) using Objective-C++. Strapping the bindings onto the existing MFC code required some pretty involved use of Objective-C++. Rewriting the app from scratch was never an option. There's no way I could have done what you suggest in a matter of hours - there were over 900 interface elements to connect, for starters.
If you have some experience porting MFC apps to Cocoa, I'd certainly be interested in seeing some of your handiwork. Otherwise, instead of arguing with the developers who actually have experience with these matters, you should listen to them.
Really? That sucks, because Obj-C++ is something I've come to rely on when porting code over to OSX. I know of a number of other developers who use it as well. Are you listening to "your" developers?
That, and the fact that GLSL is part of OpenGL itself. ;-) Seriously, CoreImage uses OpenGL's GLSL/fragment program capability, it doesn't write directly to the GPU or bypass OpenGL or other nonsense. (I'm an OSX programmer, specifically games.)
I work for Aspyr Media, and I've worked on a hair over 20 major game ports for the Mac over the course of the past 5 years. I'm not exactly sure what is meant by the "hard way", but we (along with most other Mac game port developers) have essentially written our own Win32/DirectX translation libraries, which have matured greatly over the years. It's fair to say that our own implementation is probably more robust than that in MacDX by virtue of its being more battle-hardened.
With that said, having a DX/Win32 library isn't a magic time-saving bullet for Mac ports by any stretch. Far too much time is spent dealing with byte-swapping issues ranging from the blatant to the subtle. There are also numerous differences in shader programmability that require some re-engineering, as well as the inevitable Mac-specific optimizations to make sure the game is sending the data in a manner that assures that it's running on the fastest possible rendering path on OSX, which may not be the same way that Direct3D would do it.
If you make this an opt-in program, why not make other things you don't care for opt-in as well? Don't like your school's fencing program? Don't want to subsidize football jerseys? And what if your camps is blighted with a Starbucks in your student union? Surely a small part of your tuition has gone to make that possible. Granted I'm exaggerating a little, but when you start complaining about paying for non-essential academic stuff, where do you stop?
If that's the point being made by the original poster, then I don't believe it has any basis in fact as presented. You can log on to the iTMS and look at the top songs and top albums being downloaded, almost all of which are recent. There are the usual older suspects - greatest hits albums and Dark Side of the Moon, by by and large it's all either new stuff or new-to-iTMS stuff.
There are no long-term stats given (i.e. slow and steady sales) but the lack of such statistics certainly does not imply that older songs are selling better. If there's another source for this information that does illustrate that point, it would be worth adding to this discussion.
That can't be correct, given that the iTunes Music Store has (last we heard) 70% of the online music market share, and all of their songs are in AAC format rather than mp3.
Indeed, but I would think that would affect all low-marketshare OSes more or less equally. Certainly there are a number of Mozilla/Firebird/Camino users on the Mac that do this, and Safari on the Mac can be configured to behave similarly.
Perhaps I'm not explaining the situation clearly enough. In looking at my spam filters now, over 50% of the messages caught are SMTP delivery failure notifications. I have no confidence that people will be able to configure their SMTP servers to send back these notifications to the real sender rather than the spoofed sender, if that is in fact what you are suggesting will happen.
As a "poor twink" on the receiving end of a lot of spam, I've found that my filters are effective against everything but auto-replies.
Getting a ton of auto-replies from people on vacation, with invalid addresses, support addresses that have changed, and the ever-helpful "you've sent us spam and we've rejected it but our spam filter is too stupid to realize the sender was forged" really gets old after the first week.
Don't use an autoreply and turn your problem into my problem.
Perhaps not double, but Quake 3 is SMP-aware, and does see a significant frame-rate boost from dual-processor Mac boxes.
Doesn't having two or more GUIs in competition mean multiple APIs to target? If I were developing a Killer Linux Desktop App, don't I as a programmer need to decide KDE or Gnome? Or is this a non-issue?
1.5 apparently breaks the Pinstripe theme on the Mac. This is unfortunate, because it's pretty much the only theme out there that makes Mozilla look like it belongs on the Mac. I see other posters raving about Firebird, but unfortunately here again Mac users seem to have trouble - there don't seem to be any nightly (or recent) Mac builds of Firebird, so those of us who don't want to suffer through the build process are out of luck.