Colin Posted March 28, 2001 Share Posted March 28, 2001 So BTS has 3 choices for CMBO: 1)Write a Cocoa version of CM:BO. (Time consuming, expensive but the best results for the long run.) 2)Write an updated version to run under Carbon. (I hear it's reletivly easy and quick but will not take advantage of everything OSX has to offer.) 3)Abandon CM:BO for Mac OS X (BAD!) Also hopefully they will be getting CM2 to run in OpenGL. ------------------ And if we abandon any platform, I can assure you it will not be the Macintosh. -Steve My website! A major source of Wild Bill scenarios! Link to comment Share on other sites More sharing options...
karch Posted March 28, 2001 Author Share Posted March 28, 2001 Originally posted by Maximus: Don't feed the monopoly. Feed competition. You know... that's one reason I like Macs over Windows! can you say MICROSOFT Nice second post though. Good points. I didn't know that about direct x. Good concept. I don't think Linux is toned down to run on lighter machines, I actually think it takes much more resouces than straight UNIX because of the GUI. The GUI takes more system resources than the straight text interface of old world UNIX. Both OSs could learn a few things from each other... and do. They both have strengths and weaknesses and people have personal preferences about them. Let's leave it at that..... Although I know no one will. Scott [This message has been edited by karch (edited 03-28-2001).] Link to comment Share on other sites More sharing options...
Gen-x87 Posted March 28, 2001 Share Posted March 28, 2001 I believe the big problem is Apple dropping all support for Quickdraw3D and Rave in favour of OpenGL in OS X." Imagine that. Apple dumping compatibility? And people wonder why they are at a 7% market share. "Besides I am so glad that 3Dfx's GLIDE API died. " It is actually kind of sad. 1. The Glide API has been an open standard for about 15 months now. 2. My understanding of Glide is it was a much cleaner faster standard than even OpenGL. And of course DX. Gen Link to comment Share on other sites More sharing options...
Schrullenhaft Posted March 28, 2001 Share Posted March 28, 2001 My impression is that CMBO will not be rewritten/carbonized for OS X. I believe the companies that are saying it is "real easy" don't have 3D code to change. In order for CMBO to work with OS X RAVE support will have to be implemented better than it is now (and minimal RAVE support only exists in Classic mode to boot - this is why people aren't seeing the RAVE-based 3D battlefield). BTS would have to rewrite the entire 3D engine in OpenGL before CMBO would be "carbonized" - most likely not gonna happen. What this portends for CM2, I'm not sure. Anyone who doesn't have OS 9.x or earlier will not be able to run CM2. And I wouldn't go blaming BTS for "knowingly" developing in an outdated API. They started on CMBO over three years ago. OpenGL didn't exactly have widespread support with all of the video cards on the Mac. And Apple's "compatibility-level" of support for RAVE was obviously unknown until recently. Apple has gone through painful transitions in the past. I remember very well the PPC transition - for what I was doing at the time it was a complete nightmare since Apple changed a "glue chipset" after the Beta machines were released to 3rd party engineers - it totally messed up our product line. Apple typically tries very hard to make the transitions as painless as possible, but without a prescient 3rd eye, some developers/users can find an important feature non-functional when they upgrade (such is the case with game developers and hardware manufacturers). Last I heard CM2 was going to remain a RAVE based game. There may be thoughts about changing this, but I'm guessing that is still the case. Work on CMII (written in the OpenGL API) is probably going to have to start sooner than anticipated. These are the sorts of things that cause aneurysms in developers. Link to comment Share on other sites More sharing options...
Berlichtingen Posted March 28, 2001 Share Posted March 28, 2001 Originally posted by Maximus: Don't feed the monopoly. Feed competition. Seems like a rather odd statement coming from someone that supports MS Link to comment Share on other sites More sharing options...
mensch Posted March 28, 2001 Share Posted March 28, 2001 I find this disscusion quite lame, and would not bother speculating what BTS will do or make any hopes. I just await what they have to give in a semi-press release for OS X. If they support it great stuff, if they don't also great stuff!. Why well they can spend the next few months re-writing code or say ok CMBO is for 9.0 or less and CM 2 will have the OS X in mind... I rather they spend few months on CM2 for OS X then for OS 9.0+.. as for the FLAMING TROLL MS Users, as me dad said if everyone bothered to take care of thier backyard and not complain and nit pick on the other peoples yards every one would have nice back yards... well I did never understand him then and don't now.. I guess there was a message in his saying.. but I'll leave that as that. I hate TROLLS, as worse as Biggots and Shoe Fly Pie. Link to comment Share on other sites More sharing options...
M. Bates Posted March 29, 2001 Share Posted March 29, 2001 So if you wanna buy expensive stuff, go right ahead, but don't go bashing other users who buy cheaper stuff because of competition. Maximess, you yourself are bashing Mac owners, no? Also Apple is not obliged to let other manufacturers to produce Apple compatible machines. IBM licensed their technology: it wasn't some shared technology experiment between kindly capitalists. Do you know what Apple's markup on an iMac is? Didn't think so. It isn't much I can tell you. Link to comment Share on other sites More sharing options...
Maximus Posted March 29, 2001 Share Posted March 29, 2001 Originally posted by karch: You know... that's one reason I like Macs over Windows! can you say MICROSOFT OK, but can you say Apple Hardware? Every piece of hardware that you would have to buy for a Mac had to be Apple made. Until recently when Steve Jobs FINALLY allowed 3rd party hardware to work in a Mac such as Nvidia video cards. Ever see the TNT movie "Pirates of Silicon Valley"? The story of how Steve Jobs and Bill Gates got into the computer business with Jobs making Apple I's in his garage et al. Then one scene really sums it all up where Steve Jobs said "We've got better stuff." And Bill Gates said, "So what, it's all in the software." (Let 3rd party manufactures build the stuff, but let the software do the work. ie Microsoft DOS and now Windows) Also I understand now that finally in OSX that you can change the system sounds and beeps. So what, Windows users have been able to do this since Windows 3.0 back in the early '90s. And where do you wonder I got this information from? TechTV where the ;lady that does the Mac Tips was all in a flurry to say that now OS X you can finally change the system beeps. Any Windows user would do the following... And going back to the hardware issue. Name one person that has made it rich by manufacturing PC hardware. You can't. Now name one person who has made it rich by manufacturing Apple hardware. Easy...Steve Jobs. See this is what I mean about feeding monopolies. Steve not only has a monopoly on the Mac OS, but also on the hardware itself. But I'd have to admit that I do have a couple Microsoft peripherial devices in a Intellimouse and a Sidewinder Force-Feedback Joystick. OK, now going to the software portion of the argument. Where do you think the majority of these mods come from? Windows platforms. Why because it is easy to be creative and play around with Windows files. Something that you can't readily do with Mac files. Take for instance the complicated CM graphics files and the sound files. Mac users couldn't use any mods at first until someone wrote a program to convert simple bmps and wavs to incoporate into the Mac Graphics file and Sound file. Would the ordinary Mac user know how to extract the CM graphics prior to the Mac Mod Manager? Probably not. This sort of "strictness", for lack of a better term, stems directly from Steve Job's stingyness with his software and hardware. Steve's goal was to make the best machine possible for the customer, however he didn't want anybody "tinkering" with the "guts". So he made the Mac file interface tricky to break. This maybe a cause of the unbreakable hard-coding that CM has as it was developed on a G4. It may not be, I don't know, so that is just a hunch. Anyway, being as stingy as Steve Jobs is with his hardware and software is one reason why I never like Apple computers. For instance, back in the AppleII days, what was the brand of the external 5.25 floppy drive? Surprise, Apple! I'd write a little bit more but I lost my train of thought after browsing over to PriceWatch.com. ------------------ For your dream car click here. For a Close Encounter click here. Hey look! I can see my house! And for all you Hamster Lovers out there, check this out! Kitty, this one's for you! Link to comment Share on other sites More sharing options...
Shadow 1st Hussars Posted March 29, 2001 Share Posted March 29, 2001 This is all I have to say. DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and millions of others are by far the most popular, with about 70 million machines in use worldwide. Macintosh fans, on the other hand, may note that cockroaches are far more numerous than humans, and that numbers alone do not denote a higher life form. ------------------ shadow@jagdtiger.de Canada For CM I AM CANADIAN! Eh? Link to comment Share on other sites More sharing options...
Lorak Posted March 29, 2001 Share Posted March 29, 2001 Umm, Can't believe this one isn't locked up by now. I'll just chime in and give the advice I give to those asking me about buying a home computer. (we use both PC and MAC's at work so I am not biased). I basically tell them that if they are looking for a solid machine with no up-keep to do publishing, day to day work. The MAC is the way to go. But if they are a gamer, or have a kid that is, then a MAC is pretty much a waste of space. Personaly I choose a PC because I am a game-whore. Lorak ------------------ "Do not wait to strike till the iron is hot; but make it hot by striking."--William Butler Yeats Cesspool Combatmissionclub and for Kitty's sake =^..^= Link to comment Share on other sites More sharing options...
aka_tom_w Posted March 29, 2001 Share Posted March 29, 2001 I don't believe this Lets just ingore comments in this thread that are not relevant to the ISSUE of CM2 running on Mac OSX Sure there are video 3d problems but all mac computers that are Sold after sometime LATE this summer will ship with OSX on them and the way things are right now OSX won't run CMBO in the 9.1 classic mode. Has anyone configured the 9.1 classic to work yet? There "should" be a way to make 9.1 run the way it used to before the OSX install so it can run 9.1 the "old" and so CMBO will run on it Other wise it means a reboot and then boot off 9.1 and have it configured for CMBO. I think we can keep this thread relevant to issues about CM2 and 3D video standards. OpenGL support (or the lack there off in CMBO and CM2) IS the issue here. -tom w Link to comment Share on other sites More sharing options...
aka_tom_w Posted March 29, 2001 Share Posted March 29, 2001 edit ooops [This message has been edited by aka_tom_w (edited 03-28-2001).] Link to comment Share on other sites More sharing options...
Logan Posted March 29, 2001 Share Posted March 29, 2001 Jane you ignorant slut... FACT Apple hardware is not manufactured by Apple. And hasn't been since the LCII in 1990. Why, even the G4 processor was designed by IBM, manufactured by Motorola and now is under contract negotiation for license to AMD. For a complete list of products and add ons for Mac please refer to the apple.com web site where you will find names like, oh, IBM, Microsoft, Sony, Harman Kardon, ATI, 3dfx, Maxtor, just to name a few. Your misconception comes from the fact that up until recently, no one wanted to manufacture Mac products because of economics. Let's say it together e c o n o m i c s. It's easier to sell crap to 300 million drewling morons than caviar 7 million erudite souls. FACT If you did watch that show, you'd know that Bill Gates ripped Apple off by blatantly stealing the windows based interface which Apple had previously licensed, then stole from Xerox by slightly re-engineering it. FACT I've been using custom desktop patterns, icons and sounds for close to fourteen years now. I assure you, Xtree Gold, nor Windows 3.31 never had that capability. FACT About your "back to the hardware thing." e c o n o m i c s. See above By the way, what does it take for you to install a new hard drive? Did mine the other day, took me less than five minutes. Just a thought. FACT Ever heard of ResEdit? Guess not. Look it up and find out how creative a Mac user can get with their OS. FACT Back in the Apple II days, Apple was the only mass manufacturer of personal computers. Apple computers held the market share for several years before IBM decided that this whole personal computer thing might actually go somewhere. You're surprised that Apple made the only 5.25" drive? FACT I can easily see how you might loose your train of thought. By the way, is there a caboose on that train, or did you loose that car too? Here's some advice, give up Mac bashing, cause you'll never win. Owning a Mac is a well deserved luxury. Kind of like owning a Mercedes or BMW. A Chevy will get you there just fine, but somehow the ride is just better in a Mercedes. Now about the real subject. Mac OS 9 running on OS X is an emulation, not a real OS. Certain functions are handled by OS X no matter what, such as device recognition, which includes your video card. Here's an observation as to a solution. A conversion to Mac OS X may be done by enlisting the aid of a third party such as The Omni Group. Said third party groups are well versed in OS X technology because of their close ties with NexT back in the day. As example, please refer to the speedy job they did on the Quake Arena game update for OS X. Regardless, until a conversion is made, you'll just have to boot OS 9. [This message has been edited by Logan (edited 03-28-2001).] Link to comment Share on other sites More sharing options...
GriffinCheng+ Posted March 29, 2001 Share Posted March 29, 2001 Hi mom! I have both Prismo and PC! I love them both! Okay? Griffin. ------------------ "When you find your PBEM opportents too hard to beat, there is always the AI." "Can't get enough Tank?" Get the CMSOD at Combat Missing Command Post (CMCP) at http://www.angelfire.com/games3/CMCP/ Link to comment Share on other sites More sharing options...
kmead Posted March 29, 2001 Share Posted March 29, 2001 Please forgive me, can't resist the temptation to feed one of my favorite trolls... Maximus said: OK, now going to the software portion of the argument. Where do you think the majority of these mods come from? Windows platforms. Why because it is easy to be creative and play around with Windows files. I'm sorry Max, here is one of the many places you are wrong. The files are very easy to modify on the Mac. Why are most of the mods from MSW users? Because there are more of them. No other reason. It has nothing to do with the ease of being creative on a platform, by the by Photoshop and its precursers were developed for a Mac (I used the first versions when I was at Art Center in the early nineties). Most of the creatives (the people in graphics companies who make the ads you see) I know still use Macs everyday. Something that you can't readily do with Mac files. Oh so very wrong... Take for instance the complicated CM graphics files and the sound files. Mac users couldn't use any mods at first until someone wrote a program to convert simple bmps and wavs to incoporate into the Mac Graphics file and Sound file. I used some of the first mods on my Mac by using a very powerful tool known as ResEdit, which has been around since I started using Macs in 1985. It makes it easy to change the sounds and graphic resources on a Mac. Is it easier on a Win machine, yes it is, and yes it is a function of how applications are structured on a Mac. The way resources are structured on a Mac is efficient for the way Macs are designed, it is neither better, worse or anything else, just different. I can still just move a application from one Mac to another (in most cases) by just grabbing what I see in one folder and it will work; no DLLs, registries, or other arcana to fiddle with, this is convenient and is again different, but maybe not any better. Would the ordinary Mac user know how to extract the CM graphics prior to the Mac Mod Manager? Yes any Mac user who is interested in changing the way things are does know how to do so. Most don't, many Mac users are fairly lazy in this regard, its not that you can't we just tend not to be interested in that end. The ones who are, are very good indeed. The Mod Manager is a good example of someone doing some nice work that uses some of the tools available in the Mac arena. In regards to the fine work done in the fictionalized show you espouse, keep in mind its the media. As in entertainment. It was neither truly factual or accurate, but it was entertaining. Careful what you believe. Maximus, we were not into a bash MSW session prior to your entry here. Your shallow understanding of the subject matter is all too evident. You are entirely too strident, and jumping to poor conclusions based on faulty knowledge. You are clearly an intelligent individual, and I have enjoyed many of your joustings at windmills. Please feel free to gain the firm knowledge base needed for a sound argument and do not judge things based on the insipid blatherings of media outlets and their soundbites... Karl Mead [This message has been edited by kmead (edited 03-28-2001).] Link to comment Share on other sites More sharing options...
109 Gustav Posted March 29, 2001 Share Posted March 29, 2001 Originally posted by kmead/Maximus: Would the ordinary Mac user know how to extract the CM graphics prior to the Mac Mod Manager? Yes I did. I figured out graphics on my own, and a quick post on this board taught me how to do the sounds. ------------------ The Last Defense- Made any scenarios? Send them here! Well my skiff's a twenty dollar boat, And I hope to God she stays afloat. But if somehow my skiff goes down, I'll freeze to death before I drown. And pray my body will be found, Alaska salmon fishing, boys, Alaska salmon fishing. Link to comment Share on other sites More sharing options...
jaypee Posted March 29, 2001 Share Posted March 29, 2001 Ignoring all the Windows vs. Mac blather I found ... Originally posted by Schrullenhaft: My impression is that CMBO will not be rewritten/carbonized for OS X. I believe the companies that are saying it is "real easy" don't have 3D code to change. In order for CMBO to work with OS X RAVE support will have to be implemented better than it is now (and minimal RAVE support only exists in Classic mode to boot - this is why people aren't seeing the RAVE-based 3D battlefield). BTS would have to rewrite the entire 3D engine in OpenGL before CMBO would be "carbonized" - most likely not gonna happen. And that's it in a nutshell I think. I can almost guarantee you that Apple will not fix or add RAVE support for OS X as they have stated many times that OpenGL is their graphics engine for 3D. Another game that I play fairly regularly put out two versions of the game, an OpenGL and RAVE, with the RAVE version now being phased out by that developer for these very reasons ... no support from Apple. If BTS is only working on a RAVE version for CM2 then I'm afraid that their Mac sales are going to suffer and that is a shame, I think. And no, I don't think it's their fault at all. Unfortunately, Apple can have a rather "deaf ear" at times. Maybe if enough people made some noise ... All this aside and FWIW though, OS X is the BALLS! Link to comment Share on other sites More sharing options...
Berlichtingen Posted March 29, 2001 Share Posted March 29, 2001 Now name one person who has made it rich by manufacturing Apple hardware. Easy...Steve Jobs. See this is what I mean about feeding monopolies. Steve not only has a monopoly on the Mac OS, but also on the hardware itself. Interesting point. The last word I had, was that Jobs was not being paid by Apple... he was in fact working as CEO gratis. He makes his money through his other company... Pixar. Don't want him to get your money? Don't go see Toy Story III. Yes, Apple does control their OS and their hardware... which is why you don't hear Mac users whining about drivers Link to comment Share on other sites More sharing options...
Freak Posted March 29, 2001 Share Posted March 29, 2001 Hey Maximus, Maximus Said: Also I understand now that finally in OSX that you can change the system sounds and beeps. So what, Windows users have been able to do this since Windows 3.0 back in the early '90s. This has been possible in macs for years now. Maximus Said: Ever see the TNT movie "Pirates of Silicon Valley"? The story of how Steve Jobs and Bill Gates got into the computer business with Jobs making Apple I's in his garage et al. Then one scene really sums it all up where Steve Jobs said "We've got better stuff." And Bill Gates said, "So what, it's all in the software."(Let 3rd party manufactures build the stuff, but let the software do the work. ie Microsoft DOS and now Windows) Maximus, try reading a BOOK instead of basing reality on a poorly done, crappy TNT sensationalized TV movie. Maximus Said: And going back to the hardware issue. Name one person that has made it rich by manufacturing PC hardware. You can't. Now name one person who has made it rich by manufacturing Apple hardware Easy...Steve Jobs. See this is what I mean about feeding monopolies. Steve not only has a monopoly on the Mac OS, but also on the hardware itself. Steve Jobs makes $1 a year at apple. Maximus Said: OK, now going to the software portion of the argument. Where do you think the majority of these modscome from? Windows platforms. Why because it is easy to be creative and play around with Windowsfiles. Something that you can't readily do with Mac files. Take for instance the complicated CM graphics files and the sound files. Mac users couldn't use any mods at first until someone wrote a program to convert simple bmps and wavs to incoporate into the Mac Graphics file and Sound file. Would the ordinary Mac user know how to extract the CM graphics prior to the Mac Mod Manager? Probably not. This sort of"strictness", for lack of a better term, stems directly from Steve Job's stingyness with his software and hardware. Steve's goal was to make the best machine possible for the customer, however he didn't want anybody "tinkering" with the "guts". So he made the Mac file interface tricky to break. This maybe a cause of the unbreakable hard-coding that CM has as it was developed on a G4. It may not be, I don't know, so that is just a hunch. This is simply a difference in the way the two platforms store graphic files. Maximus Said: Anyway, being as stingy as Steve Jobs is with his hardware and software is one reason why I never like Apple computers. For instance, back in the AppleII days, what was the brand of the external 5.25 floppy drive? Surprise, Apple! Yes Apple did this but there were 3rd part 5.25 drives available. I dont see your point. Another misguided shot. Maximus this link conatins a documented case about OpenGL and MS. This is interesting stuff. I would like to see what you think about this. http://www.vcnet.com/bms/features/3d.html Link to comment Share on other sites More sharing options...
Freak Posted March 29, 2001 Share Posted March 29, 2001 Also on CM2 and OS X, I sincerely hope BTS changes thier mind about rave and CM. OpenGL is the standard for all macs now OS 9 and X included. In other words OpenGL works great on any mac, whether its OS 9 or X. Rave is now an OS 9 exclusive. BTW this info has been know for quite sometime.(at least a year) [This message has been edited by Freak (edited 03-29-2001).] Link to comment Share on other sites More sharing options...
Freak Posted March 29, 2001 Share Posted March 29, 2001 Maximus Said: OK, Freak, you obviosuly have a problem accepting the views of a Windows user. No, thats not it maximus I am just correcting what I think is false information. [This message has been edited by Freak (edited 03-29-2001).] Link to comment Share on other sites More sharing options...
aka_tom_w Posted March 29, 2001 Share Posted March 29, 2001 Most of you likely won't read this and probably don't give a crap! The article below gives a REALLY good history of this issue. OK I have seen what OpenGL in MAC OSX can do. It can show a 3D object move around in real time and show textures applied to its sufrace change and animate! open GL supports animated testures. what does that mean? we could have an animated gif in a texture so that wheels would spin and tracks would move. OpenGL may be the API Apple is going with because they have defined the HIGH end 3D modeling and special effects market as the place to be.(that means making special effects in movies on Mac's runnig Mac OSX, that means somebody "might" get an oscar for special effects using somthing other than a an SGI box for a change). What does that mean. I means the Mac OSX will support Maya! Now that's HUGE and it is because of OpenGL support. If BTS wants CM or CM2 to run on Mac's in the future they need to take a LONG hard look at supporting OpenGL. Lets stay with the issue here: "No OpenGL support in CM and CM2 so it won't run under Mac OSX at this time" Comments from BTS would be Very welcome. -tom w Credit to Freak, I read this article he mentioned and, I found it SO relevent here that I reposted it in its entirety Thanks Freak! from: http://www.vcnet.com/bms/features/3d.html Microsoft and 3D Graphics: A Case Study in Suppressing Innovation and Competition by Alan Akin > Home > Keynote > Manifesto > Lead Article > Site News > Bookstore > BMS Forum > Bumper Stickers > NT Files > Dirty Tricks > Feature Articles > Departments > Monopolist's Cookbook > Site Credits F oreword The original version of this article was written in July, 1997, and is reproduced (with minor changes to improve continuity and to update hyperlinks) in the first few sections following the Foreword. If you're familiar with the original version, feel free to skip to the August, 1998 Update; otherwise, please proceed to the Introduction. Introduction In the last five years, three-dimensional computer graphics has become a critical technology in the PC world. 3D graphics capability is a prerequisite for two major markets: Computer-aided industrial and mechanical design (for which the majority of workstations and high-end PCs are sold today) and entertainment (especially computer games, which are driving significant new PC hardware and software purchases by consumers). Examining Microsoft's treatment of 3D graphics technology is especially instructive, because so many of Microsoft's actions in that area have been exposed to public scrutiny. Technical Background We must define two technical concepts in order to understand the issues in detail. Application Programming Interfaces First is the notion of an Application Programming Interface, or API. An API is essentially a library of small functions that a software developer pieces together to form a complete computer program. For example, a 3D graphics API might include functions that draw objects, simulate the effects of lights, and determine which objects are visible from a given point of view. A software developer could use these functions to build a flight simulation game: drawing mountains and buildings that would be visible through the cockpit canopy of an airplane, and lighting them as they would be lit by the sun. The design of a 3D graphics API determines what can be drawn, how quickly it can be drawn, and how easy it is for a software developer to achieve a desired effect. Thus the API is of fundamental technical and business importance to the software developers who use it. Device Drivers Second is the notion of a device driver. A device driver (driver for short) is a piece of software that implements an API on a given hardware device. For example, the functions of a 3D graphics API might be implemented differently on the video card in a Compaq PC than they would be implemented on another video card in a Dell PC. In such a case, the two hardware vendors (Compaq and Dell) would each write drivers for the 3D graphics API on their respective video cards. Note that the API would be used in the same way on both machines; only its implementation details (the drivers) would differ. A driver is key to the viability of its associated API and all the application programs that use it. The existence of a driver determines whether a given API is even available on a particular machine. The quality of the driver (its completeness, performance, and reliability) in large measure determines the quality of the software that uses it on that machine. A driver typically requires a significant amount of effort for development and testing, and is therefore of major importance to the hardware vendor who must supply it as well as the software developers and consumers who will use it. History The OpenGL API for 3D graphics By 1992 it was clear that 3D graphics was poised to become a critical technology in several markets. Requests from independent software vendors led a consortium of companies to agree to support a common 3D graphics API. This new API, derived from a popular, older graphics library created by Silicon Graphics, was called OpenGL. OpenGL was to be a state-of-the-art API that could be implemented efficiently on a wide variety of computers. Its specification would be controlled by a committee (known as the Architecture Review Board, or ARB) rather than by (and for the benefit of) a single vendor. It would be easy for any hardware vendor to extend OpenGL to accommodate innovative new features, thus allowing rapid development of new applications. The original members of the ARB were Digital Equipment Corporation, International Business Machines, Intel, Microsoft, and Silicon Graphics. At this time Microsoft was developing the first version of its new high-end operating system, Windows NT. A large part of the computer-aided design market was inaccessible to Microsoft because of technical shortcomings in Windows 3.1, and Microsoft sought to remedy those in Windows NT. One such shortcoming was the lack of good 3D graphics support, and OpenGL offered an expedient solution. The Problem of OpenGL Driver Support As part of a joint engineering project, Microsoft and Silicon Graphics produced an implementation of OpenGL for Windows NT. One feature of this implementation was a new (to Microsoft) device driver design, called an Installable Client-side Driver (ICD), which offered higher graphics performance and permitted any PC hardware vendor to extend the OpenGL API to support new and innovative 3D graphics functionality. This was in contrast to the usual Microsoft driver model, which was appropriate for more modest graphics performance requirements and in which Microsoft reserved exclusive control over the design of the driver and thus of the API it supported. The 3D graphics hardware business for PCs (particularly low-cost PCs) evolved much more slowly than Microsoft and Silicon Graphics anticipated. A few PC hardware vendors (notably Digital Equipment, Intergraph, and 3Dlabs) provided capable OpenGL drivers for machines running Windows NT, but low-cost, high-volume solutions for consumers using Windows 3.1 and Windows 95 were slow to arrive. As 3D graphics hardware became more generally available in 1996, pressure to provide fast, stable implementations of OpenGL increased, and Microsoft developed a new OpenGL device driver design called the Mini Client Driver (MCD). The MCD greatly reduced the time required to produce a quality OpenGL implementation for a large class of PC graphics cards, and thus had the potential to dramatically increase the availability of OpenGL. Microsoft Creates the Direct3D API In 1995 and 1996 Microsoft established a new program to support games on PCs running its Windows 95 operating system. The goal was to expand the market for PCs into the area then dominated by game consoles such as those from Nintendo and Sega. Microsoft chose not to use the OpenGL technology it already provided in Windows NT to handle 3D graphics for games. Instead, Microsoft purchased Rendermorphics, Ltd. and acquired its 3D graphics API known as RealityLab. Microsoft reworked the device driver design for RealityLab and announced the result as a new 3D graphics API called Direct3D Immediate-Mode (Direct3D). Leveraging Windows 95 to Promote Direct3D and Freeze OpenGL Microsoft refused to release the software needed to support OpenGL-based games on Windows 95. In fact, for a considerable time Microsoft chose not to support OpenGL on Windows 95 at all, which made it impossible for users of OpenGL-based applications on Windows NT to run them on Windows 95. Microsoft also took the unusual step of retracting its support for MCD drivers for OpenGL, even though it had already released kits to hardware developers. As a consequence, some hardware developers were forced to recall OpenGL drivers that were already in the beta-test phase. Microsoft's actions partitioned the 3D graphics market, guaranteed that OpenGL would not be widely available on high-volume PCs targeted by Windows 95, and leveraged Windows 95 to boost the overall market penetration of Direct3D. Microsoft marketing teams began to promote the proprietary Direct3D API to games developers, hardware developers, and the trade press, while simultaneously marginalizing OpenGL. If Microsoft mentioned OpenGL at all, it was presented as a low-performance API that was suited only for certain professional computer-aided-design applications on Windows NT, while Direct3D was "mainstream'' and offered ``real-time'' performance on the much more heavily-hyped Windows 95 operating system. (This despite the widespread use of OpenGL in high-performance applications with close technical similarities to games, such as flight simulators.) Microsoft also increased its commitment of staff to Direct3D while freezing the level of staffing for OpenGL, with the result that OpenGL development slowed relative to Direct3D. API Wars Silicon Graphics and many other users of OpenGL have businesses that depend on the ability to offer innovative and high-performance graphics technology. As it became clear that Microsoft intended to replace OpenGL with Direct3D, that Direct3D suffered from many technical shortcomings, and that (unlike OpenGL) Direct3D could not be extended by hardware vendors because it was controlled completely by Microsoft, Silicon Graphics decided to mount a demonstration at the 1996 Special Interest Group on Computer Graphics (SIGGRAPH) conference in New Orleans. The demonstration showed conclusively that OpenGL was at least as fast as Direct3D, thus refuting Microsoft's key marketing claim. Since OpenGL was already acknowledged (by Microsoft among others) as having more functionality than Direct3D, and potentially higher image quality than Direct3D, the demonstration precipitated an intense debate in the computer graphics and game development communities: Why was Microsoft promoting a new, less-capable API, and withholding already-existing device driver technology that could allow its customers to use the superior product? Much of the public discussion took place in the comp.graphics.api.opengl and rec.games.programmer Usenet newsgroups, and is accessible from DejaNews. (If you choose to research this, be prepared for a great deal of reading! Consider searching for the thread titled "DirectX vs OpenGL'' in the comp.graphics.api.opengl newsgroup starting around August of the year 1996.) Game Developers Ask for OpenGL on Equal Footing with Direct3D As the technical and marketing issues were exposed, a strong pro-OpenGL reaction began. John Carmack of id Software, developer of the popular game Doom, stated publically that he would refuse to use Direct3D and use OpenGL instead. Chris Hecker published a comprehensive analysis of the two APIs in the April-May 1997 issue of Game Developer magazine, concluding that Microsoft should simply discontinue Direct3D and put its efforts into OpenGL. It began to appear that Microsoft was using Direct3D to achieve market control and to limit innovation to areas that could not be used to challenge Microsoft, rather than to provide a technically superior product for its customers or to promote free competition between APIs. Two petitions were issued by game developers to Microsoft. The first, from 56 top game developers, called for Microsoft to release OpenGL MCD device drivers and other work that it had completed, but not released because it would allow OpenGL to compete with Direct3D. A second open letter to Microsoft on the same subject gathered 254 signatures initially and over 1400 by the time the letter was closed; the comments offered by some signatories are particularly interesting. Microsoft's reply was to reiterate its old market positioning statement that Direct3D was for high-volume high-performance applications, and OpenGL was for high-precision computer-aided-design applications only. Although the petitioners made it clear that they wanted the two APIs on an equal footing, so that competition spurred innovation and so that no single party controlled access to the graphics hardware, Microsoft responded by increasing its investment in Direct3D and reducing its investment in OpenGL even further. To this author's knowledge, Microsoft never issued a press release to acknowledge the petitions. August, 1998 Update About the time the original version of this article was written, Jon Peddie Associates published a cogent editorial summarizing the situation. Its assessment of Microsoft's strengths, weaknesses, and behavior is worth reading even today. Microsoft continues to update Direct3D, and with each new revision incorporates more features from OpenGL. The overlap is not yet complete; for example, Direct3D still lacks the ability to handle curved surfaces, and it doesn't support graphics cards with geometry acceleration hardware. Nevertheless, Direct3D is much more capable than it was a year ago, and its evolution is beginning to diverge from that of OpenGL. Fahrenheit The most significant development over the past year is the Fahrenheit project. Silicon Graphics, dependent on Microsoft for most of the software required by its upcoming Visual PC product and concerned about technical problems with the DirectModel graphics API announced by Microsoft and Hewlett-Packard, elected to negotiate a compromise. Silicon Graphics, Microsoft, Intel, and Hewlett-Packard created a joint engineering project codenamed Fahrenheit to produce three new APIs. Two of these are beyond the scope of the current discussion, but the third (Fahrenheit Low-Level, or FLL) is usually touted as the resolution of the conflict between OpenGL and Direct3D. What is the Fahrenheit Low-Level API? At the moment no one knows what FLL will be, since no specification exists, but public statements are remarkably consistent in a few respects. From Silicon Graphics' original press release: The Fahrenheit low-level API will evolve from Direct3D, DirectDraw and OpenGL while providing full backward compatibility with applications and hardware device drivers written for Microsoft Direct3D and functional compatibility with Silicon Graphics' OpenGL technologies. From the August, 1998 Microsoft Developer Network DirectX chat session: Direct3D IM is the API that is currently most compatible with what we expect Fahrenheit LL to look like. From slides presented at Microsoft's 1998 Meltdown Conference: Backward compatible with DirectX 6 [the current version] Direct3D... API and DDI [Device-Driver Interface] In other words, the "new'' Fahrenheit Low-Level API is simply Direct3D, plus whatever additional features seem needed to match the functionality in OpenGL. With the competitive threat from OpenGL neutralized, Microsoft can proceed with business as usual. Should Fahrenheit be regarded as a welcome sign of Microsoft's responsiveness to its customers and partners? After all, there will now be just one API, relieving a considerable burden on hardware and software developers and simplifying life for consumers. I would argue the answer is no. The new APIs are entirely Microsoft-proprietary; Microsoft is now the bottleneck for all significant innovation in the computer graphics industry. Furthermore, it must be remembered that the entire conflict was of Microsoft's creation: Without Direct3D, the industry would have arrived at this point literally years ago, with greater opportunity for competition and without the constraint on innovation that Fahrenheit represents today. Status of OpenGL OpenGL is still the only real alternative to complete control of 3D graphics by Microsoft. It remains viable, though Silicon Graphics no longer promotes it in any manner unacceptable to Microsoft, so it is at much greater risk. Game developers are an independent-minded lot, and several important ones are still using OpenGL. As a result, hardware vendors are working to improve their support for it. Direct3D is not yet capable of handling high-end graphics hardware and most professional applications; OpenGL dominates those niches. Finally, the Open Source community (notably the Mesa project) is scrambling to provide OpenGL support for computers of any type, whether or not they use one of Microsoft's operating systems. Conclusions 3D graphics is a valuable case study for students of Microsoft. In the course of this campaign for control of a new market, Microsoft consistently: Acquired or adapted technology from outside organizations, rather than innovating on its own. Used its marketing presence to spread demonstrably false information. Refused to respond to the direct requests of its independent software development partners. Leveraged the market domination of Windows to promote its own products over superior products available from other sources. Used its position as supplier of essential software to curb dissent. Acted to extend or protect its own control over the market, even at the expense of its business partners and of consumers in general. In large measure, it appears that these tactics have succeeded. Microsoft often suggests that it provides only benefit to consumers, that the standardization it enforces is well worth the cost of ceding it complete control over the computer products those consumers use for work and entertainment. In this case, it is clear that standardization for the consumer's benefit was not Microsoft's goal; a superior standard product existed, but Microsoft systematically suppressed it in order to establish its own product and gain control of a new market in which Microsoft previously had no presence. Microsoft did this, and could do this, only because it enjoyed overwhelming dominance as an operating-system supplier. As a result, product features that might have been available to consumers up to two years ago are only now becoming common. In the meantime product development costs for both hardware and software vendors have been increased significantly by the need to deal with two competing standards. 3D graphics application software development has been inhibited by an artificially-created fragmentation of the market into incompatible "consumer'' (Windows 95) and "professional'' (Windows NT) segments. Is this not precisely the kind of situation for which an antitrust action is the appropriate response? Allen Akin is an independent software developer in Palo Alto, California. Appendix: John Carmack's Discussion of OpenGL and Direct3D (Included here because it may be difficult to locate a copy online.) [idsoftware.com] Login name: johnc In real life: John Carmack Directory: /raid/nardo/johnc Shell: /bin/csh On since Dec 15 01:19:05 6 days 5 hours Idle Time on ttyp2 from idnewt On since Dec 17 01:05:12 4 days 23 hours Idle Time on ttyp3 from idcarmack Plan: I am going to use this installment of my .plan file to get up on a soapbox about an important issue to me: 3D API. I get asked for my opinions about this often enough that it is time I just made a public statement. So here it is, my current position as of december '96... While the rest of Id works on Quake 2, most of my effort is now focused on developing the next generation of game technology. This new generation of technology will be used by Id and other companies all the way through the year 2000, so there are some very important long term decisions to be made. There are two viable contenders for low level 3D programming on win32: Direct-3D Immediate Mode, the new, designed for games API, and OpenGL, the workstation graphics API originally developed by SGI. They are both supported by microsoft, but D3D has been evangelized as the one true solution for games. I have been using OpenGL for about six months now, and I have been very impressed by the design of the API, and especially it's ease of use. A month ago, I ported quake to OpenGL. It was an extremely pleasant experience. It didn't take long, the code was clean and simple, and it gave me a great testbed to rapidly try out new research ideas. I started porting glquake to Direct-3D IM with the intent of learning the api and doing a fair comparison. Well, I have learned enough about it. I'm not going to finish the port. I have better things to do with my time. I am hoping that the vendors shipping second generation cards in the coming year can be convinced to support OpenGL. If this doesn't happen early on and there are capable cards that glquake does not run on, then I apologize, but I am taking a little stand in my little corner of the world with the hope of having some small influence on things that are going to effect us for many years to come. Direct-3D IM is a horribly broken API. It inflicts great pain and suffering on the programmers using it, without returning any significant advantages. I don't think there is ANY market segment that D3D is appropriate for, OpenGL seems to work just fine for everything from quake to softimage. There is no good technical reason for the existence of D3D. I'm sure D3D will suck less with each forthcoming version, but this is an opportunity to just bypass dragging the entire development community through the messy evolution of an ill-birthed API. Best case: Microsoft integrates OpenGL with direct-x (probably calling it Direct-GL or something), ports D3D retained mode on top of GL, and tells everyone to forget they every heard of D3D immediate mode. Programmers have one good api, vendors have one driver to write, and the world is a better place. To elaborate a bit: "OpenGL" is either OpenGL 1.1 or OpenGL 1.0 with the common extensions. Raw OpenGL 1.0 has several holes in functionality. "D3D" is Direct-3D Immediate Mode. D3D retained mode is a separate issue. Retained mode has very valid reasons for existence. It is a good thing to have an api that lets you just load in model files and fly around without sweating the polygon details. Retained mode is going to be used by at least ten times as many programmers as immediate mode. On the other hand, the world class applications that really step to new levels are going to be done in an immediate mode graphics API. D3D-RM doesn't even really have to be tied to D3D-IM. It could be implemented to emit OpenGL code instead. I don't particularly care about the software only implementations of either D3D or OpenGL. I haven't done serious research here, but I think D3D has a real edge, because it was originally designed for software rendering and much optimization effort has been focused there. COSMO GL is attempting to compete there, but I feel the effort is misguided. Software rasterizers will still exist to support the lowest common denominator, but soon all game development will be targeted at hardware rasterization, so that's where effort should be focused. The primary importance of a 3D API to game developers is as an interface to the wide variety of 3D hardware that is emerging. If there was one compatible line of hardware that did what we wanted and covered 90+ percent of the target market, I wouldn't even want a 3D API for production use, I would be writing straight to the metal, just like I always have with pure software schemes. I would still want a 3D API for research and tool development, but it wouldn't matter if it wasn't a mainstream solution. Because I am expecting the 3D accelerator market to be fairly fragmented for the foreseeable future, I need an API to write to, with individual drivers for each brand of hardware. OpenGL has been maturing in the workstation market for many years now, always with a hardware focus. We have existing proof that it scales just great from a $300 permedia card all the way to a $250,000 loaded infinite reality system. All of the game oriented PC 3D hardware basically came into existence in the last year. Because of the frantic nature of the PC world, we may be getting stuck with a first guess API and driver model which isn't all that good. The things that matter with an API are: functionality, performance, driver coverage, and ease of use. Both APIs cover the important functionality. There shouldn't be any real argument about that. GL supports some additional esoteric features that I am unlikely to use (or are unlikely to be supported by hardware -- same effect). D3D actually has a couple nice features that I would like to see moved to GL (specular blend at each vertex, color key transparency, and no clipping hints), which brings up the extensions issue. GL can be extended by the driver, but because D3D imposes a layer between the driver and the API, microsoft is the only one that can extend D3D. My conclusion about performance is that there is not going to be any significant performance difference (< 10%) between properly written OpenGL and D3D drivers for several years at least. There are some arguments that gl will scale better to very high end hardware because it doesn't need to build any intermediate structures, but you could use tiny sub cache sized execute buffers in d3d and achieve reasonably similar results (or build complex hardware just to suit D3D -- ack!). There are also arguments from the other side that the vertex pools in d3d will save work on geometry bound applications, but you can do the same thing with vertex arrays in GL. Currently, there are more drivers available for D3D than OpenGL on the consumer level boards. I hope we can change this. A serious problem is that there are no D3D conformance tests, and the documentation is very poor, so the existing drivers aren't exactly uniform in their functionality. OpenGL has an established set of conformance tests, so there is no argument about exactly how things are supposed to work. OpenGL offers two levels of drivers that can be written: mini client drivers and installable client drivers. A MCD is a simple, robust exporting of hardware rasterization capabilities. An ICD is basically a full replacement for the API that lets hardware accelerate or extend any piece of GL without any overhead. The overriding reason why GL is so much better than D3D has to do with ease of use. GL is easy to use and fun to experiment with. D3D is not (ahem). You can make sample GL programs with a single page of code. I think D3D has managed to make the worst possible interface choice at every opportunity. COM. Expandable structs passed to functions. Execute buffers. Some of these choices were made so that the API would be able to gracefully expand in the future, but who cares about having an API that can grow if you have forced it to be painful to use now and forever after? Many things that are a single line of GL code require half a page of D3D code to allocate a structure, set a size, fill something in, call a COM routine, then extract the result. Ease of use is damn important. If you can program something in half the time, you can ship earlier or explore more approaches. A clean, readable coding interface also makes it easier to find / prevent bugs. GL's interface is procedural: You perform operations by calling gl functions to pass vertex data and specify primitives. glBegin (GL_TRIANGLES); glVertex (0,0,0); glVertex (1,1,0); glVertex (2,0,0); glEnd (); D3D's interface is by execute buffers: You build a structure containing vertex data and commands, and pass the entire thing with a single call. On the surface, this appears to be an efficiency improvement for D3D, because it gets rid of a lot of procedure call overhead. In reality, it is a gigantic pain-in-the-ass. (pseudo code, and incomplete) v = &buffer.vertexes;[0]; v->x = 0; v->y = 0; v->z = 0; v++; v->x = 1; v->y = 1; v->z = 0; v++; v->x = 2; v->y = 0; v->z = 0; c = &buffer.commands; c->operation = DRAW_TRIANGLE; c->vertexes[0] = 0; c->vertexes[1] = 1; c->vertexes[2] = 2; IssueExecuteBuffer (buffer); If I included the complete code to actually lock, build, and issue an execute buffer here, you would think I was choosing some pathologically slanted case to make D3D look bad. You wouldn't actually make an execute buffer with a single triangle in it, or your performance would be dreadful. The idea is to build up a large batch of commands so that you pass lots of work to D3D with a single procedure call. A problem with that is that the optimal definition of "large" and "lots" varies depending on what hardware you are using, but instead of leaving that up to the driver, the application programmer has to know what is best for every hardware situation. You can cover some of the messy work with macros, but that brings its own set of problems. The only way I can see to make D3D generally usable is to create your own procedural interface that buffers commands up into one or more execute buffers and flushes when needed. But why bother, when there is this other nifty procedural API already there... With OpenGL, you can get something working with simple, straightforward code, then if it is warranted, you can convert to display lists or vertex arrays for max performance (although the difference usually isn't that large). This is the right way of doing things -- like converting your crucial functions to assembly language after doing all your development in C. With D3D, you have to do everything the painful way from the beginning. Like writing a complete program in assembly language, taking many times longer, missing chances for algorithmic improvements, etc. And then finding out it doesn't even go faster. I am going to be programming with a 3D API every day for many years to come. I want something that helps me, rather than gets in my way. John Carmack Id Software ©1997-8 Moral Highground Productions first posted: 16 July 1997 last revised: 30 August 1998 [This message has been edited by aka_tom_w (edited 03-29-2001).] [This message has been edited by aka_tom_w (edited 03-29-2001).] Link to comment Share on other sites More sharing options...
M. Bates Posted March 29, 2001 Share Posted March 29, 2001 Also I understand now that finally in OSX that you can change the system sounds and beeps. So what, Windows users have been able to do this since Windows 3.0 back in the early '90s. And where do you wonder I got this information from? TechTV where the ;lady that does the Mac Tips was all in a flurry to say that now OS X you can finally change the system beeps. Any Windows user would do the following... Macintosh owners have been able to change system beeps ever since the Mac had a speaker. You could do it in System 6, you could do it years ago. Seems like Maximus' knowledge is based on TechTV and TV movies... Link to comment Share on other sites More sharing options...
Freak Posted March 29, 2001 Share Posted March 29, 2001 Hey thats my Link!!! Link to comment Share on other sites More sharing options...
Freak Posted March 29, 2001 Share Posted March 29, 2001 The problem is maximus thinks macintosh is a copy of windows. Link to comment Share on other sites More sharing options...
Recommended Posts