Slashdot Mirror
Myth II Carbonized
novocastrian writes "As reported at PlayMyth, Myth II has been Carbonized and will be released to owners of the game on the 15th of March. The work was done entirely by dedicated followers of the game. The disappointing Myth III has also undergone a major overhaul and will be soon be hosted on a popular player-based server."
J adds: Myth II will not support hardware rendering in OS X. But as I recall, software rendering gave an almost-playable framerate even on my 604/250, so on modern machines it might not be bad. Myth I and II were great tactical combat games. I'm itching to play Mudpit again!
Are they going to do anything with the Loki version of Myth 2 for Linux. I haven't been able to get it to run on my Linux boxen for a year and a half now. I never bought the windows version. So if they don't work on it, I guess I'm outta luck ;(
I'm a conservatice devil and quite frankly the games I like best are the ones I played prodigously from around 13-17 before learned to program. New games don't seem all that great to me. In fact, nostalgia plays a major part in my enjoyment of games.
I therefore think it's terrific that all these old games are being brought to MacOS X, f.e. Quake I and Quake 2 and Starcraft/Brood Wars.
this is great news. i was hoping for this just a few days ago. I still play myth 2 online at playmyth.net almost everyday (how many 5 year old games can say that? best $40 i ever spent.
This is really an opinionated question, so it's hard to get a "real" answer. But I feel that a common misconception is that Cocoa is better than Carbon and Cocoa is phasing Carbon out. I think Carbon is going to be around a long long time. I hear people saying "oh, Carbon isn't gonna be with us in two years". Then I remind them that Apple's own Finder app is Carbon. Most of the major Mac apps are Carbon, too (Photoshop, BBEdit, Microsoft Word, etc). At least in earlier versions of the OS, (not sure about now) Cocoa actually used Carbon for many of its functions!
:)
My personal opinion is that both environments have their own advantages. There are a few things like Gestalt that are really handy in Carbon. Cocoa makes it a lot easier to create an app (sometimes this can be viewed as a disadvantage), and is generally easier to learn for newcomers. Some of these gaps will probably close; others will not change.
Some Cocoa projects of mine have used or do use Carbon for certain purposes. Up until recently, the "chasing arrows" or now the spinning gearwheel indicator was only available through Carbon. In 10.2, it's available with Cocoa too. Also, Gestalt. Plus, Carbon has some Apple Event APIs that aren't available in Cocoa. This is just to name a few.
So, essentially, they are both as good as each other. If you've had previous experience with the OS 9 and below toolbox, go for Carbon. If you're new to OS X programming, I'd recommend Cocoa. Cocoa also gives you a lot more free stuff that takes more work to add in Carbon, like Services and spell-checking. When I tried to learn the Mac toolbox a few years ago, I was very confused, and Cocoa seemed to fit right with me. But now that Carbon exists, there are probably better tutorials and books out to help teach it. It's really up to you and your preferences.
Here's a link with more info on Carbon vs. Cocoa:
http://www.unsanity.org/archives/000024.php
Again, this is just my opinion - there's no right answer, IMO. Hope this helps.
Myth: The Total Codex was the first computer game I ever played, and loved it. Didn't actually finish Myth II when I got sucked into Starcraft/Brood War but wanted to go back and replay it. Then OSX came and that was that.
I was in the middle of Rune as well when I upgraded. I wonder if and when that will be carbonized?
Etc, etc, ad nauseam, and so on and so forth.
As a long-time NeXTSTEP, MacOS (all the way back to Finder 1.0), and Newton developer, I have to take some issue with this claim that Carbon has many advantages over Cocoa at all.
Here's what it boils down to: Apple had a lot more developers and a much older OS than NeXT did. This means that MacOS had a lot more low-level hooks for goofy weird things than NeXTSTEP did. Thus Carbon has various low-level hooks that Cocoa doesn't have.
Which is exactly why you shouldn't be using it for your application, except under very special circumstances. You almost never need those hooks (or should instead be hooking to UNIX), and they just make a disaster out of your coding experience.
Cocoa was designed as an *application*framework*, not evolved as a giant morass of hooks to do this or that. And as an application framework, it beats the living bejesus mega-snot out of Carbon. Cocoa has true internationalization, complete unicode usage, real java interoperability, a modern, sophisticated set of graphics primitives, good access to a wide range of services, and a first-rate set of highly integrated widgets. Carbon DOES NOT. You use Cocoa to write the vast majority of productivity apps. You might use Carbon when your app needs to do some odd thing that Apple isn't able to convince users to stop doing yet. But for low-level access, the Right Way to do things, if at all possible, is with Cocoa on top and BSD APIs underneath. If you can in any way help it. Carbon is really, *really* not worth the pain.
And Carbon IS a legacy library.
Sure, the Carbon developers desperately want to convince themselves, deep down, that it's NOT a legacy framework. But it is. It reeks of legacy. Apple maintains it, and adds services to it to keep it in trim, basically because of (1) Microsoft and (2) Adobe. Big software firms don't take kindly to Apple not supporting their recently-ported applications, even if they are written to link against a big pile of poo dating from the 1980's. Apple is supporting Carbon NOT because they want to. They are supporting Carbon because they HAVE to. They have no choice due to the power of their legacy developers.
Write your apps in Cocoa. Or in Java if you must. But don't write in Carbon. Might as well write 'em in COBOL.
Cocoa has true internationalization, complete unicode usage, real java interoperability, a modern, sophisticated set of graphics primitives, good access to a wide range of services, and a first-rate set of highly integrated widgets. Carbon DOES NOT.
Actually, it has identical access as Cocoa (from 10.2). Your anitpathy towards Carbon says more about you as a developer than it does about Carbon's usefulness.
The fact that Carbon has "a giant morass of hooks to do this or that" is simply due to its development over time - Cocoa has the benefit of being largely written all at once (and so has a fairly uniform design), however its main flaw as an API is that it just hasn't had the widespread use and testing that Carbon has.
This means it's ultimately less capable in some areas: e.g., how do I iterate through the list of GUI apps in Cocoa (in Carbon it's easy - talk to the Process Manager and walk through the list). The new Carbon APIs which are coming out of Apple these days (Carbon Events, HIViews, CF, etc) aren't making any of the "mistakes" people made in '84: these are APIs designed for the future, with opaque accessors, reference counting, and a very OOish flavour.
I'm a long time Mac developer as well ('86), as well as *nix/Win32, and frankly Carbon is one of the main reasons Mac OS X is still attractive as a platform - Cocoa is a nice framework, and it certainly was cutting edge when it first came out, but the world has moved on. It's just not that innovative any more, sorry.
And Carbon IS a legacy library
No, it's not. If you'd talked to Apple recently, or been to WWDC in the last couple of years, this would be crystal clear. Carbon is as much a part of the Mac's future as it ever was, and arguably in a more stable position than Cocoa (99% of the developers who generate money for the platform are using Carbon).
Driver. I want Driver on OS X. Driver! Driver! Driver! ;)