I was doing 3D games for PC around 10 years ago and well, I need to refresh and update my knowledge We were working on openGL 1.2 with 1.3 being the "cutting edge version we should not use because only high end machines have it installed" I was learning openGL via NeHe tutorials, I know RedBook rather well, I think I looked through BlueBook too. GreenBook and OrangeBook were not existing in my times. I have read the history overview here: http://en.wikipedia.org/wiki/OpenGL (althrough I simply don't know most of the terminology after 1.3 since these things were not invented when I was learning openGL, but I overall know what a shader is, these were just about to be introduced when I quit 3D). I plan of doing only very basic things in OpenGL, I don't have the resources to make a full fledged 3D games anymore anyway, so things like how to make the texture appear super cool does not interest me too much (althrough, it would be still nice to know ).

Questions:1) Is the information in RedBook still valid? Will the old code still work (I read somewhere about removed glBegin/glEnd, is that true?)2) Can you drop me an example code of the simpliest method to draw a textured triangle (or a cube)?3) What is the current minimum safe to use (guaranteed to be installed on lower end machines) OpenGL version for PC (Windows XP SP2, DirectX 9.0c)?4) What is the current minimum safe to use (guaranteed to be installed on lower end machines) OpenGL version for Mobiles Android/iPhone)?5) What is the current best tutorial for learning openGL (preferably something that is chaptered well, so I can notice what i already know and don't need to read and what is "new"?6) Anything else I should know?

The latest edition of the Redbook is ok (but doesn't cover the latest versions of OpenGL), however if you're referring the old free version then its too old.

The biggest change in OpenGL is the move from the fixed function pipeline to the programmable pipeline (mostly in OpenGL 2.0).

I'd say currently a good target to learn these days is OpenGL 2.1 as you can use the programmable pipeline and work on most cards, any graphics card released in the last half decade should support it. Once you learn the programmable pipeline further OpenGL versions after that are mostly small incremental evolutions, unlike the the drastic change from the fixed function pipeline.

For mobiles OpenGL ES2 is used alot which is largely based on OpenGL 2.1 (with some bits missing).

Example to draw a triangle can be found in the above book and is likely to use VBO's with shaders. The programmable pipeline has a higher initial learning curve than that of the old fixed function pipeline, however its much more efficient and faster.

OpenGL is ridiculously backward compatible, and the code in the Red Book will compile and run with no problems (mind you it's C, but once you port it to java, the API will work). All the deprecated functionality is still there in backward-compatible contexts, which is the context you get by default.

As for what versions you want to target, it really depends on your intended platform, and there's a lot of variables to take into account there. Rule of thumb is OpenGL 1.4 for low-spec "casual game" platforms and 2.1 for anything using shaders (shaders might be supported on <2.0 as an extension, but are likely to be so quirky that you won't want to use them at all).

The path for learning OpenGL is a bit of a dilemma: if you're at all targeting lower-end platforms (which includes 90% of game engines I might add, where "low-end" is any OpenGL version before 3.2) you'll need to know the fixed-function pipeline. Otherwise, kappa's recommendation is good for an online resource. If you're planning on buying a book, the OpenGL SuperBible is excellent: the fourth edition covers fixed function and a bit of shaders, and the fifth edition is all modern OpenGL with no fixed-function at all.

How is removing almost all fixed functionality a "small incremental evolution"? >_>

Until OpenGL 3 they just kept on adding stuff while keeping full backwards compatibility. I believe everything except GL_POLYGON_SMOOTH still works, and driver support isn't going away anytime soon. However, shaders have evolved to a point where almost all fixed functionality has become unnecessary since it can be done with shaders. Alpha testing is just a call to "discard;" in the fragment shader, shadow mapping is just a shader comparing z-values, e.t.c, so in OpenGL 3 they "deprecated" everything that could be replaced with shaders or could be done more effectively using newer OpenGL features.

Examples of things that were deprecated: - The fixed functionality pipeline (e.g. you can't render anything without a shader) - Multitexturing without shaders - glBegin-glEnd and sending vertex attributes one at a time, replaced by Vertex Buffer Objects - Alpha testing - Point and line smoothing

Many things are still there though, like blending, and depth and stencil testing. Anyway, OpenGL 2 is the way to go if you're masochistic enough to enjoy supporting hardware which best-before date was several years ago, but I'd recommend going for OpenGL 3 because the API is cleaner and it's so much easier to keep track of the OpenGL state. Well, I guess it depends on what you're doing. For 2D, OpenGL 2 is probably fine.

I still target OpenGL 1.2. theagentd has better skills in shaders than me, I sometimes waste some time with engines mixing fixed and programmable pipelines. Some things that should work just cause an OpenGL error (invalid enumerant) Shaders are difficult to use, you often have to program several versions of the same shader, it is quite difficult to debug. I don't know if you plan to use a 3D engine, none really provides the support of fixed and programmable pipelines, Ardor3D mixes both, JMonkeyEngine 3 relies much more on shaders.

I still target OpenGL 1.2. theagentd has better skills in shaders than me, I sometimes waste some time with engines mixing fixed and programmable pipelines. Some things that should work just cause an OpenGL error (invalid enumerant) Shaders are difficult to use, you often have to program several versions of the same shader, it is quite difficult to debug. I don't know if you plan to use a 3D engine, none really provides the support of fixed and programmable pipelines, Ardor3D mixes both, JMonkeyEngine 3 relies much more on shaders.

You can load more than one of each shader type for each program, so it's possible to split up functionality between shader source files. You can also define a function without actually writing the code for it (like a Java interface) and then put that code in a different file. That way you can create an uber-shader which just calls a number of "abstract" functions (like transform(...), skin(...), e.t.c). If you don't want a certain functionality in a certain shader, just define that method as an empty method. When linking everything is inlined anyway, so there's no performance impact.

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.Actual debuggin is easy becouse I can allways first check is vertex shader ok and just draw red or or normals. If there are no problems with vertex shader then I just test every part individally and its really easy. Usually I found my errors when shader do not work inside of java code and its allways some openGL state that is wrong. Shaders are really easy becouse those are short and compact code that is stateless.

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.Actual debuggin is easy becouse I can allways first check is vertex shader ok and just draw red or or normals. If there are no problems with vertex shader then I just test every part individally and its really easy. Usually I found my errors when shader do not work inside of java code and its allways some openGL state that is wrong. Shaders are really easy becouse those are short and compact code that is stateless.

True, and there's a lot less OpenGL state to worry about. God, I've forgotten glEnable(GL_TEXTURE_2D) so many times...

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.

What IDE are you using which tells you that your shaders don't compile?

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.

What IDE are you using which tells you that your shaders don't compile?

Just try to compile it with OpenGL normally, and then query for the error log, which tells you where the error occurred, e.t.c.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org