Slashdot Mirror
No More Unreal Ports For Linux?
Ant was among the first to write with a link to this article on Blue's News claiming that Epic's new game engine is Direct 3D only, based on statements made at an E3 demo yesterday. Check that link to read the full article, but consider this excerpt: "A major side effect of this is that any
future ports of Unreal-engine titles that use the new technology will need to have a
completely rewritten rendering system, making Mac and Linux ports significantly
more difficult."
DoenerMord also wrote, saying "This
kind of puts some perspective on recent comments from Tim Sweeney (the man behind the Unreal engine) on Microsoft's
breakup ..."
Quoting from http://lists.openprojects.net/pipermail/glx-dev/19 99-December/002511.html:
I asked a microsoft rep about exactly that one time. He said they would
"protect" the API. Big difference from SGI's tacit aproval of mesa.
Sadly, what many people are ignoring is that not only the Linux ports are losing out, but the PC as a platform, too. To get the last 4 games that I bought run on my Win system, I had lots of trouble, lots of tweaking to do. For me that's fine, but for the average John Smith user it's a nightmare. I went to E3 last week and at the PS2 booth I overheard Jay Wilbur behind me (formerly id, but now I guess working for Epic), saying that though they sold UnrealTournament poorly on Win, they hope that on PS2 it will receive the attention it has lacked so far. I think this may be the last year of the PC as a gaming platform, as - let's face it - the second generation of console platforms are just very attractive for developers - potentially much higher sales and much better issues regarding technical support. QA is getting to be a major trouble these days. As much as many /.ers may believe that Linux ports are the key to success, I think that the platform losing out is the PC in general. If there are PC ports in the future it will be ports from existing 2nd gen consoles and if these ports are from XBox, it is clear that this may be problematic for Linux ports.
Sure different implementations in D3D have different capabilities. In D3D, however, they are all emulated to smooth things over. Take compled vertecies for example. In OpenGL, if the ICD doesn't support that extensions, then you're ass out. In D3D, it is emulated where not avaible. The thing is that the new vertex and pixel stuff in DX8 will be emulated where not available. Write to the API and you can be sure that high quality implementations like nvidia's and matrox's and ATI's will accelerate the shading correctly. If the feature is not available, then it will be correctly emulated by D3D. About you second point, I think there is a general concensus that extensions suck. Take those nVidia extensions. Sure every feature will be there, but you'll have to rewrite your code to support the Radeon, then you'll have to do it to support Matrox's new card. A game developer is not going to wait a year for the ARB to approve an extensions when a major new graphics arch comes out every 6 months. Also, about MS shafting vendors, you've got it wrong. The game developers and the hardware companies come up with a set of featueres they want. Then the game developers ask for a set of features they'd like to see in hardware. MS puts those feautures in D3D, emulating them if they are not available in hardware. They bait the hook if you will. In the next revision of graphics cards, the hardware vendors take the bait and add that feature to the graphics hardware. This transition is seamless. When the new cards come out, the feature goes from being emulated to accelerated. No shafting is involved. In fact, MS hates nvidia (too much support for OpenGL), but I don't see any features in D3D shafting nVidia. In fact, quite the opposite, stuff like cubic environment mapping shows of a lot of features in nVidia cards. As for your third comment, MS stopped copying OpenGL features long ago. Why? They ran out of features by versions 6. Most of the cool, nifty stuff in 7.0 is new, and 7.0 is quite stable and fast. I doubt 8.0 will be any different.
A deep unwavering belief is a sure sign you're missing something...
Eh, that's true, but..
The GNU port of Allegro is in a rather bad state right now. I downloaded it to play a nifty game called "Liquid War", and straight off discovered that I had to install the binary version because it would not compile from source. (it looked like a syntax error, as I recall, but I wasn't in a mood to hunt the bug down) Once installed, it worked -- except for several very annoying efficiency problems: among other things:
-> it appears to not block at all, even when the program is doing nothing but waiting for input with an unchanging display. I suspect it just spins to handle timing instead of sleeping (I haven't tried to verify this)
-> Drawing seems to be insanely inefficient. I don't know whether it's using shared memory (I suspect it isn't), but I've seen games of much less visual complexity work with much less CPU usage. Some button-pushing popped up what looked like a meter of time used, showing that almost all the time was going into drawing routines rather than game logic.
-> For some reason, Allegro insists on using its own special mouse cursor instead of X's.
The upshot of this is that displaying a static title screen takes 100% of my CPU time. Not so good.
Of course, this is really still a beta version of the port and I'm sure it'll get better..unless these problems (eg, assumptions of 100% CPU access) are present in the API as well. I haven't looked to see, perhaps you can tell me.
Daniel
Hurry up and jump on the individualist bandwagon!
Actually, if these were standardized on hardware, then the API would never evolve. No cubic environment mapping for you!
A deep unwavering belief is a sure sign you're missing something...
The problem is, no one follows the "standards" the same way. Take HTML for example ...
... those OEM vendors signed the contracts, no one forced them to do so ...
Bad example. HTML is not supposed to look the same everywhere. When are people going to figure that out? HTML is supposed to be a presentation-independent, logical markup language. You markup what you are trying to say; the user agent (browser) determines how to say it.
Netscape and IE. Wait, hold on, those two are guilty of extending the markup language on their own...
I'm not saying NSCP and MSFT aren't both guilty of the crime of discarding standards. Indeed, I've condemned Netscape for their behavior in the past. Mozilla, at least, is based on standards, although I think that was because NSCP saw that was their only hope.
I personally just want to use whatever works well, and I want it to be the same.
So, we shouldn't have a choice? A single, select few companies should control what is fast becoming the most important communications medium in human history? We should be at the mercy of MSFT, AOL, and the like?
And you call yourself a libertarian? Libertry is the root of that word, and it seems you're not all that familiar with the concept.
Um, MSFT very much forced them to do so. It was either that, or lose their right to to distribute Microsoft's OS, which was pretty much the only choice (see monopoly). The only choice the companies had was to sign the contracts or go out of business.
If that's your definition of "liberty", well, I'm glad I don't agree.
There is a great advantage to having a somewhat standardized Operating System.
There are advantages to having a somewhat standardized health care system, too. And to the regulation of firearm ownership and operation. Yet, if you are a libertarian, I'm sure you are strongly against such things. Why are OSes different?
One of my greatest frustrations with Linux is the amount of variance in the systems and the versions of the libraries they include.
Funny, that's my greatest frustration with MS-Windows. On Linux, all I have to do is grab a copy of the library I need, install it, and I'm all set. The better package-management tools even take care of this for you, automatically and transparently.
On Windows, that is often illegal, and when it isn't, you still cannot have more then one version of a library installed. DLL Hell. No, thank you!
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
> OpenGL seems to me to be an exceedingly well-thought-out, clean, and consistent API.
;-)
It is. Check out the blue book for more goodies on the orthogonality of OpenGL.
> What is wrong with GL?
Not a hell of a lot.
- The only real drawback of GL is that software rendering speeds, are, shall we saying "quite lacking". It was meant for 3d hardware.
- OpenGL drivers usually aren't as optimized as DirectX due to limited time and money.
- Some people will complain that the OpenGL doesn't support every new feature in a consistent way, but the OpenGL extension is a much better way to do things. ANY vendor can add their own extensions. After implementations settle down, it may become part of the standard. Look at how long it took M$ to get rid of the Execute Buffer garbage in Direct3D 2/3.
--
"If I protest an illegal tax, does that make me an illegal tax protester ?
It's sad, but true. OpenGL needs a lot of
extensions now, and these extensions must be
made mandatory for the next generation of
games.
Cards are now hitting the market with environmental bump mapping, cube mapping, texture coordination perturbation, etc, and unfortunately, the only way these are currently supported is through mutually incompatible OpenGL vendor extensions.
In typical MS fashion, DX1,2,3..5 sucked. By DX6-7 were good, and now DX8 overtakes OpenGL.
You can't blame game developers from moving away from OGL if they can't write to a consistent standard API that utilizes all of the hardware acceleration features available on a card.
This christmas we will see the ATI Radeon, 3dfx Rampage, and NV20. All of these chipsets are likely to support the DX8 shading language. OpenGL won't except through proprietary extensions like NVidia's register combiners extension. That means developing a game that uses advanced photorealistic lighting on OGL will be hard.
Herein lies the difference between open-source and commercial development. MS actually runs conventions, gathers developers and manufacturers together in the same room, has people present papers, and say: What do you want in the API? The game developers and hardware manufacturers interact, and MS adds the most request features to the API.
As far as I know, there is no open-source equivalent to MS Meltdown, E3, WinHEC, etc.
What Linux needs is a hardware/kernel convention so that there is some actually two-way communication between developers and manufacturers instead of just: "Gimme your goddamn specs so I can write a driver."
The only reason that UT windows made the sales is because there was no Linux boxed version available. Yeah, I had to buy the windoze version and d/l the binaries to play under Linux. And you know what, my framerates blew away everyone else running it under windoze. I guess they are ditching Glide for the very same reason nVidia is ditching Linux: money. Seems they enjoy sucking the micro$oft moneycock just like nVidia. Thanks a lot, Epic. Enjoy your time while you can.
"Klaatu, verada, necktie!" -Ash
You can't "just port Direct3D to linux", because D3D is carefully licensed and protected by Microsoft. The reason they switched to D3D-only is because OpenGL doesn't have the features Sweeney wanted, and he told Microsoft to add such features to D3D. OpenGL's ARB just can't implement new features and versions of OpenGL as quickly as Microsoft can add new features to D3D, due to organization structure and manpower.
I bought Unreal Tournament only because there was a linux port of it.
I will certainly not buy Unreal 2 unless there is a Linux port of it. And a server only port is not enough for me.
What's really interesting is that EPIC seems to be desperate enough to bank on their relationship with Microsoft, and they do all that in a very foggy situation when Microsoft can be split up and God know what else can happen to them. EPIC is really taking a major bet here, and this probably is because they are not really doing too well in financial terms, hence comes cash infusion from Microsoft. Games development is an expensive business you know... and hey, EPIC guys deserve to drive Ferraries, too, right?
alexc
Join Majestic-12 Distributed Search Engine
Or what about a cross-platform security feature like Kerberos? No wait, I got to think more about this one.:-)
The problem here is again, a different stack here, a different browser here, a different protocol there, a different compression scheme here, a different xml engine there, a different ipsec here, and you get the point.
I could see microsoft being forced to allow its applications to run/be developed for OTHER platforms, but making win98/win2000 and future versions be broke up to replaceable components is DUMB. And that will cause problems.
P.S. You can diss glide, but it was 3dfx voodoo and glide that started the whole PC gaming era as we now it. Without them, we would all still have VLB 1 meg Cirrus Logics :)
I am slashdot, that is, i am one of the many people that read and believe in slashdot and its ideas about open source. I feel that if microsoft would release the source code for its products they COULD be improved drasticly. But about this whole DirectX thing
DirectX is a standard that is not perfect, but does its job quite well. only problem is that it is ONLY windows. If the DOJ breaks up microsoft then EPIC may not be able to pull back together enough to improve their games using OpenGL or something. They are jumping into a TRUST relationship with microsoft saying "you can do it, and we will make our shate for your shate only"
my solution,
the DOJ make microsoft release source code for the technologies that give it an advantage. DirectX for one. Microsoft gives the Linux comunity the source for DirectX, next day there is a custome installer for GNOME or KDE, BeOS can run every game windows can with perfect memory protection, and Macs can play more than solitair on their proprietary OS. Next step
DOJ looks at Intel and says Monopoly, you must turn over all of your proprietary technology and Open-source the plans, suddenly the AMD thunderbird is socket370 on a Alpha bus at 200MhzFSB and you can still clock it down to 66MhzFSB to run your old celeron366.
Overclockers are happy because they have BUS options up to 200-or 400mhz later on- and still use the chip they have today, and then they can upgrade down the road. They know that their socket370 chip will work in any new motherboard. Servers are running the same socket370-or socket A if your diehard AMD- so you can strap in your new AMD Athlon Xeon-which just happens to support first generation SIMD and advanced 3Dnow- and you can swap it out for the new 1.5Ghz Intel whillimet Xeon-which has a better SIMD but its 3Dnow aint quite as good.
Standards are good, and there is something to be said about open source, final thoughts:
open source every standard, not to be modified necesarily, but to MAKE it standard. Game developers would only have to make one rendering engine, it would run on Mac, linux, BeOS, BSD, windows, java, the new amiga, everything. they would just need some poor, boored hacker to port the executable over.
Join the OpenUT list at openut.sourceforge.net. I will guarentee it is an installation issue. 99.9% of the maps out there work just fine. In fact, I haven't found one that doesn't, but I know of a few circumstances that would prevent a map from running. jf
so it'll be an easy port to the Xbox once it's released. I'm sure Microsoft threw them several million dollars.
is not JUST a graphics API like OpenGL is. DirectX is a whole package of media libraries. Funny thing about this is I sent in an Ask Slashdot a couple months ago asking if people were using OpenGL more or D3D. Anyways, DX is very popular (in my estimation) because it is a unified set of media libraries that are all written together and in the same way. A bonus is that video and sound cards have hardware DX support. This is a boon to any game developer because it means the CPU can pump out a few extra transforms or some smarter characters and so forth. What I have yet to hear about is a completely open and cross platform media API. There probably are a few floating about, they need some attention. I really like being able to play the same game on multiple platforms, I really wish more games could be developed on multiple platforms. I would have thought a game like Unreal would have primarily cross platform development in mind, you're trying to get as many people fragging as possible. Oh well, I don't play Unreal anyways and HALO will be on Mac and PC so I'm happy.
I'm a loner Dottie, a Rebel.
MEEPT is back! All Hail MEEPT!
Please moderate the parent up. (only moderate my plea down after moderating the parent up, or ignoring my post and moderating nothing)
Why?
Because now that slashdot is censoring trolls and other fun-loving individuals, (try posting something with "First Post" in the subject line, too many capital letters, too much punctuation, etc., etc. and see what snide replies you get) a good way to combat this would be "intelligent trolling".
...and if you don't remember him, MEEPT is the king of intelligent trolling.
So please, let him post with a default score of 0 or 1 just so the funny ones have a chance of being moderated up more, and I can see his posts more often! (and look through his history, moderate the good posts up to +5!)
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Epic has already made a ton of money off of all three operating systems. And yet they would do something which would hinder that strategy? Particularly with an inferior 3D API?
I'm not worried about the Mac port; Westlake (who did the Unreal and UT ports to MacOS) has a lot of experience converting DirectX to interoperable API's (heck, most of The Sims is Windows-specific but they've already got it playable, albeit not yet at Alpha). But this could spell big trouble for the Linux port.
It's yet another of Microsoft's Broken Promises (tm). The Mac compatibility layer for DirectX was due years ago, according to Microsoft itself. And with a public API, a Linux layer would have been far easier to implement.
Now, let's look for a moment at layers:
DirectX
Pro - Easily controlled if you're in bed with MS, as Epic admits to being. Relatively easy to program.
Con - Windows-specific.
QuickDraw3D
Pro - Very easy to program. Available on many platforms via the Quesa project (already nearly complete). (and available on at MacOS and Windows in its original, closed implementation) Open-Source, again via Quesa. Implements a standard file format (3DMF, the basis for VRML97).
Con - No longer being actively developed by Apple.
OpenGL
Pro - The most powerful API out there. Already has the non-game marketshare by an overwhelming margin. Runs almost anywhere (hell, it even runs on PalmPilots!) Has Open-Source "alternatives."
Con - Few primitives, making it harder to program. Eats resources like you wouldn't believe; requires hardware acceleration for decent results. No true Open-Source "implementations," though that's more a technicality than anything else.
So which is the best? Each has its pros and cons. I'm more partial to the underappreciated QD3D (which, incidentally, Quesa implements on top of OpenGL). I will say that DirectX's platform specificity is a big problem unless you only plan to port the thing to the X-Box. But again, if you're in bed with MS, you can change the API practically at will. OpenGL really doesn't have that big a share of the gaming market (though overall it's overwhelmingly the most popular), but it's more powerful than any of the others. QD3D has ease of programming, but it never really caught on for some reason.
Their conclusion is probably because there's a huge overlap between Windows and Linux users (those who dual-boot to run Windows games), and it certainly doesn't make sense for them financially to support both platforms, since those dual-booting Linux users will buy their games anyways.
Besides, supporting DirectX only will get on Microsoft's good side, which leads to preferable treatment when the X-Box comes out. Remember, Microsoft will be the central authority for the X-box, as they have the right to issue an license for a game or not (unlike Windows). How does waiting two weeks for a X-box license sound, instead of waiting four months like the OpenGL-supporting id Software?
What this means is that you, as a gamer who wants to see games ported to Linux, should boycott game companies like Epic, who are departing platforms like the Mac and Linux for the greener pasture that is the X-Box. E-mail the developers at Epic that you refuse to dual-boot to Windows just to run their games, and that you will only choose games from developers that value the "right thing" over greed.
Go get your free Palm V (25 referrals needed only!)
No shit, as if I was'nt aware of the meaning of the acronym ... however, AFAIK, it actually *emulates* Direct3D by translating its API to OpenGL .. so there you go ...
It is obvious that Tim doesn't properly seperate between specifying
APIs and ABIs on one hand and a specific implementation on the other.
The TCP/IP stack example shows this: To end the DOS/early-Windows
chaos, people should have agreed (or forced to) APIs and ABIs, it
wouldn't be required to use one single implementation.
However, in several ways D3D as an API does what Game programmers want
where OpenGL does not. For example, it has better control over
texture loading, which is important for games that try to be more
beautiful and/or more outdoor - oriented than Quake. The step from
Glide to OpenGL/D3D initially widened the speed gap between Quake and
games like Unreal, Starsiege Tribes etc, mostly because texture
loading was suboptimal and couldn't be controlled/tuned as in Glide.
Microsoft quickly extends D3D in ways the game programmers want, while
the OpenGL consortium moves much slower and while moving it has to
weigth the concerns of "serious" (non-game) 3D applications as well.
There are some more far-sighted programmers like Carmack and Chris
Hecker who think (my interpretation) that using a single-vendor API
will cause more trouble in the long term than is worth the quick
improvements now, but few people enjoy the luxury of allowed to be
stubborn.
Sweeney has to position his product relative to Quake, he needs to do
some things better than Quake and (engine-wise) he lost ground while
moving from Unreal vs. Q2 to UT vs. Q3A. OpenGL needs a lot of
"right" tuning by the vendor and Quake is often used as the benchmark.
It is obvious that Sweeney *needs* the better control features of D3D
to get a product that is different from the new id engine while still
performing well.
I'd like to make clear that I'm absolutely on the OpenGL side here,
I'm just trying to point out that Sweeney isn't necessarily evil
(although his post about the MS splitup is rather stupid IMHO and I
can't agree with most of his programming language observations
either).
Martin
But the problem is, if Janet Reno and Co. get their way, programmers won't have the power to make that decision anymore -- the government will.
Where on this Earth did you get that from? Have you been watching too many "X-Files" shows?
The government is not proposing, nor are they allowed to, dictate what programmers have the power to include in anything. If you honestly think that, I think you should log off, shutdown your workstation, and step outside. Notice the lack of flying saucers and KGB patrols. Once reality has returned, please re-join the discussion.
What the DoJ is proposing is that a single company -- one Microsoft Corporation, in Redmond, Washington -- be broken up into two or more seperate companies, as punishment for illegally using their monopoly power to stifle competition, and to help prevent it from happening again.
No more, no less. It will not affect what other companies can do. It will not affect what other programmers can do. It won't even affect what the new "Baby Bills" can do. It will simply split the companies and prevent then from working together.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
AFAIK, there is no intention to pull OpenUT or any of the source code. In fact Brendon posted to the OpenUT devel list that he was going to release the new UT 413 headers directly after E3 so we can start developing again.
Also note that Epic has done fairly little development for the Linux port, but rather released enough of the source code to allow the OpenUT group to get the engine running. Since the source release, the code has been ported to SDL for window handling, I/O, and OpenGL, and there is currently heavy development on the sound code, with, with the exception of 3d audio, is already on a par with the windows version.
But there are three things that that gives me much hope for the future with Unreal and Linux:
1) Daniel Volgel, one of the main programmers on OpenUT (probably would be considered the 'lead' programmer) started working for Loki about a week ago. He has a pretty good working relationship with Brandon Reinhart and I would imagine that there would be a dialog between Loki and Epic.
2) AFAIK, the playstation uses OpenGL as it's primary graphics API, and Linux as it's development platform. Heck, I KNOW that Brandon has been doing the UT port on a Linux box. How can you ONLY support D3D and still port to the playstation in a reasonable fashion.
3) It's a long way from here to a new Unreal Engine. Lots of times, and there is lots of time to change their mind.
Anyway, that's my 2 cents. I've enjoyed hacking on the OpenUT code, and will continue to. And EPIC has done the Linux community a great service in releasing parts of the UT engine source, which can be a great learning experience on how a game engine is written.
OpenUT is very playable on many systems, and this will only improve as the state of accelerated OpenGL (via DRI or GLX) on Linux improves.
jf
Hell, all the linux zealots are a bunch of hypocrites anyway - all y'all have Win98 on your machines for games. So basically, your ethics can be bought for a video game. Ha.
I don't have Windows anywhere -- five desktop boxes at home, desktop at work and a laptop, all run Linux and FreeBSD (one of desktops is a powermac 8100/80 -- it also runs MacOS as a bootloader for mkLinux). And, yes, I have bought UT, and I am absolutely sure, some Epic bean-counter counted it as a sold Windows version, even though I run it on my Linux box.
Contrary to the popular belief, there indeed is no God.
You should wait patiently. It took 5 minutes to render, but it rendered finally (I tried it on NT, sorry if it doesn't apply to linux version)
Szo
Red Leader Standing By!
emulator is, namely, that which emulates (tries to act like, but is not) an origial product.
So the second system to implement an API is the emulator? All X11 servers but the first implementation (incl. XF86) are emulators, right? And all Java VMs other than the first are emulators, right? And the GNU system is a UNIX® system emulator, right? Microsoft IIS is an NCSA-httpd (now Apache Server) emulator?
Will I retire or break 10K?
So it surprises me that there is all that talk about dropping other platform support, especially after just committing to PS 2, as i doubt that it's going to have a port of Direct X.
Both Tim and Brandon's comments taken together look a little strange and may support rumors of dropping cross-platform support. But it's far from a clear cut statement that they will. BluesNews only reported that Brandon claimed it would be more difficult to port to Mac and Linux, not that it wouldn't be done. After all porting to PS 2 won't be any easier and it's definitely going forward.
Let's hope those platforms don't become victims of insignificant revenues, just after the Unreal engine is gaining respect in a market where only John Carmack stood out as a programmer more interested in better technology than revenues.
--ether
Not long ago, Sweeney had a post on the unreal tech page where he ranted and ranted about how great D3D and Microsoft tools are.
Another time, he had some none-too-favourable comments about OpenGL, claiming that Carmack was the only one who could 'afford' to take an ideological stand.
D3D is an ugly, non-standard uni-platform hairball. In every instance, D3D games look worse than OpenGL or even Glide games. And god help you if you're a programmer...just look at the case of Ultima IX. Origin originally wrote the engine for Glide and very quickly found out that D3D just could not DO what Glide did (at least, not without a LOT of pain). In the end the D3D performance was very much below Glide's performance.
So, if Sweeney wants to support D3D only, he's really going against the tide. The era of Windows '95/98 'only' is OVER. Ignore the seachange at your own risk.
One of the most common reasons to dual boot Linux is to run Windows to play games.
True. However, he's referring to hardcore gamers, who are more likely to be using dedicated gaming consoles (i.e. Sony Playstation, Nintendo, etc.) than either Windows or Linux.
There isn't a single game that runs better anywhere except on Windows. Get real! Windows runs games better. Period.
This is a load of absolute crap. Games written for Windows run better under Windows. Big surprise. Games written for Linux run better under Linux. The same is true of most games written for any particular platform: they will generally run best on their target platform.
As for what software and hardware combination runs games the best, neither Linux, nor Windows, nor Macintosh, nor any other generalized platform does it as well or as cheaply as dedicated gaming consoles. Not even your beloved Windows.
The Future of Human Evolution: Autonomy
The various X11 implementations are NOT emulators, since their purpose, their only purpose it to implement the X11 protocol itself. Berlin, AFAIK aims at EMULATING X11: because its main purpose is not to implement X11, it will implement X11 on top of another API. That's emulation. WINE, however, allows to run Windows programs on Linux. Linux is not meant to be a Windows implementation. See the difference? WINE is Not A [CPU/Machine Code/Virtual Machine] Emulator. It runs things natively, yes. That
these problems (eg, assumptions of 100% CPU access) are present in the API as well
Sorry, but you're right. Allegro was originally written for DOS. As such, it didn't get sleeping routines until 3.9.32, it displays the mouse cursor as a sprite in the game window, and it draws all graphics by blitting from an internal framebuffer to the X11 screen. But it also runs on framebuffer-console (fbcon), and many of the problems you experienced are gone. (If you care about cpu usage, why are you running an Allegro game on the server anyway?)
But it's still beta. Try Allegro 3.9.32 (from the Work in Progress page); it's quite stable now.
Will I retire or break 10K?
In other words, Mesa is to OpenGL as GNU is to UNIX.
Will I retire or break 10K?
Actually, if these were standardized on hardware, then the API would never evolve. No cubic environment mapping for you!
This is why decent standards include standardized way to extend them.
Contrary to the popular belief, there indeed is no God.
The problem here is again, a different stack tere, a different browser here, a different protocol there, a different compression scheme here, a different xml engine there, a different ipsec here, and you get the point.
And this is why standards are what should be followed. Not Microsoft's "Here is our proprietary solution that locks you into our platform" APIs, but standards. Like POSIX, like HTML, like CSS, like XML. If you followed the standard you will be okay.
It is when vendors like Microsoft decide to "enhance" the standard with extensions designed to lock out competition that things break down. Microsoft is an illegal monopoly, and something needs to be done to stop their abuse of that power, or the future of the information age will be owned by a single company.
Microsoft is an illegal monopoly, and something needs to be done to stop their abuse of that power, or the future of the information age will be owned by a single company.
I don't think breaking up MSFT is the best solution possible, but it may be the best solution possible under US law. I would rather be inconvenienced then enslaved.
What would my ideal solution be?
First, behavioral restrictions: Force Microsoft to publish complete specifications for all of their interfaces and file formats, and allow unlimited third-part re-implementation of them. If they cannot provide a spec, they cannot sell the product.
This would keep Microsoft from using their products to lock people into their products. People would be free to choose Windows, Exchange, IIS, IE, or what-have-you if that was the best product available. But if MS tries anything funny, people would be free to switch vendors.
Prohibit Microsoft from entering into exclusive licensing agreements with PC OEMs. This is something that is technically already done, but MS has found loop holes. Close them.
Next, some punitive and corrective measures. MSFT has broken the law and deserves to be punished; they also have locked out their competition in many markets and can continue that lock-out legally. So:
Prohibit bundling any other MS product with Windows for the next five years. No Windows Media Player. No MS-Works or MS-Office pre-loads. Force a choice on people, as MS has forced the lack of a choice on them for so many years.
Force MS to include freely available third-party browsers in the Windows OS package along with IE, and give users the choice of which they want to use. They've used their OS monopoly to build a browser monopoly; correct that.
But again, I don't know if any of this is possible or feasible, and I would rather be inconvenienced then enslaved.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
The problem for gamez writers is real. The fundamental problem with peecee gaming is that gamez, to get the performance gamerz want today, need to get very close to the hardware. Unfortunately, this is exactly the type of thing that good operating systems both prevent and facilitate: arbitrary random physical access to hardware devices is out of the question, but there exists one prescribed method of gaining the access you need, which offers protection from at least most mistakes. DirectAnything is hamstrung by two problems: 1) It fails to provide any real protection, and has been designed and implemented in the same slipshod way as the rest of windows, 2) It requires hardware support which is anything but universal.
So it's understandable that gamez manufacturers like targetting the consoles - it's a single known environment (as is pointed out in the article) which is generally rock solid internally and offers very direct hardware access, making high performance easy to get. Naturally, the lack of protection is problematic, but people have been writing hardware gamez since Pong - it's a science by now.
I would argue that, once completely implemented, the new DRI/DRM XFree implementation will be infinitely preferable to Microsoft targets for gamez developers. Why? Performance (with the right hardware), universal availability, and uniformity. In other words, you won't _need_ a FuxorGraphics model 455CA specifically; anything will work, though naturally if you want good performance you'll want something that can do hardware GL. GL is not itself without problems, but at least it's widely available. And with a fast enough CPU, software rendering is not out of the question (in fact, some SGI systems were set up specifically to do most of the rendering on the CPU. This is not altogether a bad thing; the 3D performance on those systems does not suck, to put it mildly).
Whether this ever happens, and whether it's ever adopted, remain to be seen. But even if all of his worst fears are realized, and DRI never gets completed in any sane fashion, it's not the end of the world. The worst doomsday scenario he comes up with is the death of the peecee. Would it be so bad to kiss the relic of the 70's, never designed but patched together by marketing types and marginal hackers from day one, unstable, unreliable, and nonuniform, a final goodbye? I'd like nothing better than the death of the peecee. Good riddance. Tragically, though, this fear is massively overblown: the peecee's existence relies on buyer ignorance and gullibility, of which there seem to be no shortage.
So, it seems while you tried to list 7 platforms, you really listed 3 that are so similar that you don't need DirectX to be portable.
Got HTML? Want LaTeX? Try html2latex
Wine Is Not an Emulator. It replaces windows libraries, it doesn't emulate.
Oh, please.
emulate: 3. Computer science: To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
Wine emulates the Windows binary interface. Funny names aside, Wine very much is an emulator.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Kenn Cobb (also from Westlake) had this to say:
So, while it may not be a great situation, atleast Mac users won't be shut out entirely. Westlake knows what's up...
-doenermord
saw this on Blue's News:
"one of the reasons for this is the fact that they have direct input to Microsoft as to the development of the API"
I could see microsoft being forced to allow its applications to run/be developed for OTHER platforms, but making win98/win2000 and future versions be broke up to replaceable components is DUMB. And that will cause problems.
Problems. Even with MS's driver certification program there are still problems with video drivers (a component) and sound drivers (another component). What if MS bought 3dfx, nVidia, and Creative? Don't you think there would be fewer problems? I think there would be fewer. I think the quality of first release drivers would go up substantially. Do you think that scenerio would be a good thing?
What if Microsoft bought every company or division of a company that made anything at all for the PC market? That would bring them to a console-like level of control (or better) over the PC market. That level of control is proven to generate very high quality, high reliability stuff. Do you think this scenerio would be a good thing?
What if we turned the knob the other way? Dozens of Baby Bill Co.'s each write their own tiny fraction. Baby Bill Co. #34 writes the code for the IDirect3DLight interface, Baby Bill Co. #35 writes the code for IDirect3DExecuteBuffer, Baby Bill Co. #36 writes..., etc. Would that be a good thing?
My opinion is that the answers to the STRONG questions are no, no, and no.
Microsoft has demonstrated (Java) and continues to demonstrate (Kerberos) that the price for allowing them bring standards and interoperability to the PC market is strict Microsoft control over implementations of said standards. One of the primary sources of Microsoft's desire to innovate is the desire to "de-commoditize" standards (Halloween docs). So, I think it is fair to say that the more control MS gains, the less they will motivated to innovate. And so I think it is appropriate for the knob to be turned down a notch or two on Microsoft.
Dealing with variations in standard implementations and getting people to play nice together, insofar as standard implementations go, IS a problem, but Microsoft domination and lock-down of those standards is not the answer.
I must say I find it difficult do disagree with him on this. In the early days of D3D there was heavy contention between OpenGL and D3D, I myself was very vocal on the side of OpenGL. OpenGL has barely moved forward in the intervening years whereas D3D has developed at an alarming rate. OpenGL support for the full range of features available on different graphics cards is limited at best whereas D3D has done a pretty good job of keeping up (although there are some nasty sides to the yearly release of the API).
Now I know I'm going to get flamed for saying anything pro a Microsoft api, and the first comment is going to be 'But Id software don't have a problem'. The largest benefit with openGL is that the specification defines exactly how every thing gets done, if the hardware can't do something it gets done in software, this unfortunately is also it's down falling. ID software don't have a problem, whenever they are about to release a big-name title all the card vendors run around making sure there drivers are optimally configured for the feature set ID is using. If you're a smaller developer, things work differently, the vendors are not as concerned with you and basically you have to limit yourself to using the features that the big-boys have already used. With D3D the situation is different, you are no longer shielded from the differences between cards but this can be used to your advantage, using once set of optimal features to achieve an affect on one card and another set on another (or a simpler effect).
The ironic situation here is that (Microsoft proprietary) D3D API is providing the smaller developer with a far more free development platform than the open OpenGL.
Oh, please.
First of all, don't jump to the conclusion that games written for Linux are necessarily going to be better performers, either where netplay or graphics are concerned. Most graphics cards these days have better OOTB support for Windows, hands down. All things being equal, that translates to better performing games. And where netplay is concerned, that varies highly from game to game. Compare Unreal's unpatched netplay to the latest patchlevel, or to UT's. Compare either to Q3. On the same hardware, with the same OS.
Second, don't be ridiculous about "refusing to allow Linux ports." Companies like Loki don't politely knock on the doors of game companies and go, "Hey there, mind if we port your game for you? We'll only be a minute." Loki gets paid to do it. That's fine - they provide a service to their customers and they deserve the right to charge for it. But the folks at Blizzard aren't being evil because they don't feel like paying for a Linux port of the game.
If Loki can show that they can sell enough copies of a game for Linux, Blizzard will likely change their minds. Until then, don't have a hissyfit at Blizzard for looking out for their bottom line. This may come as a shock to you, but Blizzard, Loki, and the publishers of every game you're likley to find at the local Best Buy are, in fact, in it for the money.
Have you EVER tried mixing thise "clone" pc's you talk about? Have you ever seen the inside of a COMPAQ? They're not a clone. You can't replace the motherboard on 99% of them because they're proprietary. DO YOUR HOMEWORK before you preach to me about CLONES and this and that.
a COMPUTER is not defined as a PC CLONE, where in the world is that misnomer coming from?
I don't think SUN calls there workstations PC's and IBM had nothing to do with there creation, the market demanded a workstation and sun provided. Sure the 'clone' market exploded, but it exploded around a common software packag called DOS and then Windows and Then whatever it is today. ITs because people chose DOS and chose windows and chose whatever they want to run.
Please, get your head out of your ass and look around. Standards are just one group or one persons concept of anything. Microsoft has Microsoft Standards and maybe YOU don't agree with it, but don't give me the shpeel on how having 2000 variants can be anything good for the industry.
Should we sue telephone companies because we can't run our own protocols or signals on the network? Should we sue cable companies because they choose what we get to watch? Should we sue cars because they put the stereo to high or two low? The world would be boring if evertthing was standardized.
Innovation is NOT conformity people
IF you claim that opengl is better, then please give some examples. All I know is that under Unreal tournment, directx is faster on my geforce 256.
Out of that whole message, this was the only thing I could even comprehend, so I'll address it. OpenGL is better for people who want a portable, robust API, that doesn't change every six months. It's not the only API out there, and it may not be the best for everyone.
And I repeat, there is nothing about an API that would make one faster or slower than another. An API is just a specification.
If a game is faster in D3D than in OpenGL on the same hardware, then this is almost always due to the fact that the game did not make better use of the OpenGL API, and has nothing to do with the illusion that one API is faster than another.
The definition of "emulator" has a slippery slope: NES virtual machines emulate the NES binary interface. Java virtual machines emulate the Java binary interface. Linux emulates the UNIX® source interface (most of POSIX® and much of the Single UNIX Spec). XFree86 "emulates" the X11 source interface. GTK+ emulates the GTK+ source interface. So you're saying an emulator is any program that exposes APIs, that all libraries are emulators?
Will I retire or break 10K?
There's a portable wrapper around much of DirectX. It's called Allegro. It supports nearly everything popular that runs on x86 (DOS, Windows, GNU/Linux, BeOS) and other hardware (the X11 version supports linux-ppc, Slolaris, HockeyPUX, AIX and Pains, etc.) but does not support Mac OS because none of the developers has a Mac to code on. And there are lots of games written for Allegro, including all of mine.
Will I retire or break 10K?
It's called Windows CE, and it powers some Sega Dreamcast games (mostly PC ports) and will power most Xbox games.
Will I retire or break 10K?
For those of us who don't follow this sort of thing, wine already does a fair chunk of DirectX, including Direct3d. If you want to play Windows games, go help wine.
"Please don't sigh like that, maam"
Microsoft fixed that with Windows 95's built-in TCP/IP.
The government's proposal would basically shackle Microsoft and prevent them from adding new features of that sort to the OS
(on that networking was bad under DOS but works fine on Win95+)
Breaking up Microsoft into one OS vendor and one Applications company won't prevent Microsoft from adding stuff like TCP/IP or DirectX to it's OS! They're OS components, I don't think anyone would claim they're applications in the normal thoughts of the user (or the DOJ, surely).
Linux and Mac will have to push OpenGL over DirectX - I'd say that's quite reasonable. At least it's not as bad as Glide ...
it's in my head
Although this is an obvious troll, I'd still like to address these points, because a lot of people posting here seem to be clueless on some of these issues:
We are not talking about D3D 3.0 anymore. 7.0 is here, and its not your mother's pansy-ass D3D anymore. It's as fast as OpenGL, and blows it away in features and power.
This sounds more like market-speak than any kind of statement based in fact. Can you provide some examples of how an API can be fast and/or powerful?
OpenGL used to be safe in the knowledge, that as much support as D3D could get, it was still king in terms of features. Not anymore. These days there are a host of features that the D3D programmer has direct access to, but is not directly accessible from the OpenGL API.
Tell you what... For every "feature" you can find that cannot be implemented as an OpenGL extension, I'll list one that isn't in D3D... Go on, I'm waiting...
OpenGL is does not have the speed advantage anymore.
Well there goes all your credibility. Please explain again, how an API can be faster or slower than another one. An API is just an interface. Some vendors' implementations may differ in speed, but there is nothing about the API that specifies a speed difference.
The OpenGL API is not powerful enough. It does not give you enough low-level access.
You're programming down to the vertex on both API's. How much lower do you want to go, and still be able to run on all hardware?
OpenGL is not extenible. Sure there are OpenGL extensions, but they are silly compared to the ones in D3D.
They're silly... Another statement based in fact I see...
Yea thats right everyone.. Just a troll.. move along.. nothing to see here..
It's clear both API's will be around for a while, so why not learn to live with them both?
Only the most hard-core pundits are going to make this out to be some kind of war between API's. They both have their advantages and disadvantages--and as programmers, we can choose which one suits our needs best.
Those who want a portable and robust API will choose OpenGL, and those who want to be able to run with the latest hardware and take advantage of Windows-only features, can choose D3D.
They both have their drawbacks too. It's unfortunate that OpenGL's review process takes so long to specify new features, just as it is unfortunate that D3D changes with each version at MS's whim. As a programmer you just have to decide which drawbacks you can live with.
I'd really like to see what Tim's opinion would be if MS decided to release a 3d game engine with Windows as one of the people in the forum said. Let's see if he is as sympathetic to MS's cause when it is his company on the line.
Oh, and if DirectX is such a superior gaming platform then what about Unreal Tourney for Linux and Mac? Maybe I'm just a conspiracy theorist, but it seems as though maybe Bill has thrown a little money Tim's way to cause a complete 180 in the company's direction, no?
So the second system to implement an API is the emulator?
Are you being obtuse on purpose, or were you born that way? Read what I flippin' wrote.
All X11 servers but the first implementation (incl. XF86) are emulators, right?
X11 servers are generally implementing the X11 protocol standard, not trying to act like the original X server implementation. In fact, many of them -- including XFree -- use the same code.
And all Java VMs other than the first are emulators, right?
I suppose that depends on Java's status this week -- is it a standard, or a product owned by Sun?
And the GNU system is a UNIX® system emulator, right?
That was how it started, after all. RMS wanted a Unix system without the Unix license problems.
Microsoft IIS is an NCSA-httpd (now Apache Server) emulator?
Well, I can't speak for Microsoft. Are they trying to be NCSA HTTPD all over again, or are they trying to implement the HTTP standard? (Or, more likely in MSFT's case, embrace and extend the standard?)
If a project is trying to implement a standard, then I wouldn't call that an emulation. They are starting from scratch and creating something that meets an abstract specification.
But, if a project sets out with the goal of implementing something which acts just like another product, then they are building an emulator, by definition. Emuate means "act like".
Is that clear enough for you, or do I need diagrams?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Of course MS is going to give game developers more input into their API. With the release of the xbox MS is going to court as many game developers as possible. But just wait a year or so down the road when these developers have abandoned all other platforms and are dependant on MS they will stick them with outrageous licensing fees or make them somehow pay through the nose to use d3d just like they've done so many times before.
I experience serious video problems with WINE
After three or four bottles things are really out of focus
134340: I am not a number. I am a free planet!
D3D's not very good on WINE yet (it's only around DX3 level), but OpenGL support is in current CVS now (look for it in the next release). If you have a XFree86 4.0 supported OpenGL card it plays Half-Life in OpenGL mode (quite fast on my TNT2 even). Gaming on Linux is gonna get even more interesting as we go I think :)
Mesa cannot legally call itself an implementation of OpenGL, because it has not taken SGI's hideously expensive testing process. Pretty much everyone agrees that it's "close enough" (even SGI) so this is more a semantic point than anything else. But stupid as it is, that's enough to scare away some businesses.
They still seem like a Linux friendly company ( Epic, NOT GT Games). Hopefully Loki could work with Epic to port games like they already did with the D3D only Heavy Gear II (excellent port to opengl) and like they did with Quake3 for id. I have purchased two copies of UT and like it very much. If Epic is listening, then please don't cut off the Linux community. We do play and pay for your games.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
Although this is an obvious troll, I'd still like to address these points, because a lot of people posting here seem to be clueless on some of these issues:
>>
Nope, not trolling.
This sounds more like market-speak than any kind of statement based in fact. Can you provide some examples of how an API can be fast and/or powerful?
>> I was just trying to be poetic. Geez, nerds. APIs can be faster or slower than others based on how effectivly it allows access to hardware and how effectivly it manages resources. Take early versions of Direct3D. They were the reason that D3D got a bad name. An engine implemented in D3D and equally optimized as one implemented in OpenGL would lose very significantly in the D3D case. Back around D3D 3 or 5, a glide or OpenGL game would run upwards of 40% faster than the same engine using a D3D renderer. In current implementations, however, the pipeline has been streamlined, the whole thing has been nearly rewritten, and provides much better access to hardware.
Tell you what... For every "feature" you can find that cannot be implemented as an OpenGL extension, I'll list one that isn't in D3D... Go on, I'm waiting...
>>>>>>>>>>
Did you not read my entire post before answering? I say that extensions suck. They are not evenly implemented and the developer has to be constantly aware of which ones he is using. I can easily (relativly) write an engine that uses every features in D3D. Now no matter what graphics card I'm using, my app will run, with D3D smoothing over hardware differences. In OpenGL, I have to use extensions, and for a lot of the cutting edge features (like the ones that nvidia is exposing as OpenGL extensions) are not ARB or EXT extensions, and in that case I have to write seperate code for each card I want to support. Eg. If I use the skinning support in DirectX 8.0, my game will automatically take advantage of both the GeForce 2 and the Radeon. In OpenGL, I would have to use both the NV skinning extension and the ATI skinning extension. Do you think the ARB is going to be able to keep up with a market where major hardware changes happen in 6 months? Hell no.
OpenGL is does not have the speed advantage anymore.
Well there goes all your credibility. Please explain again, how an API can be faster or slower than another one. An API is just an interface. Some vendors' implementations may differ in speed, but there is nothing about the API that specifies a speed difference.
>>>>>>>>>
API's can be fast or slow. Have you ever implemented an API before? Take hypothetical API X and Y. To change the color in X, I have to create a color object, register it with the server, then activate the color change. In Y, I send three color components to activate the color change. Which do you think will be faster?
You're programming down to the vertex on both API's. How much lower do you want to go, and still be able to run on all hardware?
>>>>>>>>
That's not my point. The vertex level is entirly irrelevant to what I'm talking about. In OpenGL, you have an abstract access to color, depth, etc buffers, vertex buffers, and hardware resources. In D3D, you have direct access to these. You can create hardware buffers, vertex buffers, etc. Hell, you even have direct access to what textures are uploaded to the card! None of this glPrioritizeTextures crap. Case in point, in D3D, you can render directly to a secondary hardware buffer, let's see OpenGL do that!
They're silly... Another statement based in fact I see...
>>>
Did you bother to read the last half of the post??!!! I go through point by point on why GL extensions are silly! They aren't implemented fast enough to keep pace with the evolution of consumer hardware, and they aren't implemented evenly/they aren't emulated when not implemented.
A deep unwavering belief is a sure sign you're missing something...
Wine seems to emulate Direct3D quite OK -- AFAIK, Unreal (not Tournament) for Windows runs on it in Direct3D mode. I guess it should be quite possible to link future Unreal games to WineLib.
The basis of the government's case (at least part of it) is that, in their opinion, a web browser cannot be part of an OS.
That's just plain wrong.
The basis of the government's case is that, according to US law, a monopoly cannot use their monopoly power to further their own products. It doesn't matter what Microsoft is trying to bundle with Windows; what matters is the fact that they are a monopoly. If you are a monopoly, you have to tread carefully, or your monopoly will be taken away -- forcefully. That's the law, and for good reason.
Why is that so hard for people to understand?
I'm glossing over the legal issues, partly because they're complicated and partly because I don't know them all, but please accept my rough interpretation of the case.
I am sorry, but I cannot accept an interpretation that is fundamentally flawed.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Berlin, AFAIK aims at EMULATING X11: because its main purpose is not to implement X11, it will implement X11 on top of another API. That's emulation.
Personally, I wouldn't call that an emulation, per se. I would call it a X server implemented for the Berlin platform (similar to the XFree port for OS/2). But that is starting to split hairs; if you want to call Berlin's X support "emulation", I won't argue with you.
WINE, however, allows to run Windows programs on Linux. Linux is not meant to be a Windows implementation.
True, but I never claimed that Wine made Linux a Windows emulator; I claimed Wine itself is a Windows emulator.
WINE is Not A [CPU/Machine Code/Virtual Machine] Emulator.
But it is an OS emulator.
BTW, "Wine" originally stood for "Windows Emulator". The change to the recursive acronym came later. I suspect the reasons were:
Emulating -- acting like -- Windows could be interpreted to mean crashing a lot, and they wanted to avoid that.
A lot of people seem to think that "Windows Emulator" also means "i386 Emulator", which Wine most explicitly is not.
Recursive acronyms are fun.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Yep, you heard it here first. OpenGL is losing the 3D API war to Direct3D. Heresy, you say, but hear me out.
A) We are not talking about D3D 3.0 anymore. 7.0 is here, and its not your mother's pansy-ass D3D anymore. It's as fast as OpenGL, and blows it away in features and power.
B) OpenGL used to be safe in the knowledge, that as much support as D3D could get, it was still king in terms of features. Not anymore. These days there are a host of features that the D3D programmer has direct access to, but is not directly accessible from the OpenGL API.
C) OpenGL is does not have the speed advantage anymore. D3D has evolved to the point where it is just as fast as OpenGL, if not faster (depending ont he OpenGL ICD being used.)
There are many reasons why OpenGL is falling behind, but I'll highlight the main ones.
1) The OpenGL API is not powerful enough. It does not give you enough low-level access. When I first learned OpenGL, I was shocked to see that I had no control of hardware resources. I was used to DirectX and allocating and deallocating hardware buffers left and right. Nope, OpenGL didn't let me have any fun with that stuff. Even more shocking was that it had no concept of a vertex buffer. Sure, it would let you use the glVertexPtr command to select an array, but graphcis cards cannot optimize that properly because the data can change between calls to glVertexPtr. D3D offerers a host of low level features dealing with buffers and the like to allow you to wring as much performance as possible out of the hardware.
2) OpenGL is not extenible. Sure there are OpenGL extensions, but they are silly compared to the ones in D3D. There are many problems with extensions... First, they take forever to pass as an ARB or EXT extensions. Second, even then they are not implemented on all ICDs. Take a look at the MS software renderer. No compiled vertex arrays or multitexturing for you. Third, they are not emulated when they are not implemented. You have to have seperate code paths for each combination of extensions you may require. In D3D, I can turn on a new feature confident in the fact that if the feature is not supported in hardware, it will be emulated. Eventually, all hardware will accelerate the feature and my app will automatically take advantage of it. No such thing for GL apps. The extension problem is going to reach a watershed as the new graphics accelerators come out with all these hardware features. Take the new accelerators that accelerate skinning or keyframing. MS will just make a keyframer COM object, and you can use the functions in that. If hardware accelerated keyframing is not available, then it will be emulated by D3D. In OpenGL, get ready for glKeyFramerATI and glKeyFramerNV and glKeyFramerS3, ad nauseum, or not glKeyFramer at all! Then you have more extensions for stuff liek texture compression. In D3D just, set call some functions in the texture object.
Despite all this, I still use OpenGL. Why? Because though I prefer the COM-based approach of D3D, and I like the low level control, and I like advanced rendering features, I hate windows, and I like BeOS. All that BeOS (and Linux, and QNX, etc) supports is OpenGL. I think that OpenGL needs a major overhaul in version 2. OpenML is coming out to compete with the rest of DirectX, but can OpenGL be updated to compete with Direct3D? The shoe is on the other foot now.
A deep unwavering belief is a sure sign you're missing something...
I've been picking up a little bit of OpenGL, and it seems to me to be an exceedingly well-thought-out, clean, and consistent API. Certainly better than the small amount of Win16/32, and the rather larger amount of DOS, programming I did. Admittedly, I haven't done any DirectX programming; maybe Microsoft has designed an uncharacteristically decent interface, but anyway:
What is wrong with GL?
Daniel
Hurry up and jump on the individualist bandwagon!
Ok, I agree with that...lots of different people can lead to compatiblity problems. This doesn't mean that they can't be overcome, but problems can and do occur. But then...
Jigga-What?!? Ok, this is were he losses me. First, isn't MS in trouble for exactly that...forcing software makers to do things that MS wanted them to do? What about choosing standards based on technical merit...you know, robustness, interoperability, that sort of thing...instead of standards based on their ability to tie developers to a single platform?
What ever happened to Open Standards? You know, like the ones used to build the Internet and make email work? Again, I'm no expert, but they seem to work pretty well. Don't look now, but your soaking in them! I realize some of the Open Standards may not have developed as quickly or as well as some of the MS 'standards', but how much of that was due to MS marketing muscle?
I'm not trying to bash MS or Tim Sweeney, but I don't know that dominating a market can be compared to 'setting standards'. If there's something I'm overlooking, someone please fill me in.
So you're saying an emulator is any program that exposes APIs, that all libraries are emulators?
No, I'm not, and that should be obvious. Check my previous post, and you'll see the formal definition of what I'm saying an emulator is, namely, that which emulates (tries to act like, but is not) an origial product.
Don't be obtuse.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Isn't Linux a matter of choice ?
I can't see why a Linux implementation of OpenGL/ Direct3D/Glide/Grits3D or any other 3D API I can think of would hurt anyone.
If Linux's creed was unification, it would hurt, but Linux is about choice. So if you think OpenGL is the best 3D API, it's OK. But it's OK if some folks decide to implement Direct3D too (and they do !), it's OK too.
Stéphane
Instant Karma's gonna get you, Gonna knock you right on the head (John Lennon, 1970)
Hence the misspeeling. Ditto for the word "peecee."
I agree. DRI is just appearing, and OpenGL on DRI should privide excellent performance.
3dfx VooDoo 5 6000 just BLOWS AWAY nVidia GeForce 2 according to early sightings, while Celeron II benchmarks shows that Intels decision to deliberately keep the 66MHz bus to slow it down was very effective!
So much for X-Box performance! A 600MHz PIII derived processor (i.e. Celeron II) and nVidia are already looking outdated before the box is even introduced!
VooDoo 5 6000 vs GeForce 2
Celeron II benchmarks