DirectSound accelerators can push upwords of 96 channels to the hardware. It doesn't matter if the game will use all of it, what matters is that DirectSound does it BETTER than the equivilant under Linux.
I don't think there is an open implementation yet, though KDE did something called KOM. Yes, it does have 10 MS latency when doing local calls. For local calls, it is simple a pointer deference, as fast as a C++ virtual function call. Using DCOM (Distributed COM) you get all the cool network features you are talking about, (though I'm not sure if it does anything with clustering.) I have know clue where the Linux/*BSD/BeOS/AtheOS port is, but COM is fairly well documented, and it should be more or less trivial (for easier than the bloated Bonobo/Cobra crap GNOME is doing) to write an implementation for other OSs.
I am surprised that this became a Linux vs Windows kind of thing. Windows is not even involved in this story. When a game developer writes on Windows, he would be stupid to use any more of Win32 than needed to create the window and delete the window. Most Windows games today are programmed in DirectX, which offers almost all the services needed by a game. Once one learns how to set up a windows and do some threads, almost everything else a game needs is done through calls to DirectX instead of OS calls. In addition to that, most games spend most of their time inside their own code anyway, so the OS has a negligible effect on performance, (assuming of course that the app has direct or near direct access to hardware). Som in reality the competition is Linux vs. DirectX. Quite an impressive showing on Linux's part, at least for now. DirectX (true to its name) has much less overhead that any OS ever could. I wonder, however, if this success is short-lived. Quake isn't exactly a service intensive game. Sound is pretty basic, as is input. They only thing that really matters in this case is the speed of 3D subsystem. Game, however, will eventually evolve, in particular using more sound. Some games (thief in particular) already do this. I really wonder if Linux can handle yet another subsystem that needs direct access to hardware. As 3D sound controllers become more complex (like Aureal's controllers) the OS will need a good way to get huge amounts of data and commands to the sound cards. In these types of games, Windows will keep trumping Linux. The main problem is that Linux doesn't have DirectX. In absense of that, it has no consistant API that pushes the OS out of the way and allows the game to take over the system. Take a look at the rest of the APIs. DirectSound, DirectInput, DirectDraw, and to some extent DirectPlay (for its flexibility) whoops anything availible on Linux. (Any Linux driver-hardware combo that allows 32 HW accelerated 3D sound streams in addition to 96 normal streams? Windows had that in the A3D 2.0 days.) What Linux really needs at this point is a DRI for the rest of the sub systems. Only then, will Linux become better than Windows for games. Some will say the current situation is enough. Linux is almost as good as windows, it performs almost as well. Almost will not cause anybody to switch, however. If Linux really is a technically superior system, it should be able to trounce windows, not merely equal it.
Ahh, its all clear now. I didn't realize you were talking about non-OS managed threads. I had the idea that you were saying BeOS and NT threads are resource intensive.
This is incorrect. Nothing in Unix says that threads must be lightweight processes, there are many implementation possibilities. Solaris is the only design firmly in that camp. Linux is actually quite the opposite, if I remember right, in that both processes and threads are created with the same spawn system call. >>>>>>>> Actually, I believe that you have it reversed. I know Solaris uses their own implementation of threads, and that Linux uses POSIX threads. I have seen test results that show that POSIX threads take 10 times longer to create than NT threads (which take serveral times longer than BeOS threads), and the system slows down significantly at a much lower thread count than under NT and BeOS. (Both of which have nearly a hundred threads from bootup.)
Also, the (imho only) advantage of lightweight processes is that the the resources to create a thread are far less than any object that the OS is aware of. This is exactly the opposite of what you said. >>>>>>>> Actually, under most systems stuff like semaphores and locks take far less memory. The advantage of threads is two fold. First, the multiple paths allow multiprocessing, and second, they keep subsystems of a single program from having to on one another. This is a big help considering that fact that even the most basic PC these days has four processers, the I/O processor, the graphics processor, the sound chip, and the main CPU.
The problem with lightweight processes is that support requires complex libraries and redundancy with the OS (which has to support multiple processes anyway) and requires non-blocking versions of all system calls, which are much more complex (interesting enough MicroSoft makes a big stink about their non-blocking support and their multi- threading support, when realistically only one of these needs to be implemented!) >>>>>>>>>>> Threads and non-blocking systems calls are neither complex, nor terribly difficult. If the OS is designed from the core to support threads, (like BeOS and NT) multithreading naturally flows to the whole system.
As for the Win95 vs. Linux thing, I had no intent to glorify Windows in anyway. I was just repeating what I heard on the Linux.org FAQ about how Win95 is less susceptible to bad memory than Linux, mainly because it doesn't use the hardware as effectively. I never said anything about it being fault tolerent, I merely pointed out that there are differences between OSs that will allow one OS to run on marginal hardware while another will not. As for having no experiance with VMS, that experiance is unnecessary in this case. I said I have no idea if VMS can do that, but I am sure that some hypothetical OS exists that could do that, and VMS might be one of them. The person I was responding to thought that it did not matter what OS was running, that the HW as entirely at fault. I was just pointing out that in some cases, some OSs will keep running in places others won't. I never said that VMS was one of them, I just said it COULD be.
No, compressed postscript is just that, compressed postscript. PDF is an entirely new open standard that is heavily based in PostScript. It doesn't, however, carray a lot of the full fleged language capabilities of postscript, it has a better color matching model, and most importantly YOU DO NOT HAVE TO PAY ADOBE TO IMPLMENENT IT!
Because you're a nerd and have no asthetic sense. (Whoa, put that keyboard down, just kidding!) Seriously though, people like pictures and icons and shiny things. If they didn't everyone would be using Motif. There is something to be said for asthetic appeal. People don't live in ugly houses, they don't like reading books with ugly formatting, they don't like reading magazines without lots of color and pictures. Humans are visual creatures used to seeing lots of color. A grey icon that says EMAIL might be efficient, but it would bother the hell out of some people. Second, it might not even be more efficiant. Often, when one gets a desktop organized just so, people can actually access things faster than by reading an icon. Once you have the icon memorized (through familiarity) it is processed by the pattern recognition part of the brain. This is significantly faster than sending it through the analytical part of the brain(mainly because humans don't do pattern recognition with plain, black characters). For me at least, I access icons on my desktop and BeMenu more by color and shape of icon rather than anything else. This is shown very well by the default helix GNOME menu. The icons for terminal and logout are the same shape. So my brain, (using shape before it reads the text of the icon) will often cause me to logout when I wanted to start a terminal.
Yes, it is partially hardware, but a great deal software. It shows that VMS can take much more flaky hardware errors than can UNIX. (It's true. Even Win95 is less susceptible to flaky hardware than Linux is. Some severly overclocked systems will run on Win95, but crash on Linux.) Take a PC running Win95 for example. If one shoots the harddrive, and the resultant shock sends a electric surge up and kills an I/O processor, more likely than not, a UNIX will crash. Another bullet-proof OS, for example, could handle an I/O processor going out in the middle of operation and still keep running. I have no experiance with VMS, so I don't know it can do that, but I think that's what the author was getting at.
Yo, COM is not without its merits. There is only a few major architectural differences between SOM and COM, the most important being that SOM supports direct inheritance, while COM doesn't. COM does something called aggregation which achieves the same effect. They support two different philosophies. SOM is slightly more fragile at the benifet of being more flexible, while COM is more resistant to base-class derived class interaction problems at the expense of requiring more programming effort to derive an object. I am of the mind that developers in general aren't responsible enough to do unchecked deriving, and that by making it less automatic in COM, the developer is required to have a clearer understanding of the interface between the base and derived class.
Actually, there are many open OSs that are not UNIX-like. My favorite (for reasons that will becomes obvious soon) is AtheOS. It is a project run by one person, but is actually progressing quite quickly. It even has hardware accelerated drivers for some Matrox cards. The best part is that its architecture was heavily influenced by BeOS, and its file system is basically a clone of BFS that he made using the book that the guy who wrote BFS published.
Actually, multitasking and multi threading have no relation to each other. Multi tasking is the ability to run more than one process. Multi-threading is the ability of one process to have multiple, simultanious paths of execution. Both OS/2 and Windows have the same multi-tasking/multi-threading model. For 32bit apps, both are preemptivly multitasked, and many parts of the OS and some apps are multi-threaded. Second, don't go dissing the Win95 process/thread model. It kicks UNIX's all over the place (not in security of course). Under UNIX, a thread is a lightweight process. As such, the scheduler is process oriented, and threads take much more time and resources to create under UNIX. Under OS/2, Windows, and BeOS, a thread is the smallest unit of sheduling, and are very lighweight in terms of resources and creation tim. Lastly, there is no such thing as "true multitasking." Hell, under any definition of mulitasking, DOS had multitasking (TSRs.) Win95, OS/2, BeOS, and Linux both employ something called preemptive multi-tasking, where the OS decides when an app should give up processing to another app. Under cooperative multi-tasking systems, like 16 bit Windows and MacOS 10, the application has to call a function to return control back to the OS so it can shedule another process.
It doesn't matter if it is or not, because Darwin isn't really supposed to be an OS in it's own right. Some people (namely Carmack) had an affinity for OSX and decided to contribute to its base OS. Aside from that, Darwin has some cool features, namely the kits.
Who says that a story posted on Slashdot has to have something to do with the furthering of Linux? Darwin looks pretty cool as an OS in its on right and has zilch to do with Linux. If anything, it's helping BSD gain wider acceptance. It's Darwin's spotlight, not Linux's.
But neither D3D nor OpenGL specify access to hardware or resource management! These are both implementation details, and can be bad or good depending on who wrote the implementation >>> You cannot take that statement in a vacuum. Both OpenGL and D3D specify a significant number of implementation details, and it is a proven fact (go read some benchmarks circa 1996-7) that OpenGL was faster than D3D. Now take a look at current games that support both OpenGL and D3D. You'll see that they both run at about the same speed.
No game developer in their right mind would risk using a feature not implemented in hardware on most cards. Why would you want to fall back to Microsoft's HAL? It's SLOW.
In this case, OpenGL is almost the same as D3D. Instead of being implemented by the HAL, unsupported features of OpenGL are implemented by the vendor. >>>>>>>>> Take a closer look at my vertex skinning example. No matter what, the app will have to do vertex skinning (it's integral to many engines' animation capabilities.) In OpenGL, if you want to take advantage of hardware acceleration for skinning, you write 3 code paths, one for each case (software, nVidia, ATI). In D3D, you write one code path, (The D3D case) and D3D will take care of things. If you have to fall back to software, so be it, you'd have had to do that anyway, and if you have hardware, you get a nice speed increase. You say that unsupported featueres of OpenGL are supported by the vendor. That's the whole problem. In D3D, the core feature set is much larger, and unsupported features are emulated. Many of the newer extensions don't take a terrible speed hit if they are being emulated. Even if the speed hit IS that bad, D3D still comes out ahead. Take a hypothetical lighting feature that has not yet become an ARB extension. It is accelerated on two or three cards. In OpenGL, you'd have to support the case where HW acceleration is not available, in which case you'd disable the feature, the case where nVidia accelerates it, in which case you'd use the nVidia extensions, the case where ATI accelerates it, in which case you'd use the ATI extensions, etc. In D3D, you'd have two cases. If D3D reports that the feature is not being hardware accelerated, you disable it. Otherwise, leave it enabled. The best thing about this is that it takes advantage of new hardware AUTOMATICALLY.
This is entirely false. Both API's abstract access to vertex buffers, and provide direct access to frame buffers (depth, color). Do you really thing that when you fill a vertex buffer in D3D that you are using the vertex format that will eventually get sent to the card? Think again.
But what if the user is running on an S3 Virge? Heck, I guess he's out of luck! Time for the slow HAL to kick in! As a game developer, you should know whether or not your neat little trick is actually running in hardware! >>>>> If he's running a virge, he is scewed anyway. Besides that fact, vertex skinning is done by most apps anyway. Hardware just makes it faster. We're not talking about stuff like texture mapping here. Most of the new features in cards can be done adequatly in software, but not to the level the developer would like. As such, glazing over these differences in hardware makes sense. Plus, you do know if the feature is being accelerated, that's what driver caps are for. If it is not accelerated, you can fall back to lower quality rendering, but even if you don't, the app will still WORK. >>>>>>>>>> Okay, niggly little point, you do not have direct access to vertex buffers in D3D, but you do have direct control. When you create a vertex buffer, it is a locked object like a screen buffer. The display driver can manage these much better than a program-space array like glVertexPointer uses. (Yes, I know about complied vertex arrays, but that's an extension.) Second, OpenGL does not give you direct access to buffers. I'm not talking about his glCopyPixels crap, I'm talking about a pointer to video memory. Believe it or not, there are a lot of cool things you can do with that. Under direct access, I also include control. I find it silly that there is nothing in the core open gl API like a vertex buffer object. Texture objects exist, and both are buffers that are uploaded to the card, so why the lack of one.
What about implementations that don't even load textures into a card's on-board memory? How will your LoadThisTextureToVideoMemory work on a card without local video memory free? You'll get an error and will have to load it into AGP anyway. Why not let the implementation take care of this minor detail >>>>>>>>>> If the card doesn't have local video memory free, you still have to load it into AGP memory. Under OpenGL, you have less control of the situation then under D3D. This is not a minor detail, it can get in the way of some nifty rendering styles. Say you are rendering a room with a strip of a certain texture down the middle. A lot of stuff in that area uses that texture, and it is critical that it stays in video memory at that time. However, it is not used for the rest of the room. Do you give it a really high texture priority? That way it stays in memory, but will eat lots of space while the rest of the room is rendering. You could reprioritize in the middle of the frame, but state changes are expensive. An API should not try to force a way of development on the developer. Why not give more low level control over stuff like this that can potentially be important?
Read up on auxilary buffers. >>>>>>>>> I have, and they are fairly useless. Most hardware implementations of OpenGL can't render accelerated to an auxilliary buffer. This is bad because it is a pretty nifty effect to render parts of the scene into a texture buffer. It looks really cool when rendering stuff like portals, mirrors, etc. In the future, it could be even more helpful. Rendering a 3D movie to a texture buffer, then using that as the source texture would look pretty cool.
Half you people have no clue whatsoever about what makes Windows easy to use. People could care less if the Windows interface is simple, or intuitive. It's easy to use because everyone uses it! The vast majority of people with any semblance of computer background are used to windows. Thus, KDE 1.x is easy mainly because it seems to be a Windows clone. Then you have the segment of the market that is totally new to computers. In that case, UNIX is way out of their ballpark. Sure they can wordprocess or whatever once everything is set up, but not everyone has a sysadmin. It is irrelevant on how easy to use the interface is in most cases. What matters is how easy to use the system is as a whole. Take something simple as adding new fonts. Even iMac people can do it, just drag it into the directory. In Linux, you have to put it into the directory, rerun mkfdir, do cp fonts.dir fonts.scale, and if your adding a truetype font, go to XF86Config and change the fontpath. Or take the example of somebody getting DSL or such. People aren't stupid, at least 50% of users can handle clicking on preferences and changing their IP and gateway. Would you like to walk the same user through doing that in Linux?
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.
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.
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.
Yikes, at first I thought John Carmack was leaving id. Whoa, that'd be the day. One must admit, however, that the whole John thing is a little strange. John Romero, John Cash, John Carmack. Does that mean during the early days of id, all three people in the company were named John? Secondly, does anybody think Carmack will leave id eventually. A man does get tired of doing one thing. In interviews Carmack has shown himself to be pretty narrowly focused, but not closed to the idea of using his skills for other tasks. In fact, he's already done some stuff with porting X to Darwin and some stuff with graphics cards under linux.
Slashdot Mirror
DirectSound accelerators can push upwords of 96 channels to the hardware. It doesn't matter if the game will use all of it, what matters is that DirectSound does it BETTER than the equivilant under Linux.
I don't think there is an open implementation yet, though KDE did something called KOM. Yes, it does have 10 MS latency when doing local calls. For local calls, it is simple a pointer deference, as fast as a C++ virtual function call. Using DCOM (Distributed COM) you get all the cool network features you are talking about, (though I'm not sure if it does anything with clustering.) I have know clue where the Linux/*BSD/BeOS/AtheOS port is, but COM is fairly well documented, and it should be more or less trivial (for easier than the bloated Bonobo/Cobra crap GNOME is doing) to write an implementation for other OSs.
It exists. It' called COM.
I am surprised that this became a Linux vs Windows kind of thing. Windows is not even involved in this story. When a game developer writes on Windows, he would be stupid to use any more of Win32 than needed to create the window and delete the window. Most Windows games today are programmed in DirectX, which offers almost all the services needed by a game. Once one learns how to set up a windows and do some threads, almost everything else a game needs is done through calls to DirectX instead of OS calls. In addition to that, most games spend most of their time inside their own code anyway, so the OS has a negligible effect on performance, (assuming of course that the app has direct or near direct access to hardware). Som in reality the competition is Linux vs. DirectX. Quite an impressive showing on Linux's part, at least for now. DirectX (true to its name) has much less overhead that any OS ever could. I wonder, however, if this success is short-lived. Quake isn't exactly a service intensive game. Sound is pretty basic, as is input. They only thing that really matters in this case is the speed of 3D subsystem. Game, however, will eventually evolve, in particular using more sound. Some games (thief in particular) already do this. I really wonder if Linux can handle yet another subsystem that needs direct access to hardware. As 3D sound controllers become more complex (like Aureal's controllers) the OS will need a good way to get huge amounts of data and commands to the sound cards. In these types of games, Windows will keep trumping Linux. The main problem is that Linux doesn't have DirectX. In absense of that, it has no consistant API that pushes the OS out of the way and allows the game to take over the system. Take a look at the rest of the APIs. DirectSound, DirectInput, DirectDraw, and to some extent DirectPlay (for its flexibility) whoops anything availible on Linux. (Any Linux driver-hardware combo that allows 32 HW accelerated 3D sound streams in addition to 96 normal streams? Windows had that in the A3D 2.0 days.) What Linux really needs at this point is a DRI for the rest of the sub systems. Only then, will Linux become better than Windows for games. Some will say the current situation is enough. Linux is almost as good as windows, it performs almost as well. Almost will not cause anybody to switch, however. If Linux really is a technically superior system, it should be able to trounce windows, not merely equal it.
Ahh, its all clear now. I didn't realize you were talking about non-OS managed threads. I had the idea that you were saying BeOS and NT threads are resource intensive.
This is incorrect. Nothing in Unix says that threads must be lightweight processes, there
are many implementation possibilities. Solaris is the only design firmly in that camp.
Linux is actually quite the opposite, if I remember right, in that both processes and
threads are created with the same spawn system call.
>>>>>>>>
Actually, I believe that you have it reversed. I know Solaris uses their own implementation of threads, and that Linux uses POSIX threads. I have seen test results that show that POSIX threads take 10 times longer to create than NT threads (which take serveral times longer than BeOS threads), and the system slows down significantly at a much lower thread count than under NT and BeOS. (Both of which have nearly a hundred threads from bootup.)
Also, the (imho only) advantage of lightweight processes is that the the resources to
create a thread are far less than any object that the OS is aware of. This is exactly the
opposite of what you said.
>>>>>>>>
Actually, under most systems stuff like semaphores and locks take far less memory. The advantage of threads is two fold. First, the multiple paths allow multiprocessing, and second, they keep subsystems of a single program from having to on one another. This is a big help considering that fact that even the most basic PC these days has four processers, the I/O processor, the graphics processor, the sound chip, and the main CPU.
The problem with lightweight processes is that support requires complex libraries and
redundancy with the OS (which has to support multiple processes anyway) and requires
non-blocking versions of all system calls, which are much more complex (interesting
enough MicroSoft makes a big stink about their non-blocking support and their multi-
threading support, when realistically only one of these needs to be implemented!)
>>>>>>>>>>>
Threads and non-blocking systems calls are neither complex, nor terribly difficult. If the OS is designed from the core to support threads, (like BeOS and NT) multithreading naturally flows to the whole system.
As for the Win95 vs. Linux thing, I had no intent to glorify Windows in anyway. I was just repeating what I heard on the Linux.org FAQ about how Win95 is less susceptible to bad memory than Linux, mainly because it doesn't use the hardware as effectively. I never said anything about it being fault tolerent, I merely pointed out that there are differences between OSs that will allow one OS to run on marginal hardware while another will not. As for having no experiance with VMS, that experiance is unnecessary in this case. I said I have no idea if VMS can do that, but I am sure that some hypothetical OS exists that could do that, and VMS might be one of them. The person I was responding to thought that it did not matter what OS was running, that the HW as entirely at fault. I was just pointing out that in some cases, some OSs will keep running in places others won't. I never said that VMS was one of them, I just said it COULD be.
No, compressed postscript is just that, compressed postscript. PDF is an entirely new open standard that is heavily based in PostScript. It doesn't, however, carray a lot of the full fleged language capabilities of postscript, it has a better color matching model, and most importantly YOU DO NOT HAVE TO PAY ADOBE TO IMPLMENENT IT!
Because you're a nerd and have no asthetic sense.
(Whoa, put that keyboard down, just kidding!) Seriously though, people like pictures and icons and shiny things. If they didn't everyone would be using Motif. There is something to be said for asthetic appeal. People don't live in ugly houses, they don't like reading books with ugly formatting, they don't like reading magazines without lots of color and pictures. Humans are visual creatures used to seeing lots of color. A grey icon that says EMAIL might be efficient, but it would bother the hell out of some people. Second, it might not even be more efficiant. Often, when one gets a desktop organized just so, people can actually access things faster than by reading an icon. Once you have the icon memorized (through familiarity) it is processed by the pattern recognition part of the brain. This is significantly faster than sending it through the analytical part of the brain(mainly because humans don't do pattern recognition with plain, black characters). For me at least, I access icons on my desktop and BeMenu more by color and shape of icon rather than anything else. This is shown very well by the default helix GNOME menu. The icons for terminal and logout are the same shape. So my brain, (using shape before it reads the text of the icon) will often cause me to logout when I wanted to start a terminal.
Yes, it is partially hardware, but a great deal software. It shows that VMS can take much more flaky hardware errors than can UNIX. (It's true. Even Win95 is less susceptible to flaky hardware than Linux is. Some severly overclocked systems will run on Win95, but crash on Linux.) Take a PC running Win95 for example. If one shoots the harddrive, and the resultant shock sends a electric surge up and kills an I/O processor, more likely than not, a UNIX will crash. Another bullet-proof OS, for example, could handle an I/O processor going out in the middle of operation and still keep running. I have no experiance with VMS, so I don't know it can do that, but I think that's what the author was getting at.
Yo, COM is not without its merits. There is only a few major architectural differences between SOM and COM, the most important being that SOM supports direct inheritance, while COM doesn't. COM does something called aggregation which achieves the same effect. They support two different philosophies. SOM is slightly more fragile at the benifet of being more flexible, while COM is more resistant to base-class derived class interaction problems at the expense of requiring more programming effort to derive an object. I am of the mind that developers in general aren't responsible enough to do unchecked deriving, and that by making it less automatic in COM, the developer is required to have a clearer understanding of the interface between the base and derived class.
Actually, there are many open OSs that are not UNIX-like. My favorite (for reasons that will becomes obvious soon) is AtheOS. It is a project run by one person, but is actually progressing quite quickly. It even has hardware accelerated drivers for some Matrox cards. The best part is that its architecture was heavily influenced by BeOS, and its file system is basically a clone of BFS that he made using the book that the guy who wrote BFS published.
Actually it can, and they did. So did Win95 compared to win3.1
Actually, multitasking and multi threading have no relation to each other. Multi tasking is the ability to run more than one process. Multi-threading is the ability of one process to have multiple, simultanious paths of execution. Both OS/2 and Windows have the same multi-tasking/multi-threading model. For 32bit apps, both are preemptivly multitasked, and many parts of the OS and some apps are multi-threaded. Second, don't go dissing the Win95 process/thread model. It kicks UNIX's all over the place (not in security of course). Under UNIX, a thread is a lightweight process. As such, the scheduler is process oriented, and threads take much more time and resources to create under UNIX. Under OS/2, Windows, and BeOS, a thread is the smallest unit of sheduling, and are very lighweight in terms of resources and creation tim. Lastly, there is no such thing as "true multitasking." Hell, under any definition of mulitasking, DOS had multitasking (TSRs.) Win95, OS/2, BeOS, and Linux both employ something called preemptive multi-tasking, where the OS decides when an app should give up processing to another app. Under cooperative multi-tasking systems, like 16 bit Windows and MacOS 10, the application has to call a function to return control back to the OS so it can shedule another process.
*nix apps should compile, since OS X IS a UNIX.
It doesn't matter if it is or not, because Darwin isn't really supposed to be an OS in it's own right. Some people (namely Carmack) had an affinity for OSX and decided to contribute to its base OS. Aside from that, Darwin has some cool features, namely the kits.
Who says that a story posted on Slashdot has to have something to do with the furthering of Linux? Darwin looks pretty cool as an OS in its on right and has zilch to do with Linux. If anything, it's helping BSD gain wider acceptance. It's Darwin's spotlight, not Linux's.
But neither D3D nor OpenGL specify access to hardware or resource management! These are both implementation details, and
can be bad or good depending on who wrote the implementation
>>>
You cannot take that statement in a vacuum. Both OpenGL and D3D specify a significant number of implementation details, and it is a proven fact (go read some benchmarks circa 1996-7) that OpenGL was faster than D3D. Now take a look at current games that support both OpenGL and D3D. You'll see that they both run at about the same speed.
No game developer in their right mind would risk using a feature not implemented in hardware on most cards. Why would you
want to fall back to Microsoft's HAL? It's SLOW.
In this case, OpenGL is almost the same as D3D. Instead of being implemented by the HAL, unsupported features of OpenGL are
implemented by the vendor.
>>>>>>>>>
Take a closer look at my vertex skinning example. No matter what, the app will have to do vertex skinning (it's integral to many engines' animation capabilities.) In OpenGL, if you want to take advantage of hardware acceleration for skinning, you write 3 code paths, one for each case (software, nVidia, ATI). In D3D, you write one code path, (The D3D case) and D3D will take care of things. If you have to fall back to software, so be it, you'd have had to do that anyway, and if you have hardware, you get a nice speed increase. You say that unsupported featueres of OpenGL are supported by the vendor. That's the whole problem. In D3D, the core feature set is much larger, and unsupported features are emulated. Many of the newer extensions don't take a terrible speed hit if they are being emulated. Even if the speed hit IS that bad, D3D still comes out ahead. Take a hypothetical lighting feature that has not yet become an ARB extension. It is accelerated on two or three cards. In OpenGL, you'd have to support the case where HW acceleration is not available, in which case you'd disable the feature, the case where nVidia accelerates it, in which case you'd use the nVidia extensions, the case where ATI accelerates it, in which case you'd use the ATI extensions, etc. In D3D, you'd have two cases. If D3D reports that the feature is not being hardware accelerated, you disable it. Otherwise, leave it enabled. The best thing about this is that it takes advantage of new hardware AUTOMATICALLY.
This is entirely false. Both API's abstract access to vertex buffers, and provide direct access to frame buffers (depth, color). Do you
really thing that when you fill a vertex buffer in D3D that you are using the vertex format that will eventually get sent to the
card? Think again.
But what if the user is running on an S3 Virge? Heck, I guess he's out of luck! Time for the slow HAL to kick in! As a game
developer, you should know whether or not your neat little trick is actually running in hardware!
>>>>>
If he's running a virge, he is scewed anyway. Besides that fact, vertex skinning is done by most apps anyway. Hardware just makes it faster. We're not talking about stuff like texture mapping here. Most of the new features in cards can be done adequatly in software, but not to the level the developer would like. As such, glazing over these differences in hardware makes sense. Plus, you do know if the feature is being accelerated, that's what driver caps are for. If it is not accelerated, you can fall back to lower quality rendering, but even if you don't, the app will still WORK.
>>>>>>>>>>
Okay, niggly little point, you do not have direct access to vertex buffers in D3D, but you do have direct control. When you create a vertex buffer, it is a locked object like a screen buffer. The display driver can manage these much better than a program-space array like glVertexPointer uses. (Yes, I know about complied vertex arrays, but that's an extension.) Second, OpenGL does not give you direct access to buffers. I'm not talking about his glCopyPixels crap, I'm talking about a pointer to video memory. Believe it or not, there are a lot of cool things you can do with that. Under direct access, I also include control. I find it silly that there is nothing in the core open gl API like a vertex buffer object. Texture objects exist, and both are buffers that are uploaded to the card, so why the lack of one.
What about implementations that don't even load textures into a card's on-board memory? How will your
LoadThisTextureToVideoMemory work on a card without local video memory free? You'll get an error and will have to load it
into AGP anyway. Why not let the implementation take care of this minor detail
>>>>>>>>>>
If the card doesn't have local video memory free, you still have to load it into AGP memory. Under OpenGL, you have less control of the situation then under D3D. This is not a minor detail, it can get in the way of some nifty rendering styles. Say you are rendering a room with a strip of a certain texture down the middle. A lot of stuff in that area uses that texture, and it is critical that it stays in video memory at that time. However, it is not used for the rest of the room. Do you give it a really high texture priority? That way it stays in memory, but will eat lots of space while the rest of the room is rendering. You could reprioritize in the middle of the frame, but state changes are expensive. An API should not try to force a way of development on the developer. Why not give more low level control over stuff like this that can potentially be important?
Read up on auxilary buffers.
>>>>>>>>>
I have, and they are fairly useless. Most hardware implementations of OpenGL can't render accelerated to an auxilliary buffer. This is bad because it is a pretty nifty effect to render parts of the scene into a texture buffer. It looks really cool when rendering stuff like portals, mirrors, etc. In the future, it could be even more helpful. Rendering a 3D movie to a texture buffer, then using that as the source texture would look pretty cool.
Ah, in that case you would be, sysadmining? My point exactly.
Half you people have no clue whatsoever about what makes Windows easy to use. People could care less if the Windows interface is simple, or intuitive. It's easy to use because everyone uses it! The vast majority of people with any semblance of computer background are used to windows. Thus, KDE 1.x is easy mainly because it seems to be a Windows clone. Then you have the segment of the market that is totally new to computers. In that case, UNIX is way out of their ballpark. Sure they can wordprocess or whatever once everything is set up, but not everyone has a sysadmin. It is irrelevant on how easy to use the interface is in most cases. What matters is how easy to use the system is as a whole. Take something simple as adding new fonts. Even iMac people can do it, just drag it into the directory. In Linux, you have to put it into the directory, rerun mkfdir, do cp fonts.dir fonts.scale, and if your adding a truetype font, go to XF86Config and change the fontpath. Or take the example of somebody getting DSL or such. People aren't stupid, at least 50% of users can handle clicking on preferences and changing their IP and gateway. Would you like to walk the same user through doing that in Linux?
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.
Actually, if these were standardized on hardware, then the API would never evolve. No cubic environment mapping for you!
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.
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.
Yikes, at first I thought John Carmack was leaving id. Whoa, that'd be the day. One must admit, however, that the whole John thing is a little strange. John Romero, John Cash, John Carmack. Does that mean during the early days of id, all three people in the company were named John? Secondly, does anybody think Carmack will leave id eventually. A man does get tired of doing one thing. In interviews Carmack has shown himself to be pretty narrowly focused, but not closed to the idea of using his skills for other tasks. In fact, he's already done some stuff with porting X to Darwin and some stuff with graphics cards under linux.