I don't know, but some businesses do. I know id has no such guarenteed contract, yet they not only release all their games natively on Linux, but release the source code of all but their latest generation.
True, but I would argue that id does have a reasonable assurance of profit from their Linux efforts. First off, id still uses OpenGL, so the graphics engine is pretty much cross-platform, with possibly some small exceptions in the world of extensions. The windowing system used is typically just plain Win32, and there isn't that much code involved (when viewed in the scope of the entire engine), so when id goes to port, they just use the SDL on Linux and call it good. What I'm trying to point out here is that id puts forth maybe 0.001% of their overall coding into porting the engine from windows to linux. Since I bet (and I'm sure id bets) Linux people enjoy gaming as much as windows people, and Linux has more than a 0.001% desktop share, id is pretty comfortable with the assertion that the Linux port will draw revenue, even though they have no guarantee (and heck, for that matter, id doesn't have a guarantee of their windows games selling either, but they do have a reasonable assurance).
As for the source code release, can't argue there. The one point I would make though is that nVidia licenses some of their driver code, and thus cannot release all of their source code. Also, nVidia makes their money off of selling their hardware design (I've never seen an nVidia brand card, only a third party card with an nVidia GPU), while id makes money off of licensing their newest engine. nVidia builds off of its old hardware, where as Carmack has admitted several times that his team starts from scratch. Thus, nVidia giving away specs of their older hardware is not quite the same as id giving away its old source code.
This article hits and misses
on
The SLI Godfather
·
· Score: 4, Interesting
Yes, of course, nVidia isn't going to spend time developing drivers for 0.01% of their customer base. The reason why Linux has any support at all is because nVidia sees it as a growing market, and because the drivers for Windows and Linux share 98% of their code. This isn't true of other platforms. Look at the Mac for example, their driver interface is completely different than that of Windows or Linux, which is why it takes longer (even though they have a somewhat full team of engineers for the Mac).
For the Linux drivers, the engineers simply say "what do we need more urgently, these bug fixes, or these features?" If they need the features, they borrow the code from Windows and put it in, with possibly some minor glue code. With other platforms, some poor engineer has to learn enough about that one particular OS to get a driver working. Again, how does diverting this portion of time equate to revenue for ATI without a guaranteed contract from the hardware vendor? It doesn't.
nVidia has a steady stream of revenue from Windows users (gamers and casual users) and Linux users (research and education), but the same is not always true of other manufacturers like HP, Sun, etc. And again, why would a business invest their time and money if they don't have a reasonable assurance of profit?
Yes, you could just allocate a huge array, but that has some problems:
1) Possibly slow/complex initalization
2) Difficult to take advantage of OO
3) Unlike in C++, the bytes in the array couldn't be easily made into a reference to a Java object (you'd have to use JNI)
The first isn't as difficult/complex in a programmer managed memory space (as in C++ with the placement new operator). The second is the entire reason why you would use Java in the first place. So yes, it could be done almost the same way, but it would have some major drawbacks.
I've always had the philosophy, "use what makes the job easiest." Typically, this involves garbage-collection. However, one of the biggest problems I have with garbage collection is that you can't have your cake and eat it too. Meaning, you can get all the memory you want, but you can only access it at a high level (think Objects in Java). In C/C++ however, you can call malloc/new, create a big pool of memory (or just a single object), and then do whatever the heck you want with it. But again, as the subject says, it all depends on which method helps get the job done, and so far neither has been perfect for everything.
Slashdot Mirror
Or is the NHTSA a newly hated acronym. National Highway Traffic Safety Asministration
True, but I would argue that id does have a reasonable assurance of profit from their Linux efforts. First off, id still uses OpenGL, so the graphics engine is pretty much cross-platform, with possibly some small exceptions in the world of extensions. The windowing system used is typically just plain Win32, and there isn't that much code involved (when viewed in the scope of the entire engine), so when id goes to port, they just use the SDL on Linux and call it good. What I'm trying to point out here is that id puts forth maybe 0.001% of their overall coding into porting the engine from windows to linux. Since I bet (and I'm sure id bets) Linux people enjoy gaming as much as windows people, and Linux has more than a 0.001% desktop share, id is pretty comfortable with the assertion that the Linux port will draw revenue, even though they have no guarantee (and heck, for that matter, id doesn't have a guarantee of their windows games selling either, but they do have a reasonable assurance).
As for the source code release, can't argue there. The one point I would make though is that nVidia licenses some of their driver code, and thus cannot release all of their source code. Also, nVidia makes their money off of selling their hardware design (I've never seen an nVidia brand card, only a third party card with an nVidia GPU), while id makes money off of licensing their newest engine. nVidia builds off of its old hardware, where as Carmack has admitted several times that his team starts from scratch. Thus, nVidia giving away specs of their older hardware is not quite the same as id giving away its old source code.
For the Linux drivers, the engineers simply say "what do we need more urgently, these bug fixes, or these features?" If they need the features, they borrow the code from Windows and put it in, with possibly some minor glue code. With other platforms, some poor engineer has to learn enough about that one particular OS to get a driver working. Again, how does diverting this portion of time equate to revenue for ATI without a guaranteed contract from the hardware vendor? It doesn't.
nVidia has a steady stream of revenue from Windows users (gamers and casual users) and Linux users (research and education), but the same is not always true of other manufacturers like HP, Sun, etc. And again, why would a business invest their time and money if they don't have a reasonable assurance of profit?
That's why there's fluxbox
1) Possibly slow/complex initalization
2) Difficult to take advantage of OO
3) Unlike in C++, the bytes in the array couldn't be easily made into a reference to a Java object (you'd have to use JNI)
The first isn't as difficult/complex in a programmer managed memory space (as in C++ with the placement new operator). The second is the entire reason why you would use Java in the first place. So yes, it could be done almost the same way, but it would have some major drawbacks.
I've always had the philosophy, "use what makes the job easiest." Typically, this involves garbage-collection. However, one of the biggest problems I have with garbage collection is that you can't have your cake and eat it too. Meaning, you can get all the memory you want, but you can only access it at a high level (think Objects in Java). In C/C++ however, you can call malloc/new, create a big pool of memory (or just a single object), and then do whatever the heck you want with it. But again, as the subject says, it all depends on which method helps get the job done, and so far neither has been perfect for everything.
Why do Texans insist upon finding every place possible to put an engine?