And where was Direct3D at this time? Was Direct3D even usable? Again, why re-invent the wheel with Direct3D when OpenGL was available?
>>>>
I think you're relying too much on hindsight. I don't think that OpenGL was even an option at the time. GL was a heavyweight API that ran on heavyweight hardware and required complex drivers. It just wasn't suited for gaming in the days of Virge. Also, OpenGL drivers were (and still are) very complex to develop. Even today, many vendors don't have stable OpenGL drivers. Thus, the chances of the consumer hardware market accepting GL were pretty small.
Ok, with this reasoning we can re-invent many APIs, and then when our new API after several years doesn't suck any longer compared to what was already available before, we can conclude that the effort was worth it because the older API "was" better...
What do we gain here?
>>>>>>>>>>>>
D3D and OpenGL, though they both do 3D, have two different paradigms. OpenGL is clean and abstract, while D3D is down and dirty. D3D was suited to the consumer level hardware of the time, and OpenGL was suited to the pro level hardware of the time. While it could be argued that both APIs have moved closer together (D3D has become more abstract because new hardware accelerates more parts of the pipeline, and OpenGL has started to expose more low-level functionality through extensions), there was no way anyone could have predicted how hardware would evolve.
I believe the conclusion was that it may have been a good choice for Sweeney, short term. But bad for the gaming community as a whole in the long run, due to fragmentation.
>>>>>
What fragmentation? Most people use Windows and most games use D3D! Where's this fragmentation you speak of? If some developers chose to use OpenGL, that's their option. It doesn't really hurt the consumer any. The underlying API is more or less invisible, unlike the disparity between, say, GNOME and KDE...
But that goes for all developers that chose Direct3D at the time. Besides, Unreal's Direct3D performance hasn't exactly been stellar throughout the history. Had more developers gone with OpenGL, hardware manufacturers would have focused on OpenGL instead of Direct3D. I believe it was an important breakpoint for the success of Direct3D when Epic chose it.
>>>>>>>>>..
While that is true to a certain extent, I belive that can't explain all of why D3D has been successful. Remember, Carmack's engine powers many of the 'A' titles out there, and that keeps OpenGL a force. I think hardware manufacturers just chose to go with D3D because it is easier for them to implement, and developers chose it because it had more stable (consumer-level) drivers and MS is more responsive to the needs of game developers than is the ARB.
Yes, gamers mostly run Windows/D3D, but I believe that fact was the issue up for debate and questioning? Windows users could run OpenGL without sacrificing any gaming experience.
>>>>>>>
Again, for the above reasons, this is not the case. When D3D was created, using OpenGL would have been a major sacrifice for gamers.
The OS market may be another issue, but the fact that Direct3D limits the choice of platform (and freedom of people), is highly related to this issue.
>>>>>>
Gamer's really don't care about freedom. They want their OS running stably (Win2K does this to a large degree) and their games running smoothly. Like communists, the OSS community doesn't always understand that politics is not the sole factor in everything.
Define compatible? I believe being cross-platform and being used for other stuff than gaming is being compatible....
>>>>>>>
Compatible in the practical sense. There are more gamers who own Matrox cards than gamers who run Linux. Being more comptible with Matrox's crappy GL drivers (ie. using their D3D drivers instead) is more important than being cross-platform.
How many vendors are there today...? I bet most people use Nvidia hardware and they have great OpenGL-drivers.
>>>>>>
And you'd be wrong. Although NVIDIA is #1 in sales, its going to take a lot before ATI's 22 million chips go out of circulation. Even S3, Matrox, and PowerVR are still a factor. These cards don't have good OpenGL drivers, but they are still a large part of the gaming market.
And I haven't heard that Direct3D has more features, taking OpenGL's modularity into account. Stick to the facts!
>>>>>>>>>
Take a look at an OpenGL 1.2 book, then take a look at a D3D book. There are tons of features in D3D that (if they appear at all) only appear as extensions to OpenGL. Since these extensions are often propriatory to particular vendors, it causes headaches to developers who have to deal with a fragmented API. MS thought of making a D3D extension mechanism to relive themselves of the burden of haivng to release new versions of D3D so often. Game developers were not keen on the idea, and blocked it from happening. Extensions are great for OpenGL's original market (slow evolving pro hardware), but aren't the right solution for a quickly changing consumer hadware market.
And read John Carmack's posting for his view on DirectX-releases if you believe OpenGL extensions are so bad...
>>>>>>
Actually, he points out that ATI and NVIDIA have diverged on the extensions point. Unless ATI and NVIDIA suddenly become the only forces in the graphics industry (a plausible, but undesirable scenario) this divergance will become worse. I don't really trust the good natures of the hardware developers to work together and adopt one another's extensions. The days of Glide, MeTaL, PowerSGL, and other propriatory APIs are still to fresh in my mind...
I have personally always questioned the existence of Direct3D (I am not talking about DirectX in general here), since I really can't find anything it has contributed to but fragmentation of API:s and drivers. I am not out to bash Microsoft here, but I really can't help to see how well Direct3D fits in with Microsft's known ability to use its power (and near monopoly) to crush the competition. Direct3D does not only hurt OpenGL, but also gaming on other platforms in general, thus forcing consumers to the one and only alternative... Anyone but me thinks Deja vu? Why didn't Microsoft simply develop a DirectX wrapper around OpenGL, like SDL? This would allow OpenGL to integrate transparently into the rest of the DirectX stuff and at the same time avoiding the introduction of a completely new redundant API.
>>>>>>>
The public has a short memory indeed. While MS no doubt uses Direct3D to compete with OpenGL, its not D3D's main reason for existance. D3D was created to keep Glide from becoming the de-facto Windows 3D API. MS had lost a lot to Apple when Quicktime became the major media format on Windows, and Bill wasn't having a competing propriatory API on his platform. OpenGL wasn't even an issue until Carmack decided to use it for GLQuake, and even then, it didn't become popular until NVIDIA introduced full-blown ICDs into the consumer market. Thus, your wrapper idea has two flaws. First, the whole point of DirectX in general is to remove as many abstractions as possible while still maintaining hardware independence. Wrapping around OpenGL (which significantly more abstract than D3D even today, and was much more so back when D3D was created) would have gone across the grain of the D3D API. Second, since OpenGL wasn't even a player in the consumer industry at the time, MS might as well have wrapped over Heidi for all the good it would do.
OpenGL works great (why else do the #1 3D-genius favor it),
>>>>
Carmack is the One True Game Creator (TM) now? He favors it because it didn't like the early versions of DirectX, and because it is cross platform. I haven't heard him say anything about its technical merits in a long time.
just look at the Quake-engine games and the upcoming Doom... OpenGL had this when Direct3D didn't even exist and was clearly the better API for a long time.
>>>
Keyword, "was."
It is robust, also cross-platform and not controlled by a gigantic "closed" company. So the choice should be a no-brainer, right?
>>>>>>>>
Not for Microsoft! Or have you changed the subject somewhere and I just missed it?
I believe the developers are to blame. Tim Sweeney once chose to replace the ageing proprietary Glide API in his Unreal engine. He decided (about the time of DirectX5) to go with Direct3D, citing better driver support. This is just such a bad argument... Direct3D drivers may have been better back then, but OpenGL support is today as good as Direct3D. OpenGL was back then already a mature, proven API. How would driver support be for OpenGL today if OpenGL was the only (or favored) API?? Just think about it....
>>>>>>>>>
I don't know how bad a decision it was for Sweeny. A lot of people will say that D3D is technically superior to OpenGL today, and 99% of UTs users are on Windows anyway, so I don't think he's lost much.
If developers really care for gamers they should do like John Carmack. He has put free effort into bringing his gaming experiences to as many people as possible, no matter what underlying platform they use, by contributing to the improvement of free OpenGL drivers himself (through the Utah-GLX project). His creations run on virtually every platform out there and they have always been on the bleeding edge. This prove that cross-platform gaming is possible, but only if the will is there and the right choices are made.
>>>>>>>
Let's get this straight. Gamers run Windows. Consumer D3D drivers, in general, are better than consumer OpenGL drivers. D3D is also more powerful, for game development anyway. If developers want to help gamers, they should use the API that runs their game best on the user's hardware. Right now, and for the forseeable future, that API is Direct3D. Now whether or not it is good for the OS market in general is another issue entirely.
So, my question to game developers is: Why choose Direct3D? It's not as if OpenGL won't run on Windows...
>>>>>>>>
Its more compatible. Only a few vendors have really good OpenGL drivers, even today. Its more powerful, since it has more default features. It is easier to support, since there are far less problems caused by buggy OpenGL drivers, and the extension mechanism (which developers detest by the way) isn't present in D3D.
I think you don't seem to understand the definition of a "restriction." The GPL might lead to freer code, but it does that by being more restrictive than the BSD license. Take a different example. As an employer, you can discriminate against people when hiring. This is more restrictive, but also leads to a freer society.
Well, the BSD licence forces you to release your code to the likes of microsoft who can take it, and use it for whatever they like, without merging the changes back.
>>>>>>>>>
Umm, if you license something under the BSD license, you implicitly OK that usage. Some people don't care if their code gets used in a closed commercial system, if it makes that system better for users. Are you saying that that's bad?
Great. Another article that as a lot of technical possibility, and all I hear are license considerations and politics. Anybody want to enlighten the rest of us as to why exactly this release is significant? Is the OpenUNIX kernel somehow better than the Linux kernel? At what things? What's the VM system look like? Real meaty stuff that nobody seems to talk about...
Re:Been running it for a week now, great release.
on
KDE 2.2 Released
·
· Score: 2
I shouldn't bother responding to this obnoxious and patronzing post, but screw it, you are a pretentious fuck.
>>>>>
God I love being me...
When I started using GCC, nowhere near 90% of GCC targets were for IA32. It could build for 68000, Sparc, PDP-20, etc. I remember hacking on the code generation for a summer job I had ages ago, since the ANSI C compliance was so good (for the time). That is why I said that the retargetable nature of GCC was always its "killer feature". Telling me to "deal" with the fact that 90% of targets NOW are intel, is an assinine retort.
>>>>>>>
I meant that right now, 90% (or some other big percentage) of people using GCC are running x86. That's just the simple truth of the world.
GCC 3.0 is a nice step forward, and perhaps compile speeds will improve in future releases. If that isn't good enough for you, spend the $400-$500 for Intel's compiler, you damn cheapskate. Meanwhile, I'll spend that money on a faster CPU, more RAM, a bigger disk, AND have money left over for good sushi.
>>>>>>>>
Hey, I never said it wouldn't get better. I'm just saying it really isn't that great. And aside from better complience, there is no real tangible improvements in 3.0, despite the extensive changes.
GCC is *good* for developers, since commercial compilers have to perform at least as well as GCC in order to expect any sales. So the non-free "competition" must not stand still to remain relevant. As of GCC 3.0, we have the makings of a very good baseline for C++ (and even C99, to some extent) support, and it will just get better. Deal with it yourself.
>>>>>>
Again, I never said that it wouldn't get better. I'm just saying, that at this point, commercial competitors such as icl have almost as good complience, much better speed, much better code generation, and are more developer friendly (icl has GREAT error messages). Sure GCC will get better, but it isn't that great yet.
Lost cause? The only remaining hope is that Palm does something with the BeOS code (like Open Source it!), cuz god knows BeIA has been BeOS's worst enemy...
Honestly, I can't think of a single good thing that could come out of this. Can you?
Wow. So that's what french crack does;) Anyway, I take offense to your statement that scientists don't appreciate beauty. Science is all about finding the underlying beauty in the world. As it has been said many times, Truth is Beauty. As for C++ programmers, I find a piece of code that uses hardware 99.9% efficiently to be beautiful. Meanwhile, Java's focus on rapid coding at the cost of efficiency seems merely utilitarian.
BeOS is not based on XINU (yea, I've heard that rumor too). XINU is an x86 OS that doesn't run in protected mode. BeOS is a microkernel that started on the AT&T Hobbit. Totally different beasts.
Umm, the UNIX API isn't garbage, the garbage is some of the stuff that has evolved around it.
As for POSIX complience, Windows 2000 (Cygwin) Linux, BeOS, AtheOS, Hurd, and MacOS X will run 99% of all (non-GUI) POSIX software out there. I'd say that that's pretty damn successful.
Re:Been running it for a week now, great release.
on
KDE 2.2 Released
·
· Score: 2
Would you trade speed of compilation for standards compliance?
>>>>>>>>>
Yes. Because I tend to stick very closely to "safe" code, which is always a good practice, no matter how standards complient your compiler. There is, of course, a balance, but GCC's balance point is in the wrong place.
That would be complete stupidity. GCC 3 is a godsend for C++ developers, and a firm base for future speed improvements.
>>>>>>>>>>
Well, let's see what shapes up. Of course, the competition isn't standing still either. IntelC++, for example, is very fast, makes great code, and is quite standard complient (not to the point of GCC, but very close). If only it didn't cost so damn much...
Besides, standards compliance is not GCC 3's only feature. It is also one of the most portable and retargetable compilers out there (perhaps THE most), which was always the main killer feature.
>>>>>>>>>
90% of the world runs x86, deal with it. Something useful to a very limited portion of the population cannot be billed as a "killer" feature. Maybe if GCC was billed as an embedded compiler, that would be true, but as a compiler for Linux/x86, that feature carries little weight.
I have no doubt that GCC will improve. Whether it will every be better than its competitors, however, is totally up in the air. As it stands, 3.0 is not much better than 2.95.3 in any respect other than standards complience. If 3.1+ changes this, then great. Otherwise, not so great.
Actually, corporate machines are unilaterally badly configured. MS Windows is very needy. For example, if you hose something, you can't just reinstall over the old installation, but you have to wipe the disk clean. You have to feed it the highest quality drivers and make sure not to run programs that can bother it (like AIM). If you follow the rules (not so hard in reality), clean you recyle bin regularly, and keep up on those updates, you too can be a happy Win2K user.
That would be silly. I want all developpers to have quad SMP machines with a Gig of RAM and 100 gigs disk. That way they can develop and compile and debug FASTER.
>>>>>>>>
BeOS was developed on 66MHz PPCs with 16MB of RAM and it shows. The damn thing runs like hell on mediocre machines, and even faster on faster ones.
It would be nice if they all had a small machine like you described on their network so that they could INSTALL their rapidly developped applications for TESTING. That might lead to some optimizations being done that don't happen now.
>>>>>>>>
Its not just optimizations. Its the whole mindset that features are more important than basic usability.
OTOH maybe it would be better if the KDE project started suggesting 400mhz and 256RAM as a minimum for a useable "desktop workstation", and saved time by *not* optimizing the code for old machines. It's an engineering question worthy of debate.
>>>>>>>>
That's ridiculous! And Linux people claim that Win2K is bloated! An OS (and by extension, a GUI environment) is just a helper. A lowly piece of code that has no other reason for existance than the fact that it is sometimes useful to the application. Nobody wants to run KDE-2, they want to run their apps. The OS code should just get the hell out of the way and leave all the processor they can do the application. I don't mind my 3D renderer sucking up resources like anything. Hell, I'm getting a dual Athlon soon just so I can feed it more. But moving windows around on my desktop is a means to an end, not an end in itself. Thus, it deserves very little of my processor time, whether my machine is a dual 1.2GHz monster, or a wimpy 300Mhz weakling.
Its not even that. MS goes to a lot of trouble optimizing the "feel" of the OS. They make sure that things load quickly, even if they're not fully functional when first loaded. They make sure that widgets flicker as little as possible when being resized. They grok the scheduler to make sure that GUI apps get preferential scheduling. These things just make the environment "feel" faster. While KDE2 is probably better technology than Win2K's GUI, it seems that the KDE devels would rather add features than go to the trouble of optimizing things like this. There is no arguement that the Linux core OS is significantly faster and more stable than Win2K. However, KDE2 (and, to be fair, most other non-minimalistic Linux GUIs) slows the cheetah down to the point where it loses the race to the hippo.
Windows 2000 might not be usably fast on a 386/33, but neither is KDE (1.x even) for that matter... And maybe you and I have a different definition of "usable" because I consider something jerky to be unusable. Maybe I'm spoiled, but if I notice it, its going too slowly. Win2K goes fast enough that I don't notice it (and it is significantly faster than 9x, if you don't know why read a good OS book) but KDE2 doesn't. Simple as that.
Microsoft says "Okay, do it this way".
>>>>>
Is this really such a *bad* thing? K & R wrote the UNIX API and said "do it this way." Is anyone complaining? IEEE standardized the API into POSIX and told people to "do it this way." POSIX is perhaps the most successful OS API in history. Somtimes, a nice standard is just better than some additional freedom (especially when that freedom is for hardware developers, which aren't highest on my ethics list).
The multiplier is just the difference betweent the CPU speed and the bus speed. An AMD T-Bird 1.3 is actually clocked at 1.3 GHz, but a divider makes the bus speed 266 MHz. The multiplier just specifies how much faster than the bus the CPU should be clocked, its not some trick that speeds up the CPU. Besides, a 2.2GHz bus would be *really* interesting.
Actually, Celerons (specifically) have very little L2 cache. All Intel chips have too little L1 caches (32KB? That's SO 1998!) Also, a 400MHz G4 costs more than a 800 MHz PIII, and STILL won't run faster than it in most cases.
Yep, here it goes again. Everybody needs a PCI bus that allows the sound card to transfer at 8 GB/sec, and a system bus that can keep up with the soundcard... Get real. Bus speed matters, but so does CPU speed. Either one is a welcome advancement.
I know you guys work hard on this, but comments like this just tee me off. Speed is never a bonus. If you release a piece of software, it must be usably fast to begin with (which KDE isn't for a whole lot of people.) If you extend or add features, you must make sure that the speed doesn't decrease. Making software fast isn't really that hard, and it doesn't lead to bad design. It just requires a little restraint with respect to features. With all the interface doodads and eye candy in KDE2, it is quite apparent that this restraint has not been exercised.
Has the speed been fixed?
on
KDE 2.2 Released
·
· Score: 1, Informative
Despite how mature KDE 2.x is, it still has a killer flaw: it is dreadfully slow. I mean it makes Windows-2000 feel like BeOS. I scares me to think of all the people who never got into Linux because KDE's speed frightened them away.
Somebody on/. once made a very good point. Developers should be forced to code on vanilla pentiums with 48MB of RAM. Thus, their programs will run quickly on those with mainstream machines. Watching KDE-2.1 (I have not tried 2.2, so I won't comment on it) sputter along on my PII-300/w 256MB of RAM (which runs Win2K damn snappily, thank you very much) is just sad. For example try loading up a directory with a lot of files in Konqueror. KDE2 will visibly pause while Win2K will merrily blast them all onscreen. Then try resizing the window (with opage resize turned on). With Explorer, there is barely any flicker, and the process is *smooth* With Konqueror, you can see visible redraw, and the thing rubber-bands like Netscape 4.7. While Word 97 starts up instantly on my computer, even simple apps take several seconds to load on KDE. For a twichy guy like me (spoiled by BeOS) KDE's lack of snappy response makes it unusable. Alex St. John (DirectX evangalist and former columnist at MaximumPC) once asked how the hell Internet Explorer could visibly flicker when drawing a few bitmaps and some text, while Carmack was spewing tons of AI driven monsters on the screen at 30fps.
What KDE really needs is a feature-freeze. It is already "usable enough" and has enough eye-candy (aren't UNIX guys supposed to HATE style over substance?) What needs to be done is to revamp the internal architecture for speed. Not turning the codebase into spaggheti code for a few more % speedup, but making good design decisions that trade some 1% functionality (defined as functionality that is cool, but useless to 99% of the population, such as remote network objects) for speed and simplicity. Unfortuately, the tricks going on at AMD and Intel virtually assures that such a thing will never happen. It has been said of software (MS software in particular) that it expands to fill available hardware resources. I thought Linux was supposed to be different?
Slashdot Mirror
And where was Direct3D at this time? Was Direct3D even usable? Again, why re-invent the wheel with Direct3D when OpenGL was available?
>>>>
I think you're relying too much on hindsight. I don't think that OpenGL was even an option at the time. GL was a heavyweight API that ran on heavyweight hardware and required complex drivers. It just wasn't suited for gaming in the days of Virge. Also, OpenGL drivers were (and still are) very complex to develop. Even today, many vendors don't have stable OpenGL drivers. Thus, the chances of the consumer hardware market accepting GL were pretty small.
Ok, with this reasoning we can re-invent many APIs, and then when our new API after several years doesn't suck any longer compared to what was already available before, we can conclude that the effort was worth it because the older API "was" better...
What do we gain here?
>>>>>>>>>>>>
D3D and OpenGL, though they both do 3D, have two different paradigms. OpenGL is clean and abstract, while D3D is down and dirty. D3D was suited to the consumer level hardware of the time, and OpenGL was suited to the pro level hardware of the time. While it could be argued that both APIs have moved closer together (D3D has become more abstract because new hardware accelerates more parts of the pipeline, and OpenGL has started to expose more low-level functionality through extensions), there was no way anyone could have predicted how hardware would evolve.
I believe the conclusion was that it may have been a good choice for Sweeney, short term. But bad for the gaming community as a whole in the long run, due to fragmentation.
>>>>>
What fragmentation? Most people use Windows and most games use D3D! Where's this fragmentation you speak of? If some developers chose to use OpenGL, that's their option. It doesn't really hurt the consumer any. The underlying API is more or less invisible, unlike the disparity between, say, GNOME and KDE...
But that goes for all developers that chose Direct3D at the time. Besides, Unreal's Direct3D performance hasn't exactly been stellar throughout the history. Had more developers gone with OpenGL, hardware manufacturers would have focused on OpenGL instead of Direct3D. I believe it was an important breakpoint for the success of Direct3D when Epic chose it.
>>>>>>>>>..
While that is true to a certain extent, I belive that can't explain all of why D3D has been successful. Remember, Carmack's engine powers many of the 'A' titles out there, and that keeps OpenGL a force. I think hardware manufacturers just chose to go with D3D because it is easier for them to implement, and developers chose it because it had more stable (consumer-level) drivers and MS is more responsive to the needs of game developers than is the ARB.
Yes, gamers mostly run Windows/D3D, but I believe that fact was the issue up for debate and questioning? Windows users could run OpenGL without sacrificing any gaming experience.
>>>>>>>
Again, for the above reasons, this is not the case. When D3D was created, using OpenGL would have been a major sacrifice for gamers.
The OS market may be another issue, but the fact that Direct3D limits the choice of platform (and freedom of people), is highly related to this issue.
>>>>>>
Gamer's really don't care about freedom. They want their OS running stably (Win2K does this to a large degree) and their games running smoothly. Like communists, the OSS community doesn't always understand that politics is not the sole factor in everything.
Define compatible? I believe being cross-platform and being used for other stuff than gaming is being compatible....
>>>>>>>
Compatible in the practical sense. There are more gamers who own Matrox cards than gamers who run Linux. Being more comptible with Matrox's crappy GL drivers (ie. using their D3D drivers instead) is more important than being cross-platform.
How many vendors are there today...? I bet most people use Nvidia hardware and they have great OpenGL-drivers.
>>>>>>
And you'd be wrong. Although NVIDIA is #1 in sales, its going to take a lot before ATI's 22 million chips go out of circulation. Even S3, Matrox, and PowerVR are still a factor. These cards don't have good OpenGL drivers, but they are still a large part of the gaming market.
And I haven't heard that Direct3D has more features, taking OpenGL's modularity into account. Stick to the facts!
>>>>>>>>>
Take a look at an OpenGL 1.2 book, then take a look at a D3D book. There are tons of features in D3D that (if they appear at all) only appear as extensions to OpenGL. Since these extensions are often propriatory to particular vendors, it causes headaches to developers who have to deal with a fragmented API. MS thought of making a D3D extension mechanism to relive themselves of the burden of haivng to release new versions of D3D so often. Game developers were not keen on the idea, and blocked it from happening. Extensions are great for OpenGL's original market (slow evolving pro hardware), but aren't the right solution for a quickly changing consumer hadware market.
And read John Carmack's posting for his view on DirectX-releases if you believe OpenGL extensions are so bad...
>>>>>>
Actually, he points out that ATI and NVIDIA have diverged on the extensions point. Unless ATI and NVIDIA suddenly become the only forces in the graphics industry (a plausible, but undesirable scenario) this divergance will become worse. I don't really trust the good natures of the hardware developers to work together and adopt one another's extensions. The days of Glide, MeTaL, PowerSGL, and other propriatory APIs are still to fresh in my mind...
I have personally always questioned the existence of Direct3D (I am not talking about DirectX in general here), since I really can't find anything it has contributed to but fragmentation of API:s and drivers. I am not out to bash Microsoft here, but I really can't help to see how well Direct3D fits in with Microsft's known ability to use its power (and near monopoly) to crush the competition. Direct3D does not only hurt OpenGL, but also gaming on other platforms in general, thus forcing consumers to the one and only alternative... Anyone but me thinks Deja vu? Why didn't Microsoft simply develop a DirectX wrapper around OpenGL, like SDL? This would allow OpenGL to integrate transparently into the rest of the DirectX stuff and at the same time avoiding the introduction of a completely new redundant API.
>>>>>>>
The public has a short memory indeed. While MS no doubt uses Direct3D to compete with OpenGL, its not D3D's main reason for existance. D3D was created to keep Glide from becoming the de-facto Windows 3D API. MS had lost a lot to Apple when Quicktime became the major media format on Windows, and Bill wasn't having a competing propriatory API on his platform. OpenGL wasn't even an issue until Carmack decided to use it for GLQuake, and even then, it didn't become popular until NVIDIA introduced full-blown ICDs into the consumer market. Thus, your wrapper idea has two flaws. First, the whole point of DirectX in general is to remove as many abstractions as possible while still maintaining hardware independence. Wrapping around OpenGL (which significantly more abstract than D3D even today, and was much more so back when D3D was created) would have gone across the grain of the D3D API. Second, since OpenGL wasn't even a player in the consumer industry at the time, MS might as well have wrapped over Heidi for all the good it would do.
OpenGL works great (why else do the #1 3D-genius favor it),
>>>>
Carmack is the One True Game Creator (TM) now? He favors it because it didn't like the early versions of DirectX, and because it is cross platform. I haven't heard him say anything about its technical merits in a long time.
just look at the Quake-engine games and the upcoming Doom... OpenGL had this when Direct3D didn't even exist and was clearly the better API for a long time.
>>>
Keyword, "was."
It is robust, also cross-platform and not controlled by a gigantic "closed" company. So the choice should be a no-brainer, right?
>>>>>>>>
Not for Microsoft! Or have you changed the subject somewhere and I just missed it?
I believe the developers are to blame. Tim Sweeney once chose to replace the ageing proprietary Glide API in his Unreal engine. He decided (about the time of DirectX5) to go with Direct3D, citing better driver support. This is just such a bad argument... Direct3D drivers may have been better back then, but OpenGL support is today as good as Direct3D. OpenGL was back then already a mature, proven API. How would driver support be for OpenGL today if OpenGL was the only (or favored) API?? Just think about it....
>>>>>>>>>
I don't know how bad a decision it was for Sweeny. A lot of people will say that D3D is technically superior to OpenGL today, and 99% of UTs users are on Windows anyway, so I don't think he's lost much.
If developers really care for gamers they should do like John Carmack. He has put free effort into bringing his gaming experiences to as many people as possible, no matter what underlying platform they use, by contributing to the improvement of free OpenGL drivers himself (through the Utah-GLX project). His creations run on virtually every platform out there and they have always been on the bleeding edge. This prove that cross-platform gaming is possible, but only if the will is there and the right choices are made.
>>>>>>>
Let's get this straight. Gamers run Windows. Consumer D3D drivers, in general, are better than consumer OpenGL drivers. D3D is also more powerful, for game development anyway. If developers want to help gamers, they should use the API that runs their game best on the user's hardware. Right now, and for the forseeable future, that API is Direct3D. Now whether or not it is good for the OS market in general is another issue entirely.
So, my question to game developers is: Why choose Direct3D? It's not as if OpenGL won't run on Windows...
>>>>>>>>
Its more compatible. Only a few vendors have really good OpenGL drivers, even today. Its more powerful, since it has more default features. It is easier to support, since there are far less problems caused by buggy OpenGL drivers, and the extension mechanism (which developers detest by the way) isn't present in D3D.
I think you don't seem to understand the definition of a "restriction." The GPL might lead to freer code, but it does that by being more restrictive than the BSD license. Take a different example. As an employer, you can discriminate against people when hiring. This is more restrictive, but also leads to a freer society.
Well, the BSD licence forces you to release your code to the likes of microsoft who can take it, and use it for whatever they like, without merging the changes back.
>>>>>>>>>
Umm, if you license something under the BSD license, you implicitly OK that usage. Some people don't care if their code gets used in a closed commercial system, if it makes that system better for users. Are you saying that that's bad?
Great. Another article that as a lot of technical possibility, and all I hear are license considerations and politics. Anybody want to enlighten the rest of us as to why exactly this release is significant? Is the OpenUNIX kernel somehow better than the Linux kernel? At what things? What's the VM system look like? Real meaty stuff that nobody seems to talk about...
What happend in '97-'98 that made for so few releases?
God what I'd give to see a Win2K changelog...
Its a metaphor. Order is truth, truth, beauty.
I shouldn't bother responding to this obnoxious and patronzing post, but screw it, you are a pretentious fuck.
>>>>>
God I love being me...
When I started using GCC, nowhere near 90% of GCC targets were for IA32. It could build for 68000, Sparc, PDP-20, etc. I remember hacking on the code generation for a summer job I had ages ago, since the ANSI C compliance was so good (for the time). That is why I said that the retargetable nature of GCC was always its "killer feature". Telling me to "deal" with the fact that 90% of targets NOW are intel, is an assinine retort.
>>>>>>>
I meant that right now, 90% (or some other big percentage) of people using GCC are running x86. That's just the simple truth of the world.
GCC 3.0 is a nice step forward, and perhaps compile speeds will improve in future releases. If that isn't good enough for you, spend the $400-$500 for Intel's compiler, you damn cheapskate. Meanwhile, I'll spend that money on a faster CPU, more RAM, a bigger disk, AND have money left over for good sushi.
>>>>>>>>
Hey, I never said it wouldn't get better. I'm just saying it really isn't that great. And aside from better complience, there is no real tangible improvements in 3.0, despite the extensive changes.
GCC is *good* for developers, since commercial compilers have to perform at least as well as GCC in order to expect any sales. So the non-free "competition" must not stand still to remain relevant. As of GCC 3.0, we have the makings of a very good baseline for C++ (and even C99, to some extent) support, and it will just get better. Deal with it yourself.
>>>>>>
Again, I never said that it wouldn't get better. I'm just saying, that at this point, commercial competitors such as icl have almost as good complience, much better speed, much better code generation, and are more developer friendly (icl has GREAT error messages). Sure GCC will get better, but it isn't that great yet.
Lost cause? The only remaining hope is that Palm does something with the BeOS code (like Open Source it!), cuz god knows BeIA has been BeOS's worst enemy...
Honestly, I can't think of a single good thing that could come out of this. Can you?
Wow. So that's what french crack does ;) Anyway, I take offense to your statement that scientists don't appreciate beauty. Science is all about finding the underlying beauty in the world. As it has been said many times, Truth is Beauty. As for C++ programmers, I find a piece of code that uses hardware 99.9% efficiently to be beautiful. Meanwhile, Java's focus on rapid coding at the cost of efficiency seems merely utilitarian.
Oh god, even I can see how bad this is. Blind optimism, must be nice...
BeOS is not based on XINU (yea, I've heard that rumor too). XINU is an x86 OS that doesn't run in protected mode. BeOS is a microkernel that started on the AT&T Hobbit. Totally different beasts.
Umm, the UNIX API isn't garbage, the garbage is some of the stuff that has evolved around it.
As for POSIX complience, Windows 2000 (Cygwin) Linux, BeOS, AtheOS, Hurd, and MacOS X will run 99% of all (non-GUI) POSIX software out there. I'd say that that's pretty damn successful.
Would you trade speed of compilation for standards compliance?
>>>>>>>>>
Yes. Because I tend to stick very closely to "safe" code, which is always a good practice, no matter how standards complient your compiler. There is, of course, a balance, but GCC's balance point is in the wrong place.
That would be complete stupidity. GCC 3 is a godsend for C++ developers, and a firm base for future speed improvements.
>>>>>>>>>>
Well, let's see what shapes up. Of course, the competition isn't standing still either. IntelC++, for example, is very fast, makes great code, and is quite standard complient (not to the point of GCC, but very close). If only it didn't cost so damn much...
Besides, standards compliance is not GCC 3's only feature. It is also one of the most portable and retargetable compilers out there (perhaps THE most), which was always the main killer feature.
>>>>>>>>>
90% of the world runs x86, deal with it. Something useful to a very limited portion of the population cannot be billed as a "killer" feature. Maybe if GCC was billed as an embedded compiler, that would be true, but as a compiler for Linux/x86, that feature carries little weight.
I have no doubt that GCC will improve. Whether it will every be better than its competitors, however, is totally up in the air. As it stands, 3.0 is not much better than 2.95.3 in any respect other than standards complience. If 3.1+ changes this, then great. Otherwise, not so great.
Actually, corporate machines are unilaterally badly configured. MS Windows is very needy. For example, if you hose something, you can't just reinstall over the old installation, but you have to wipe the disk clean. You have to feed it the highest quality drivers and make sure not to run programs that can bother it (like AIM). If you follow the rules (not so hard in reality), clean you recyle bin regularly, and keep up on those updates, you too can be a happy Win2K user.
That would be silly. I want all developpers to have quad SMP machines with a Gig of RAM and 100 gigs disk. That way they can develop and compile and debug FASTER.
>>>>>>>>
BeOS was developed on 66MHz PPCs with 16MB of RAM and it shows. The damn thing runs like hell on mediocre machines, and even faster on faster ones.
It would be nice if they all had a small machine like you described on their network so that they could INSTALL their rapidly developped applications for TESTING. That might lead to some optimizations being done that don't happen now.
>>>>>>>>
Its not just optimizations. Its the whole mindset that features are more important than basic usability.
OTOH maybe it would be better if the KDE project started suggesting 400mhz and 256RAM as a minimum for a useable "desktop workstation", and saved time by *not* optimizing the code for old machines. It's an engineering question worthy of debate.
>>>>>>>>
That's ridiculous! And Linux people claim that Win2K is bloated! An OS (and by extension, a GUI environment) is just a helper. A lowly piece of code that has no other reason for existance than the fact that it is sometimes useful to the application. Nobody wants to run KDE-2, they want to run their apps. The OS code should just get the hell out of the way and leave all the processor they can do the application. I don't mind my 3D renderer sucking up resources like anything. Hell, I'm getting a dual Athlon soon just so I can feed it more. But moving windows around on my desktop is a means to an end, not an end in itself. Thus, it deserves very little of my processor time, whether my machine is a dual 1.2GHz monster, or a wimpy 300Mhz weakling.
Its not even that. MS goes to a lot of trouble optimizing the "feel" of the OS. They make sure that things load quickly, even if they're not fully functional when first loaded. They make sure that widgets flicker as little as possible when being resized. They grok the scheduler to make sure that GUI apps get preferential scheduling. These things just make the environment "feel" faster. While KDE2 is probably better technology than Win2K's GUI, it seems that the KDE devels would rather add features than go to the trouble of optimizing things like this. There is no arguement that the Linux core OS is significantly faster and more stable than Win2K. However, KDE2 (and, to be fair, most other non-minimalistic Linux GUIs) slows the cheetah down to the point where it loses the race to the hippo.
Windows 2000 might not be usably fast on a 386/33, but neither is KDE (1.x even) for that matter... And maybe you and I have a different definition of "usable" because I consider something jerky to be unusable. Maybe I'm spoiled, but if I notice it, its going too slowly. Win2K goes fast enough that I don't notice it (and it is significantly faster than 9x, if you don't know why read a good OS book) but KDE2 doesn't. Simple as that.
Microsoft says "Okay, do it this way".
>>>>>
Is this really such a *bad* thing? K & R wrote the UNIX API and said "do it this way." Is anyone complaining? IEEE standardized the API into POSIX and told people to "do it this way." POSIX is perhaps the most successful OS API in history. Somtimes, a nice standard is just better than some additional freedom (especially when that freedom is for hardware developers, which aren't highest on my ethics list).
The multiplier is just the difference betweent the CPU speed and the bus speed. An AMD T-Bird 1.3 is actually clocked at 1.3 GHz, but a divider makes the bus speed 266 MHz. The multiplier just specifies how much faster than the bus the CPU should be clocked, its not some trick that speeds up the CPU. Besides, a 2.2GHz bus would be *really* interesting.
Actually, Celerons (specifically) have very little L2 cache. All Intel chips have too little L1 caches (32KB? That's SO 1998!) Also, a 400MHz G4 costs more than a 800 MHz PIII, and STILL won't run faster than it in most cases.
Yep, here it goes again. Everybody needs a PCI bus that allows the sound card to transfer at 8 GB/sec, and a system bus that can keep up with the soundcard... Get real. Bus speed matters, but so does CPU speed. Either one is a welcome advancement.
"and you get as a bonus %30-%50 speed increase.."
I know you guys work hard on this, but comments like this just tee me off. Speed is never a bonus. If you release a piece of software, it must be usably fast to begin with (which KDE isn't for a whole lot of people.) If you extend or add features, you must make sure that the speed doesn't decrease. Making software fast isn't really that hard, and it doesn't lead to bad design. It just requires a little restraint with respect to features. With all the interface doodads and eye candy in KDE2, it is quite apparent that this restraint has not been exercised.
Despite how mature KDE 2.x is, it still has a killer flaw: it is dreadfully slow. I mean it makes Windows-2000 feel like BeOS. I scares me to think of all the people who never got into Linux because KDE's speed frightened them away.
/. once made a very good point. Developers should be forced to code on vanilla pentiums with 48MB of RAM. Thus, their programs will run quickly on those with mainstream machines. Watching KDE-2.1 (I have not tried 2.2, so I won't comment on it) sputter along on my PII-300 /w 256MB of RAM (which runs Win2K damn snappily, thank you very much) is just sad. For example try loading up a directory with a lot of files in Konqueror. KDE2 will visibly pause while Win2K will merrily blast them all onscreen. Then try resizing the window (with opage resize turned on). With Explorer, there is barely any flicker, and the process is *smooth* With Konqueror, you can see visible redraw, and the thing rubber-bands like Netscape 4.7. While Word 97 starts up instantly on my computer, even simple apps take several seconds to load on KDE. For a twichy guy like me (spoiled by BeOS) KDE's lack of snappy response makes it unusable. Alex St. John (DirectX evangalist and former columnist at MaximumPC) once asked how the hell Internet Explorer could visibly flicker when drawing a few bitmaps and some text, while Carmack was spewing tons of AI driven monsters on the screen at 30fps.
Somebody on
What KDE really needs is a feature-freeze. It is already "usable enough" and has enough eye-candy (aren't UNIX guys supposed to HATE style over substance?) What needs to be done is to revamp the internal architecture for speed. Not turning the codebase into spaggheti code for a few more % speedup, but making good design decisions that trade some 1% functionality (defined as functionality that is cool, but useless to 99% of the population, such as remote network objects) for speed and simplicity. Unfortuately, the tricks going on at AMD and Intel virtually assures that such a thing will never happen. It has been said of software (MS software in particular) that it expands to fill available hardware resources. I thought Linux was supposed to be different?