In other words, if anyone starts threatening Linux with patents, they might find Nokia lawyers on their doorstep.
Almost but not quite, I think. I read this as saying, "If you use Linux (or possibly something else that may contain patents of Nokia's?) and you are threatening Linux development with your own patents, we'll set the dogs on your ass to sue you over our own patents."
Is Apple expected to maintain WebCore AND khtml??
on
Safari vs. KHTML
·
· Score: 1
Apple and the minors(appleusers) use KHTML-Webcore as an example of how great Apple works with the OSS comunnity when they don't in this particular case work with the OSS community at all.
I don't keep up with Apple stuff all that much, but I don't really remember ever seeing Apple brag about this close involvement with the OSS community on the HTML renderer. Can you give us some links or something?
Also, I'm not sure how much better they can work with the KDE guys on this. They're providing their patches. It's just not in a form that is extremely convenient for the KDE developers, it seems. That sounds like a problem for the KHTML maintainers to deal with. Why should the engineers at Apple be forced to maintain both WebCore and KHTML? It sort of sounds like that's what people are expecting of them.
In other words it runs a heck of a lot faster than doom 3.:)
This is partly due to the fact that ATI has historically had crappy OpenGL support in their drivers. They claim to be working on a new OpenGL implementation now, which is good news for everyone I think. I'm using NVIDIA hardware primarily because they support OpenGL well and they support Linux well, but I'd love to see some real competition for them in this area.
I've never owned a device like this, but two of the features that it lists on the page are:
Ultra-fast USB 2.0 transfers
Supports secure transfers from Windows Media Player(TM)
Does anyone know how easy it is to transfer music to it from Linux? My Nikon digital camera lets me mount it like a USB hard drive and just drag files over in Nautilus or whatever. Does anyone know if this music player can do something like that?
I do have Windows, with Media Player. But I don't want to boot over to Windows just to upload a couple songs.
http://www.justworldnews.org/ is a very interesting weblog by Helena Cobban. The blog seems to be primarily concerned with things of middle-eastern relation, but maybe that's just the way it's focused these days due to all the things going on there right now. Definitely a great website, and well worth keeping an eye on.
There is no reason why the vendors can't take the DX shader assembly code and reorder/optimize it for their card's strengths at the driver level. (NVidia and ATI both already do this).
But there is no longer a good reason to have this intermediate assembly. It only makes it more difficult for the IHVs to optimize their drivers.
Consider a hypothetical high-level shader function foo() that compiles into, say, six instructions in SM2.0 four instructions in SM3.0. For the driver to try to do some crazy-cool optimizations, it doesn't need to merely compile foo() but it needs to parse through the six instructions and sort of reverse-compile it to realize that it's something that can be optimized into a single low-level instruction.
(I don't really write compilers or drivers or anything, so I'm not sure if I'm describing this well or not. I hope it makes some sense.)
I agree with the other posters that the GLSL way could help with optimizations. However, given the problems I've had with ATI's drivers, I'm more than a little worried about the quality of ATI's shader compilation.:P
NVIDIA's is pretty good, but also isn't perfect yet. I think it's to be expected that neither one of them has gotten everything correct. We have to keep in mind that GLSL is still pretty new.
Anyone know if Doom 3 uses these newly ratified extension? I would imagine it does - but I of course have no facts to back this up.
I would not bet on it out of the box. I would probably bet against it.:)
That said, I do remember JohnC saying at some point that he is committed to doing a codepath for this, so it's extremely likely that it will appear in a future patch. I am very excited to see how it performs.
Of course, the philosophy of OpenGL is counter to DirectX in that there's no one Big Company controlling it all, but
at the very least, there needs to be some standard token bytecode defined and standarized by the ARB, and a reference compiler design, as well as a compliance suite to verify compiler correctness and language compliance.
I understand what you're saying, and it makes sense. But I will still respectfully disagree.
For one thing, GLSL is an incredibly easy language to compile compared to C++ or C#. That aside, 3Dlabs has written the source code to the GLSL compiler and released that source code for anyone to use, including competitors like ATI or NVIDIA.
But my main disagreement is with the idea of having an ARB-specified intermediate language. I already described my position in another post, so I won't repeat it all here.. but I think your position is short-sighted. I think allowing the IHVs to do the full compile/optimization stuff will provide them with greater flexibility and greater potential for innovation.
Re:What are people's opinion of comparisions
on
OpenGL Shading Language
·
· Score: 3, Insightful
In a way, I'd say it's more advanced thatn DirectX 9.0. At least in terms of shaders.
GLSL allows you to design things to be more modular. You can write multiple shaders (multiple vertex shaders, multiple fragment shaders) and then link them together into a single program object. This is a very good step in the right direction, I think.
Also, HLSL specifically compiles its code into a DirectX-specified shading assembly. Microsoft is controlling those, of course, so there's less room for innovation of compiler optimizations on the part of the hardware vendors. I think the OpenGL approach (define the language, not the underlying assemblies) is a better approach. Sadly, I think the hardware vendors will be locked into doing things the Microsoft way and this will also affect how the GLSL compilers work internally.
I found the Orange Book to be a very good introduction to GLSL, and I think it'll make for a good reference as I develop stuff. It does a good job of explaining how GLSL fits into the entire GL pipeline, which is cool because I don't know of any other books on OpenGL shader development that do this (It was hard to write a book on GL shaders before, and while GLSL is still ARB extensions, it's pretty clear that it's really targeted towards the core, while ARBvp1/ARBfp1 really seemed to just be placeholders until something really robust--GLSL--could come along).
I think that's one of the most interesting questions asked here today. Of course NVIDIA's biggest market right now is gaming, but that's not their only market. They've recently gotten into the business of film CG with their Gelato product, a hardware-accelerated finale-frame renderer for high-level graphics like that in film. Multiple GeForce 6800 Ultra video cards doesn't sound very useful for gamers, but multiple next-gen Quadro cards sounds extremely useful for a Gelato system, assuming that it will really take advantage of all the features of both boards.
Something that I'm really interested in knowing is how it compares to Alienware's Video Array technology. Video array suffers from the problem of being totally useless, because it only increases fillrate but it doesn't improve shader performance. Almost no game these days is fillrate-limited, but many games are limited by shader performances. I hope that NVIDIA's SLI solution is more interesting.
Obviously, the other big thing here is just to have another one-up over ATI.:)
The cpu wouldn't cost that much more, but any amount is a lot in this field. When Xbox came out, they were pretty much selling them at cost in order to compete. So even an extra $40 is a pretty large amount.
They would also need to come up with some crazy new motherboard component that can deal with both x86 and PPC hardware, and switch between them.
They would also have to develop the operating system and hardware drivers for both CPUs. They obviously already have it developed for PPC, and they have whatever iteration of the OS Xbox used developed for x86. But, still.. that would be a major task to sync them together and fully test it for both CPUs.
Re:Hmmm,. I wonder if it is very nVidia centric?
on
GPU Gems
·
· Score: 1
Good points, I guess I wasn't very clear in the beginning that what I didn't like about the book was the (imho) feel that they were intentionally making the book sound vendor neutral and part of the 'gems' series. It has value, just as Shader X does, as a reference for shading in general (because ideas are not language specific.) I'm sure it does have use, I just took issue with the presentation of the book as such.
Yeah, I understand. But at the same time, from their perspective as publishers and writers, it would be a poor move to put Cg or NVIDIA in the title of the book for a few reasons. If it makes it too obvious that it's NVIDIA-centric, too many people would think that it's only useful for NVIDIA hardware. Furthermore, if the title implied that the book was about the Cg language, we would have a lot of people complaining that the book says it's about writing in Cg, but doesn't have any information on the language itself, only complicated examples. So I guess there's no perfect solution here. They're damned if they do, and they're damned if they don't.:)
But I also don't think they tried to imply that they were part of "the gems series", because like I said before, there are already at least two existing 'gems' series. There was Graphics Gems by AP Professional, then Game Programming Gems by Charles River Media. I don't see any reason why they can't begin a new 'gems' series for shader development. Like the original review said (I think it was this review), shaders are really the perfect things to make into a 'gems' style book or series.
Re:Hmmm,. I wonder if it is very nVidia centric?
on
GPU Gems
·
· Score: 1
I think a book can be written about a topic that is not the language used to implement the topic of discussion. What this has to do with our discussion I don't know because you seem to think I have a problem with the fact that the book uses Cg to implement ideas, I do not.
You gave every indication before that you thought this book's content was not valuable, and it seemed that your reasoning was simply because it was written in Cg. From a previous post:
lol... Why did they bother to use Cg at all? There are books on HLSL and OSL that are more valuable than this one.
I don't know if we're talking about different things or what now, because much of what I was arguing (originally, before I got frustrated and off topic; for that, I'm sorry) was based upon these statements.
The other books that are about HLSL or GLSL are more valuable if what you're trying to do is learn how to write vertex and fragment shaders. For example, the OpenGL Orange Book is the best book if you want to learn how to write GLSL, and it's additionally very good for demonstrating some example shaders. But I don't think you could ever claim that it's a "gem" style book.
I have a problem with the fact that the book is presented as a Gems series type of book
How would you have presented it? It's a series of mostly independent ideas that can be roughly grouped together in sections. The Game Programming Gems books are the same.
written by an nVidia employee, entirely written using Cg rather than an open shader language such as GLSL, and because the title makes it sound like it is vendor neutral when it is anything but.
Okay, yeah. You're right. Although I hate to defend them on this particular count, because I do agree with you here, I can't help but point out that the book has an extremely obvious, fairly large NVIDIA logo on the cover, so I don't understand why it's that big of a surprise.:)
But, more importantly than that is that the sort of people this book is aimed at probably don't care that much. If they know anything at all about programming the 3d pipeline with vertex and fragment shaders, the NVIDIA-centric approach is a pretty insignificant thing to overcome. The fact is that in production environments, you end up writing the same shaders multiple times for the major vendors (ATI and NVIDIA at least) anyway, even when you're writing in a supposedly neutral language like HLSL.
My complaint in the previous message was not really in that you were calling it NVIDIA-centric, but that you seem to say that the book is about writing Cg, and it is not. That's why I say you're wrong and point out that nowhere in the book do they ever discuss the syntax of Cg, which they most certainly would do if they were trying to teach you Cg. My quote in that section of my last post should have removed the part about NVIDIA-centricity, but I was lazy and didn't do that. Sorry.
Assmasher - Actually the ATI drivers are pretty good, don't know about nVidia's drivers but I wouldn't expect them to work their tails off to kill Cg for you.
Some of the things we were working on had problems on the ATI drivers, and other things had problems on the NVIDIA drivers. Overall, I feel that both of them are beta quality but my feeling is that NVIDIA's will be superior in the long run. The main reasoning for this is because NVIDIA has a pretty sophisticated compiler system in the driver that has a single optimizing backend compiler, and three front-end compilers for the different highlevel languages. I think gcc does something similar to this, but I'm not positive since I've never really looked at their code. But since the three shader languages are not complicated in themselves, so I think the backend is the main important thing. With this new framework, GLSL is likely to perform just as well as Cg or HLSL, once the remaining kinks are worked ou
Re:Hmmm,. I wonder if it is very nVidia centric?
on
GPU Gems
·
· Score: 1
Actually, the guy who comes along and says "It should be called Programming games in C++" is correct. You seem to think it is pedantic to believe that many book titles seem to be misleading (even if only somewhat.)
I guess we'll just have to disagree on this one, because I think a book can be written about a topic that is not the language used to implement the topic of discussion. I don't believe every book needs to advertise on the title what language they use to implement the thing they're interested in discussing. I don't see anything wrong with it when a book does say "Doing such and such in C++", but usually those books are very interested in the details of implementing the topic in that language. There isn't a great deal of implementation detail differences between GLSL, HLSL, and Cg.
Yes, I'm absolutely aware of who the authors work for and I'm not naive in thinking that they did not pick the language because of that association with NVIDIA. But I just don't give a shit about that because the information that's contained in the book is so easily applicable to any other shading framework. I just think it's ridiculous to trash the book because you don't like the language. But I find it more likely that you just don't like NVIDIA for some fanboy sort of reason, and make silly remarks and assumptions for those reasons.
are VERY nVidia-centric) about how to write Cg
No, you're just wrong here. I own this book and have read it. It is not about the Cg language, but it uses it. It does not even contain a chapter on syntax for Cg or HLSL. There isn't even a fucking appendix chapter about language-specific details. You're just full of shit here, I'm sorry. If you buy David Eberly's "Game Physics" book, it includes source that is written in C++, but it does not teach you C++, nor does it try to. It is about game physics, not about the language.
given that it VERY explicitly claims to be (1)a Gems book when it isn't actually part of that series
Which series do you mean? You probably mean the "Game Programming Gems" series, which is published by Charles River Media. But they don't own the concept of a "gem" book, and in fact they were not the first ones to do that. There was a series before that called "Graphics Gems" that was published by Academic Press.
As for no one being able to use GLSL, you're obviously not very knowledgeable regarding GLSL. For instance, you can use GLSL with ATI cards as of 6 months ago. Early support was pretty damn sketchy, but 4.5+ Catalyst drivers are pretty good. Another example of your ignorance is that nVidia themselves have released drivers which support GLSL.
I'm well aware of the level of support by both NVIDIA and ATI, and so far I'm not fully satisfied by either of them yet, although I am very optimistic that support will improve shortly. I've been working a little bit with the beta drivers from NVIDIA, and they're not too bad at all, but they're not fully there yet. ATI had support for GLSL before NVIDIA, but theirs is farther behind NVIDIA's right now. 3Dlabs was the first to have drivers (for obvious reasons, being that they designed the language) and they are the only ones who have really robust, fully-implemented drivers. We have worked with the GLSL implementations from all three at work, so I'm enough aware of the quality levels of the three that I feel comfortable making statements about them.
That aside, at the time the book was being written then certainly 3Dlabs was the only vendor who had working GLSL drivers. It doesn't matter what level ATI and NVIDIA have now, the book isn't being written now.
Perhaps you should (1)learn how to discuss your differences in a more adult manner and (2)spend the 30 seconds on google to validate some of your more ridiculous assertions.
Have a nice day:). Great name by the way. I'm sure it is quite indicative of your personality.
It's a little amusing to see you claim I'm discussing things in a less than adult manner, then see you turn around and try to make some sort of insult based upon my username.:)
Re:Hmmm,. I wonder if it is very nVidia centric?
on
GPU Gems
·
· Score: 1
No, you're wrong. It's not about Cg programming. It's about the underlying algorithms and techniques. They had to choose languages to implement the techniques in, and it apparently happens to be the language you don't like. Oh, "boo hoo" for you!
This is a Gems book, written by numerous people. These people tell the editor, "Yeah, I have a cool GPU technique that would make a good 'gem' for the book." and they say, "Okay, give us an implementation." and that happens to be in either HLSL or Cg.
The fact is, there were a few options they had for how to implement the code. They could have implemented in Cg, GLSL, HLSL, or any number of assembly languages. If they used GLSL, they would ensure that nobody but 3Dlabs Wildcat users could test out any of the code at the time of publication. If they used the assemblies, they would ensure that nobody could just look at the code and understand what was going on. So using any high-level language is a superior choice over this. It just seems that they didn't pick the one that is your favorite, so you're whining like a little bitch.
If you see a book that claims to be about game programming, and it's written in C++.. then is that book about game programming in C++? Some other guy comes along and says, "That book should be called 'Programming games in C++'". Is he right, or is he a whiny little bitch because he doesn't like C++?
Re:Hmmm,. I wonder if it is very nVidia centric?
on
GPU Gems
·
· Score: 1
Fine, but this isn't a production environment. These are examples in a book. Your original statement is absolutely ridiculous.
lol... Why did they bother to use Cg at all? Could it be because nVidia is putting this book out? Some conflict of interest? Hehe. There are books on HLSL and OSL that are more valuable than this one.
This is the dumbest thing anyone has said about this book. The book is bad because you disagree with their choice of shading language? Hardware shaders are not complex things, and if you know anything at all about even one of them (HLSL, Cg, or GLSL) then you can look at source by any other one and understand what's going on.
The point of this book was to show some cool ideas for stuff that can be run using hardware pipeling programs. If the gems themselves sucked, then fine.. but their choice of implementation language has absolutely no impact on whether the gems suck, so I think you're just blowing smoke out of your ass and trying to talk trash about NVIDIA. If I was a moderator on Slashdot, I'd mark you down for trolling.
I bought Halo for PC, but I was disappointed in the port. I feel that it is a pretty shoddy product, and not very well polished. It doesn't seem very well optimized at all.
Like many, many other people I used to be a fan of Bungie until the Microsoft buy-out. Not to say I hold a grudge against Bungie.. you do what you have to do in order to make games the way you want to. I understand the business aspect of that, but it made me sad to see a game that was designed for PC and Mac get rewritten for console and then ported back to its original platform, and ported poorly.
To keep this post from being modded down too much for its off-topicness so far, I'll try to go back to the original topic a little bit here. I would say that the Gearbox PC port of Halo has hurt the credibility of the Halo series of games. I mean, I look at Grand Theft Auto and how great GTA3 and Vice City were and, despite certain criticisms I have of the PC ports, it almost makes me want to go buy a PS2 so I can play San Andreas when it comes out rather than wait a year for the PC version to come out. But after playing the PC version of Halo, I have zero desire to do anything like that for Xbox/Halo 2.
I think Doom 3 would be successful regardless of the name. For one thing, it's the next game engine by id Software. Everyone buys their games, if for no other reason than to see what the graphics are like. Each engine revision introduces a lot of innovation and creativity in terms of technical and graphical features. In addition, they have some absolutely amazing artists and animators working at id Software right now and it's already clear that the art and animation in Doom 3 will be the finest that has ever appeared in a game yet. The obvious areas of criticism will likely be the game length (it's already known that Doom 3 will be a fairly short game) and that it is deeply stuck in the traditional FPS style that was created by id Software. Their "start here, go here, and kill everything in the middle" gameplay is getting a little old to me, personally.
I think Half-Life 2 will be successful not purely on its name. Half-Life had no name to begin with, and the company that made it had no prior history. That was their first game, and it became one of the most successful games in history. They've had time to learn from their mistakes and do cool new things in this game.
Halo 2 I know nothing about. I have no interest in it since it will probably be an Xbox-only title, so perhaps someone here who finds Xbox interesting can give us some insight on the potential technical innovations for that game.
GTA: San Andreas. How can you make a statement one way or the other on this one at this point in time? They have yet to release any actual information on the game yet. We haven't seen any screenshots or feature lists or anything. If they're knocking the possibility of innovation based purely upon its name, then let's take a trip down memory lane and remember the differences between GTA and GTA2.. then GTA2 and GTA3 (clearly the biggest difference), then GTA3 to Vice City (not really a huge difference technically, but I think the gameplay was much improved and it was even more fun than GTA3 for most people). Anyway, the point is that without any information about what GTA:SA will be like, you have no room to knock it at all. They may have expanded this game to be a fucking huge region instead of a single city.
I won't buy the DVDs, because I personally think Star Wars sucks now. Partly because of the Special Edition, and partly just because now that I'm older I realize that they just weren't good movies to begin with. When I was a kid, I didn't know anything about acting or cinematography or anything, and I liked them. The only thing those movies had going for them was the nostalgia from childhood, and George ruined that.
If George had fixed minor flaws in the movie, that doesn't ruin the effect. But all this CG stuff looks so out of place in these old 70s/80s films. It definitely changes the feel of the movie.
The sad thing is that everyone will go out there and buy the DVDs, even though it seems like everyone hates the Special Edition. Bitching about how they suck is obviously not a clear message to Lucas. The only way to get the message through to them is to not buy the movies.
Slashdot Mirror
We'll make a GIMP for DNA, and rule the world! It'll run on more platforms too: all variants of primates, birds, farm animals, and Slashdot nerds. :)
Also, I'm not sure how much better they can work with the KDE guys on this. They're providing their patches. It's just not in a form that is extremely convenient for the KDE developers, it seems. That sounds like a problem for the KHTML maintainers to deal with. Why should the engineers at Apple be forced to maintain both WebCore and KHTML? It sort of sounds like that's what people are expecting of them.
This is partly due to the fact that ATI has historically had crappy OpenGL support in their drivers. They claim to be working on a new OpenGL implementation now, which is good news for everyone I think. I'm using NVIDIA hardware primarily because they support OpenGL well and they support Linux well, but I'd love to see some real competition for them in this area.
-
Ultra-fast USB 2.0 transfers
-
Supports secure transfers from Windows Media Player(TM)
Does anyone know how easy it is to transfer music to it from Linux? My Nikon digital camera lets me mount it like a USB hard drive and just drag files over in Nautilus or whatever. Does anyone know if this music player can do something like that? I do have Windows, with Media Player. But I don't want to boot over to Windows just to upload a couple songs.http://www.justworldnews.org/ is a very interesting weblog by Helena Cobban. The blog seems to be primarily concerned with things of middle-eastern relation, but maybe that's just the way it's focused these days due to all the things going on there right now. Definitely a great website, and well worth keeping an eye on.
Consider a hypothetical high-level shader function foo() that compiles into, say, six instructions in SM2.0 four instructions in SM3.0. For the driver to try to do some crazy-cool optimizations, it doesn't need to merely compile foo() but it needs to parse through the six instructions and sort of reverse-compile it to realize that it's something that can be optimized into a single low-level instruction.
(I don't really write compilers or drivers or anything, so I'm not sure if I'm describing this well or not. I hope it makes some sense.)
That said, I do remember JohnC saying at some point that he is committed to doing a codepath for this, so it's extremely likely that it will appear in a future patch. I am very excited to see how it performs.
For one thing, GLSL is an incredibly easy language to compile compared to C++ or C#. That aside, 3Dlabs has written the source code to the GLSL compiler and released that source code for anyone to use, including competitors like ATI or NVIDIA.
But my main disagreement is with the idea of having an ARB-specified intermediate language. I already described my position in another post, so I won't repeat it all here.. but I think your position is short-sighted. I think allowing the IHVs to do the full compile/optimization stuff will provide them with greater flexibility and greater potential for innovation.
In a way, I'd say it's more advanced thatn DirectX 9.0. At least in terms of shaders. GLSL allows you to design things to be more modular. You can write multiple shaders (multiple vertex shaders, multiple fragment shaders) and then link them together into a single program object. This is a very good step in the right direction, I think. Also, HLSL specifically compiles its code into a DirectX-specified shading assembly. Microsoft is controlling those, of course, so there's less room for innovation of compiler optimizations on the part of the hardware vendors. I think the OpenGL approach (define the language, not the underlying assemblies) is a better approach. Sadly, I think the hardware vendors will be locked into doing things the Microsoft way and this will also affect how the GLSL compilers work internally.
I found the Orange Book to be a very good introduction to GLSL, and I think it'll make for a good reference as I develop stuff. It does a good job of explaining how GLSL fits into the entire GL pipeline, which is cool because I don't know of any other books on OpenGL shader development that do this (It was hard to write a book on GL shaders before, and while GLSL is still ARB extensions, it's pretty clear that it's really targeted towards the core, while ARBvp1/ARBfp1 really seemed to just be placeholders until something really robust--GLSL--could come along).
Something that I'm really interested in knowing is how it compares to Alienware's Video Array technology. Video array suffers from the problem of being totally useless, because it only increases fillrate but it doesn't improve shader performance. Almost no game these days is fillrate-limited, but many games are limited by shader performances. I hope that NVIDIA's SLI solution is more interesting.
Obviously, the other big thing here is just to have another one-up over ATI. :)
They would also need to come up with some crazy new motherboard component that can deal with both x86 and PPC hardware, and switch between them.
They would also have to develop the operating system and hardware drivers for both CPUs. They obviously already have it developed for PPC, and they have whatever iteration of the OS Xbox used developed for x86. But, still.. that would be a major task to sync them together and fully test it for both CPUs.
But I also don't think they tried to imply that they were part of "the gems series", because like I said before, there are already at least two existing 'gems' series. There was Graphics Gems by AP Professional, then Game Programming Gems by Charles River Media. I don't see any reason why they can't begin a new 'gems' series for shader development. Like the original review said (I think it was this review), shaders are really the perfect things to make into a 'gems' style book or series.
You gave every indication before that you thought this book's content was not valuable, and it seemed that your reasoning was simply because it was written in Cg. From a previous post:
I don't know if we're talking about different things or what now, because much of what I was arguing (originally, before I got frustrated and off topic; for that, I'm sorry) was based upon these statements. The other books that are about HLSL or GLSL are more valuable if what you're trying to do is learn how to write vertex and fragment shaders. For example, the OpenGL Orange Book is the best book if you want to learn how to write GLSL, and it's additionally very good for demonstrating some example shaders. But I don't think you could ever claim that it's a "gem" style book.
How would you have presented it? It's a series of mostly independent ideas that can be roughly grouped together in sections. The Game Programming Gems books are the same.
Okay, yeah. You're right. Although I hate to defend them on this particular count, because I do agree with you here, I can't help but point out that the book has an extremely obvious, fairly large NVIDIA logo on the cover, so I don't understand why it's that big of a surprise. :)
But, more importantly than that is that the sort of people this book is aimed at probably don't care that much. If they know anything at all about programming the 3d pipeline with vertex and fragment shaders, the NVIDIA-centric approach is a pretty insignificant thing to overcome. The fact is that in production environments, you end up writing the same shaders multiple times for the major vendors (ATI and NVIDIA at least) anyway, even when you're writing in a supposedly neutral language like HLSL.
My complaint in the previous message was not really in that you were calling it NVIDIA-centric, but that you seem to say that the book is about writing Cg, and it is not. That's why I say you're wrong and point out that nowhere in the book do they ever discuss the syntax of Cg, which they most certainly would do if they were trying to teach you Cg. My quote in that section of my last post should have removed the part about NVIDIA-centricity, but I was lazy and didn't do that. Sorry.
Some of the things we were working on had problems on the ATI drivers, and other things had problems on the NVIDIA drivers. Overall, I feel that both of them are beta quality but my feeling is that NVIDIA's will be superior in the long run. The main reasoning for this is because NVIDIA has a pretty sophisticated compiler system in the driver that has a single optimizing backend compiler, and three front-end compilers for the different highlevel languages. I think gcc does something similar to this, but I'm not positive since I've never really looked at their code. But since the three shader languages are not complicated in themselves, so I think the backend is the main important thing. With this new framework, GLSL is likely to perform just as well as Cg or HLSL, once the remaining kinks are worked ou
This is a Gems book, written by numerous people. These people tell the editor, "Yeah, I have a cool GPU technique that would make a good 'gem' for the book." and they say, "Okay, give us an implementation." and that happens to be in either HLSL or Cg.
The fact is, there were a few options they had for how to implement the code. They could have implemented in Cg, GLSL, HLSL, or any number of assembly languages. If they used GLSL, they would ensure that nobody but 3Dlabs Wildcat users could test out any of the code at the time of publication. If they used the assemblies, they would ensure that nobody could just look at the code and understand what was going on. So using any high-level language is a superior choice over this. It just seems that they didn't pick the one that is your favorite, so you're whining like a little bitch.
If you see a book that claims to be about game programming, and it's written in C++.. then is that book about game programming in C++? Some other guy comes along and says, "That book should be called 'Programming games in C++'". Is he right, or is he a whiny little bitch because he doesn't like C++?
Like many, many other people I used to be a fan of Bungie until the Microsoft buy-out. Not to say I hold a grudge against Bungie.. you do what you have to do in order to make games the way you want to. I understand the business aspect of that, but it made me sad to see a game that was designed for PC and Mac get rewritten for console and then ported back to its original platform, and ported poorly.
To keep this post from being modded down too much for its off-topicness so far, I'll try to go back to the original topic a little bit here. I would say that the Gearbox PC port of Halo has hurt the credibility of the Halo series of games. I mean, I look at Grand Theft Auto and how great GTA3 and Vice City were and, despite certain criticisms I have of the PC ports, it almost makes me want to go buy a PS2 so I can play San Andreas when it comes out rather than wait a year for the PC version to come out. But after playing the PC version of Halo, I have zero desire to do anything like that for Xbox/Halo 2.
I think Half-Life 2 will be successful not purely on its name. Half-Life had no name to begin with, and the company that made it had no prior history. That was their first game, and it became one of the most successful games in history. They've had time to learn from their mistakes and do cool new things in this game.
Halo 2 I know nothing about. I have no interest in it since it will probably be an Xbox-only title, so perhaps someone here who finds Xbox interesting can give us some insight on the potential technical innovations for that game.
GTA: San Andreas. How can you make a statement one way or the other on this one at this point in time? They have yet to release any actual information on the game yet. We haven't seen any screenshots or feature lists or anything. If they're knocking the possibility of innovation based purely upon its name, then let's take a trip down memory lane and remember the differences between GTA and GTA2.. then GTA2 and GTA3 (clearly the biggest difference), then GTA3 to Vice City (not really a huge difference technically, but I think the gameplay was much improved and it was even more fun than GTA3 for most people). Anyway, the point is that without any information about what GTA:SA will be like, you have no room to knock it at all. They may have expanded this game to be a fucking huge region instead of a single city.
I won't buy the DVDs, because I personally think Star Wars sucks now. Partly because of the Special Edition, and partly just because now that I'm older I realize that they just weren't good movies to begin with. When I was a kid, I didn't know anything about acting or cinematography or anything, and I liked them. The only thing those movies had going for them was the nostalgia from childhood, and George ruined that.
If George had fixed minor flaws in the movie, that doesn't ruin the effect. But all this CG stuff looks so out of place in these old 70s/80s films. It definitely changes the feel of the movie.
The sad thing is that everyone will go out there and buy the DVDs, even though it seems like everyone hates the Special Edition. Bitching about how they suck is obviously not a clear message to Lucas. The only way to get the message through to them is to not buy the movies.
It's a bad game, dude. Deal with it. You get a Pentium 4 3.2GHz with a Radeon 9800 XT and this game is still going to be shit.
I'm trying to figure out what the fuck your post has to do with anything I said, and I'm getting nowhere.
So tell me.. what does your post have to do with anything I said?