Kind of stuck in learning.

Your graphics card doesn't support which version of OpenGL? What leads you to believe that your video card doesn't support it?

SFML is an excellent 2D C++ library.

You would need fairly ancient hardware to not have at least some support for GLSL. I can even do OpenGL2.1 on my netbook with crappy intel GMA graphics.

Can't you run openGL is software like you can with Direct3D ? Correct me if i'm wrong.

Err, even my old 10 year old machine with integrated graphics that came out a few years earlier than that supports openGL (an older version but still it supports openGL)

If you're a beginner, I suggest not diving into OpenGL or even DirectX, just yet. Learn the native drawing API of your system or tool first. If you're using any of Microsoft Express editions, jump into GDI+ (or even GDI). Otherwise, there's Qt, which has their own QPainter class that makes those calls internally for you. At the least, it guarantees it will run without a dependency on the OpenGL or DirectX libraries.

If you are set on using C++ and feel confident in that language, look into doing some 2D game programming with SDL or SFML. I'm sure your computer would be able to handle both of those libraries. SDL is fun, easy to learn and software accelerated. Later down the road if you end up with a computer that actually CAN handle OpenGL, you can use OpenGL to do all the rendering with SDL or SFML to handle the user input, etc..

So I would get familiar with SDL/SFML, since later you can and OpenGL to either one of those. It's probably a better idea than jumping straight into OpenGL in all honesty. I wouldn't recommend that for beginners.

If you aren't so set on using C++, I would look into learning Python with Pygame for 2D game programming if you're just starting out.

I mean it supports up to 2.1, but I don't want to waste time learning deprecated stuff. I made a snake game using SFML and OpenGL. Now I want to learn the new stuff, but unfortunately, my poor graphics card doesn't support it.

Well, make a more advanced 2D game with SFML then. How about a turn-based strategy?

Or, use a 3D engine that supports older OpenGL stuff - you won't have to learn outdated OpenGL, but you'll still get to mess around with 3D, you'll still get to make a cool game, and you'll still learn alot.

For what it's worth, learning the deprecated stuff won't necessarily be wasted time. Many of the concepts transfer over directly; most of the differences come in the application of those concepts. It is not as if GL3+ is any kind of radical departure from deprecated GL. The basic ideas have been there for a long time.

Thanks, people. I'll try to make some more advanced games. And maybe I'll look at the old redbook again when I'm bored. Learning the history will do more good than harm

everyone has great suggestions and ideas in response to your query. I wanted to point out that for many of us, we got started pre-opengl and during the early opengl. the reality is that opengl is the same that it has always been, as far as the bare minimum functionality is concerned. GLSL is only a newer part of opengl that gives programmers control over the newer GPU-programming functionalities, but it's all performed within the context of what opengl has always been. your sub-standard hardware is plenty for a beginner.

as opposed to making suggestions about what I think you should do, I'm just going to tell you that my personal experience was by mere chance guided into getting into opengl instead of direct3d, there was no rhyme or reason, but I am happy because seemingly all 3D-capable devices have some form of opengl support (whereas d3d is the exact opposite, with the exception of what I imagine to be some similar form of it on the xbox).

'opengl programming tutorials' is/are all you need, both literally, and as a google search term. I discovered nehe.gamedev.net a lifetime ago and off I went writing native win32 applications that utilized opengl. it wasn't until much later that I began using a cross-platform library, which came to be SDL, the most decent one at the time (for my needs).

there is SFML, I recently began familiarizing myself with the library's API documentation as it appeared to have such a clean and concise implementation, began a sort of practice project with it, only to find that it required some further external libraries to actually be used by my program which were not included - a personal pet peve of mine as far as software development is concerned.. these sorts of 'issues' are known as EXTERNAL DEPENDENCIES, and I hate them passionately, including all programs and programmers that RELY on them incessantly without any regard toward the end-user's experience and/or overall performance degradation that may result from them. It takes a real programmer to write quality software, and 'quality software' entails producing an OPTIMAL experience to the user.

nowadays I've resorted to hand-writing native code for each platform, basically for the reason that I simply do not trust anybody - including other programmers and their widely-varying abilities, and it's bad enough that my code runs in an operating environment that I have little to no idea what it may be doing behind the scenes *really*, there's simply no need for me to further complicate things with library API learning curves and the unpredictable issues that will only be layered ontop of the inherent and/or existing ones that development will burden me with.

but that's just me, and I felt my 2 cents were about due around here.

there is SFML, I recently began familiarizing myself with the library's API documentation [...] only to find that it required some further external libraries to actually be used by my program which were not included [...] these sorts of 'issues' are known as EXTERNAL DEPENDENCIES, and I hate them passionately

Perhaps you downloaded the wrong build? Yes SFML requires a few 3rd party libraries (better than it re-inventing the wheel!), but it includes those with the SFML libraries... you don't have to go hunting for them.

The dependencies (if building SFML from source) are: freetype, glew, libjpeg, openal32, libsndfile
libsndfile-1.dll and openal32.dll are the only things that need to be distributed with the SFML DLLs, the others being statically linked to the SFML libraries.

[size=2][/off-topic]

I mean it supports up to 2.1, but I don't want to waste time learning deprecated stuff. I made a snake game using SFML and OpenGL. Now I want to learn the new stuff, but unfortunately, my poor graphics card doesn't support it.

You can still learn a lot about OpenGL with a 2.1 implementation. If you haven't learned GLSL, you can still do quite a bit with with the 1.2 version that will be trivial to port to modern versions.

Maybe it's a stupid suggestion, but computers, especially 1-2 year old models are not expensive (you don't even have to buy a new monitor if you already have one). It's even affordable with saved lunch-money.
So maybe you could update your machine.

So maybe you could update your machine

I agree. Otherwise you are really soon going to be bored with slow compilations, etc.

The reason I can't update it is that I'm just a high school sophomore who doesn't have a single penny

I bought my own computer when I was 12. Had a paper route, saved my money, bam.

We'll then perfect opportunity to look into this!

http://www.raspberrypi.org/

Supports OpenGL ES and its only 25 bucks and runs Linux..

[EDIT : Or you can just pick up an old Android device which supports OpenGL ES for about the same $ and get started that way and get to learn some Java / Android programming to boot.]

But isn't that about the same as doing OpenGL 2.1? Sure ES might be somewhat cleaner but as far as capabilities go it should be similar and the raspberry is unlikely to be the more "responsive" development environment ;).