quick question about OpenGL,
Members - Reputation: 1475
Posted 21 September 2012 - 11:11 AM
Is the same true for directx?
Members - Reputation: 1104
Posted 21 September 2012 - 12:56 PM
Old OpenGL books/tutorials are still somewhat useful (the math part didn't really change), but I would recommend learning modern OpenGL, because that will help you leverage the true power of modern hardware.
Visit the OpenGL forum here on gamedev; There are many links there which lead to really useful, modern tutorials.
I really like this one: http://www.arcsynthesis.org/gltut/
Members - Reputation: 569
Posted 21 September 2012 - 12:58 PM
I read on some recent thread that OpenGL is backwards compatible with obsolete code? So that means if I were to pick up a book from 7-8 years ago, the code would still run without any tweaking on the newer version of OpenGL?
Don't count on it. New functionality in OpenGL often comes in via extensions. Often, the extensions were such a good idea they were then adopted into the core profile in the next version and whatever was the common practice prior has often been deprecated and won't work unless you specifically choose a version or a legacy compatibility mode.
There's so much OpenGL reference out there that it's actually quite easy to be looking at an older example and not realizing why it won't work. A good example of this would be based on vertex data. The original methods were dropped a long time ago and just about everyone knows that, but things like vertex buffer objects were still optional at that point, yet by 3.X were mandatory. A lot of 2.X examples will compile under 3.X, but won't work...and there are an awful lot of examples out there that are 2.X but not obviously so. To add to the confusion, you'll find a lot of reference where people think they are talking about vertex buffer objects but are actually talking about the predecessor. Then you've got the idea that the internet is also littered (due to the boom in mobile development) with current Open GL ES examples, which might work in 2.X but not in 3.X for the same reasons.
For OpenGL, make sure you have the latest references and if you go looking for examples, try and ascertain the version. Also read the spec, but bear in mind a few key things are described sometimes in just one not very obvious sentence in the open gl spec. RTFM doesn't always apply with open gl due to non-obviousness, even if the information is actually there.
Is the same true for directx?
To some extent yes, but largely no.
For starters, DirectX doesn't have the problem introduced by mobile/ES.
I'd also say that generally, it's a little more obvious when looking at DirectX code which version you're looking at. A lot of this has to do with the idea DX9 was prevalent for a long time and a lot of the examples of DX10/11 are not only flagged as such but also do have some obvious differences and as yewbie mentions, many of the newer features force a differing implementation in the surrounding code. This is very much different to the Open GL vertex buffer objects examples I mentioned above, which look very similar between versions, often with the same function call being used with the only difference being one parameter.
DirectX may at least in part suffer the same problem over time - we could find ourselves in a position at some point where the wealth of DX9 examples are nothing other than misleading.
I think at some point, were going to need some sort of internet command to delete old information or search engines that filter/age out results more intelligently. We'll also be much more thankful of things like Wiki's too - where someone else will come and delete whatever old example I posted 25 years before I died.
Edited by freakchild, 21 September 2012 - 01:11 PM.
Crossbones+ - Reputation: 5838
Posted 24 September 2012 - 02:24 PM
Note through that it is not recommended for performance reasons, but if you just need to code something small and don't care about the best speed possible, there is no problem at all, you can just copy/paste your ancient code.
As for DX that's definitely not true.