Reading/grasping the idea isn't the whole picture, you need experience. Make little toy programs in C++ first, just using console i/o. Once you have experience and you're quite comfortable with programming, then I recommend you to move on.

Jumping straight into OpenGL wouldn't be so smart. It'd be easier if you have somewhat of a computer graphics background (e.g. you know Maya/Cinema4D/Blender/3DS Max, or even After Effects). I'd start at learning Allegro, SDL or SFML first and then moving from there. Unless of course you want to really learn OpenGL and not concentrate on making games. After that you could learn OpenGL, or even jump to a rendering engine, such as Ogre3D. It's all up to you.

I shared a few of my thoughts on this in a blog post a while back titled "What next? Intermediate to advanced C++".

If you didn't already do so when reading through your book, I'd suggest getting in lots of practice with your programming and C++ basics:

• Make sure you've done all of the exercises in your books.
• Take the exercises in your books and make small changes to them. Just pick any one thing -- delete a character, add a random character, change an array index, whatever -- make an educated guess at what will happen when you make the change, and then actually do it and see if you were right. If at any point you're wrong, do some research to find out why. This will test out your knowledge, and will also allow you to become familiar with common error messages and some of the possible causes.
• Seek out additional exercises. These might be from another book, from an online resource (the quizzes provided in some of the chapters at LearnCpp.com for example), or might come from collections of problems such as Project Euler or Code Kata. Try to solve your own problems or build things you actually need as well; if you need to solve an equation, write a program for it. If you need to re-name a bunch of files, write a program for it.
• Teach yourself the basics of using the debugger provided by whatever development environment you use. Learn to set break-points, inspect/watch values, and step into/through code, and learn when these things are useful. These things will be easier to learn when working with the simpler code provided by your examples and exercises, but will help you to solve much more difficult problems later on.

Only you can decide when you're ready to move on from the basics, but the good thing is that if you're wrong and find yourself in trouble, you can always just go back to solidify your knowledge. When you're ready to move on I'd suggest starting out by learning to create some simpler games with an API such as SDL, SFML or Allegro -- from there you can later move on to OpenGL or DirectX if you feel it's necessary, can learn to use an engine instead, or can simply continue to use your chosen API to create great games.

I always recommend Pong as a great first game to create: It's relatively simple and everyone knows the rules to it, but it contains many of the things that make up more complex games; you'll learn to use a game loop, draw to the screen, handle input, and perform some rudimentary collision detection. It also allows room for moving on by adding power-ups or your own twists, or can even be expanded into an entirely different game by removing a paddle and adding bricks to make a Breakout game.

Hope that helps!