How much C is enough to start programming games?

C itself is a pretty small language. Knowledge of it probably isn't going to be your limiting factor, but your knowledge of - as you say - algorithms and data structures, as well as experience of completing (or at least significantly progressing with) projects.

C itself is only enough to make a text-based interface. If you want to make games with graphics that spin, twirl, and flash, you need access to an API, and that depends on which platform you want to use (Windows and Mac have different libraries).

If you use Windows, try using SDL.

If you use Windows, try using SDL.

Actually, SDL is available on many platforms (according to their website: Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX).

Is SDL code for Windows the same as SDL code for Linux? I prefer to develop under Linux, but I understand that eventually I will be making games for Windows.

Yes. SDL is SDL.

So is OpenGL code under windows and Linux, with the only difference creating the context as far as I am aware, after that the code for rendering should be the same on win/linux/mac.

I too would suggest using SDL with C. I originally only made C games, and you can make some great games with it. While I now prefer SFML (which requires a C++ implementation), SDL is fine for what you are doing.

Good Luck!

BTW, learning from K&R (which I still have from my 1994 CS class) seems odd, as it's mainly a reference document. You might want to check out some C tutorials to help fill out your understanding of programming.

So is OpenGL code under windows and Linux, with the only difference creating the context as far as I am aware, after that the code for rendering should be the same on win/linux/mac.

That's more or less correct - the actual rendering parts of the API are completely OS-neutral. It's not the full story however as OpenGL is very hardware-dependent (on it's own OpenGL doesn't do anything aside from pass rendering commands to your graphics hardware, which is what does the actual drawing). By that I mean that you need to be aware of what features are available on the graphics hardware you're targetting and either code to a common baseline or implement workarounds where they're not available.

There is one exception to the "OpenGL doesn't do anything..." thing I mentioned, and that is where the driver reports support for a certain GL_VERSION, but features of that version are not available in hardware - in that case they must be emulated in software by the driver. Sometimes (not always) that can come at a performance cost, and sometimes (not always) that performance cost can be extreme. Generally the cost increases the deeper into the pipeline you go - pre-vertex-shader emulation will be cheap, fragment shader emulation will be expensive (may drop you to less that 1 fps).

You may also encounter buggy drivers and have to be aware of what the bugs are and what the consensus is for working around them.

So once you have your context up you can treat OS as being totally irrelevant, and focus on driver quality and hardware features as being the key differentiators.

The easy route would be SDL for making 2d games for example "Side Scrollers,Puzzle Games,RTS,etc" and SDL and OpenGL for making 3d games "Amnesia the dark descent,Halo,Dear Esther,etc" or you could go the hard route learning WIN32 API for Windows for 2D games/3d games.

You might be able to make something like a breakout clone using ncurses as seen in this video

but don't expect to impress anyone as as mentioned since C itself doesn't have any sort of graphics support built in you are still going to have to learn more stuff namely an API like ncurses to get something on the screen other than text.