First of all i dont really understand all these updates and modern OpenGL. I was studying OpenGL in college and we used old deprecated stuff. After some time i come back to it and i see lot of changes. I've seen glfw glew but not used them and im really confused what is what and what to start learning. Also, since i dont plan on using fancy shaders on my programs can i continue with plain old OpenGL ?

OpenGL 3.0 introduced what's called the "Core profile" that deprecates all of the fixed-pipeline functionality and state tracking. Some platforms require the use of it in order to use the "modern" OpenGL functionality like geometry shaders, etc. That said you can us the "Compatibility profile" and it's like nothing ever happened.^^

I would suggest learning the "modern" methods as they allow for so much more freedom and will let you play with the new hotness should you be ever be so inclined!^^ (Not to mention MUCH more performant)

http://www.arcsynthesis.org/gltut/

http://www.opengl-tutorial.org/

Those may help^^

Adaptation of the codes of 2000 to Visual C++ MS VS pro 2010-2012: NeHe's demo and codes OpenGL summary

I've seen glfw glew but not used them and im really confused what is what and what to start learning.

Thous are not OpenGL, per-se, they are there just to help you with some of the mundane tasks related to opengl. Most importantly - a crap-ton of boilerplate code to expose all the available/requested functions/enums for you.

Just read a bit about them and pick one you like - knowing that it is fairly easy to change your mind later on.

Also, there is a bit of truth in saying that the OGL3.3+ way (without backwards compatibility) is easier to work with than the old ways even when you do not need any of the new features - although the entry fee, if i may say so, is a bit higher. The mentioned http://www.arcsynthesis.org/gltut/ is great help there (at least read the "About this Book" part to know what you get yourself into).

Although at least one very major person from one very major manufacturer disagrees with my opinon, I suggest not using deprecated functionality. The reason is that as a beginner, it is not immediately obvious for you which deprecated functionality is well-supported in hardware and what isn't. On the other hand, once you have climbed over the -- admittedly high -- entry barrier (like, having to type 100 lines of code to produce the first triangle), core functionality isn't any harder than using deprecated features.

Also despite vendors currently promising not to do this any time soon, one day the deprecated functionality will be removed. Nor can you rely that while maybe one or two vendors will keep supporting deprecated functionality, in fact all of them will.

Indeed, I would wish for manufacturers to drop deprecated functionality in favor of making core functionality better and faster, and making drivers smaller, less complicated, and bug-free.

For the record, here is what Mark Kilgard has to say about it:

OpenGL 3.1 introduced notion of “core” profile

Idea was remove stuff from core to make OpenGL “good-er”

• Well-intentioned perhaps but...
• Throws API backward
• compatibility out the window

Lots of useful functionality got removed that is in fast hardware

• Examples: Polygon mode, line width

Lots of easy-to-use, effective API got labeled deprecated

• Immediate mode
• Display lists

Best advice for real developers

• Simply use the “compatibility” profile
• Easiest course of action

Requesting the core profile requires special context creation gymnastics

• Avoids the frustration of “they decided to remove what??”
• Allows you to use existing OpenGL libraries and code easily

•No, your program won’t go faster for using the “core” profile

• It may go slower because of extra “is this allowed to work?” checks

Source: GTC 2010 session, OpenGL Version 4.3 is here

Imo todays opengl is 'overstuffed' for small 'indie' games,

It is good for big comercial games (like for example "nail'd"

game i play recent whole week) with heavy heavy tons

of geometry and coloring - but much heavy for small fckn* indie

games

Imo todays opengl is 'overstuffed' for small 'indie' games,

It is good for big comercial games (like for example "nail'd"

game i play recent whole week) with heavy heavy tons

of geometry and coloring - but much heavy for small fckn* indie

games

I don't know... while OpenGL 3.x or 4.x is a real pain to get working at all, it is actually a lot easier than the old versions... once you're over that initial hurdle.

There are no obscure limits, and the limits that do exist are so big that you will likely never run into them (unless you write something like FarCry 3). There is, at least in theory, no struggling about what special feature that you need a particular graphics card supports and doesn't support, and which extension you need to load, and what fallback strategy if that doesn't work. Because, behold, everything that you reasonably need just works.

Also, even indie games nowadays have much higher geometry demands (think Minecraft) than immediate mode can reasonably deliver. Sure, it won't make much of a difference if you write a side scroller like Flappy Birds, which is basically a dozen textured quads. But it makes a huge difference for everything else.

Even for quite "simple" 2D games which "only" draw a few hundred tiles or textured quads (think "diamonds" or "frozen bubble" or a graphical roguelike or dwarf-fortress-alike), instancing and array textures may be big win both for performance and ease of implementation.