Well, it's obvious I am a newbie. I only know a bit of C, I am a newbie at C, but this hasn't stopped me from writing an application I want.
I was able to write myself a GPU temp monitor using AMD's ADL library. It's multithreaded so each thread is checking the corresponding sensor for overheats.
I am in the process of writing an HTML parser of sorts(not a library, but one that uses it) using cURL then piping to htmlTidy to fix up the document then piping the fixed document to libxml2 for the actual HTML parsing and finally through PCRE for regular expressions.

Well, I pretty much pointed out that I wish to write a game in pure C. I already have SDL. Now the problem I am facing is that, I don't know anything about game programming. Neither terminology(shading,voxel,polygons and the list goes on), neither about geometry involved, nor the concepts and maths of "Depth,Gravity,Collision". And for instance how walking on some texture, you don't fall off of it.

So if possible, can you point me to some resources on how all these stuff work. And perhaps how to start.

As someone who works with C and C++ (I do use both) 50 hours a week for work, I have to ask the question of WHY anyone would chose to use C for a game development project that you are starting in 2012 (Embedded applications or other special circumstances excluded).

Because I find C++ too cluttered with all the OOP stuff,iterators, dynamic/static casts(with weird declarations, too),templates,maps, the list goes on. Whereas C is much easier, and typecasting is done via (type)variable and voila.

I concur with Waterlimon. Straight-up C just isn't well suited to games... that is to say that OOP features come in very handy. You're also more likely to find useful libraries for more modern languages. It isn't really very hard to pick up the basics of C++ (or Java or C# which are both relatively similar to C++ in syntax). I can appreciate the desire to make a game right from the get-go (its pretty much what I tried to do some 10 or 11 years ago), but I'd first focus on language and design skills before taking on a big giant project. From there, start with small projects (much higher chance of finishing ) and work your way up as you develop the kind of skills you'll need for elaborate projects.

There was a saying we had in college: Those who walk into the engineering building are never quite the same when they walk out.

Because I find C++ too cluttered with all the OOP stuff,iterators, dynamic/static casts(with weird declarations, too),templates,maps, the list goes on. Whereas C is much easier, and typecasting is done via (type)variable and voila.

So in other words "I'd rather use a tooth pick for construction work than learning how to use those overrated 'power tools' everybody is talking about".

How is C "easier" if you end up wasting 80% of your time reinventing countless wheels instead of actually making progress with the game?

Based on your choice of language and current level of knowledge the only advice that comes to mind is: if you aim higher than a very simple Pong clone as a first project, you are over reaching. And even that means getting familiar with at least one way to get graphics on the screen (meaning a library) and reading keyboard input beyond scanf. Though it would technically be possible to create a "turn based" Pong on the console with nothing but the standard library.

Because I find C++ too cluttered with all the OOP stuff,iterators, dynamic/static casts(with weird declarations, too),templates,maps, the list goes on. Whereas C is much easier, and typecasting is done via (type)variable and voila.

As far as other languages, I already know I'd never do python or C#.

Those different casts exist in C++ for a reason, the C casting system is all kinds of broken.

You can still use c style casts, can ignore templates etc... but you shouldn't.

@OP: I understand your line of reasoning. Unfortunately it simply does not work if you want to develop games beyond a tetris. You do NOT have the time to reinvent and reimplement stuff which has been done before. If you want to get anything done you will need to use stuff other people have already coded, and this includes using OOP features. It will thus probably involve using a different language than C. Of course nobody is pointing a gun to your head and telling you to "use Java!" "use C#" "use Unity!", but if you want to get anything interesting done you will almost certainly need to move beyond C and get used to new programming paradigms.

Unless you have a specific project in mind, for instance a Dwarf-Fortress type game which requires nothing but trusty old console and algorithms (that can be coded in C, but you would probably still want OOP for that).

TL;DR: try and be more open-minded. Nobody's forcing you to anything but it doesn't hurt to look beyond what one already knows and actually try it out long enough to get comfortable with it - who knows, you may actually like it!

For instance I had some misconceptions about Python, but I actually came to like it quite a lot. Of course I don't really use it because I don't need to, but it does come in handy as a tool for quick script whip-ups, especially with all the stuff it takes for granted which most languages don't (arbitrary precision arithmetic is a good example).

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

Well, I was thinking more along the lines of an o for the ball and a couple |s for the bats. The reason I said "turn based" is because I don't know any non-standard way in C or C++ to get keyboard input without blocking.

TL;DR: try and be more open-minded. Nobody's forcing you to anything but it doesn't hurt to look beyond what one already knows and actually try it out long enough to get comfortable with it - who knows, you may actually like it!

To emphasize this point: I had co-workers with up to 40 years of experience in C that unfortunately spent at least 30 of them stubbornly refusing to learn anything new. Their code tended to be messy, not because you can't write clean code in C (you can), but because all the extra work resulted in taking shortcuts and just be sloppy to finish in time. So you had code with plenty of bugs that were also a pain to find in all that mess.

Of course I might simply be biased because I spent many years being the guy that had to find and fix bugs in other peoples code whenever the bug reports came in.

Nobody expects anyone to instantly transition to C++ and write what is so nicely called "modern C++". But flat out refusing even the option to make use of some extremely useful and time saving features out of a feeling of being "overwhelmed" by all the new possibilites? Really?

So I figure everybody failed to elaborate on the actual question in the thread:

Well, I pretty much pointed out that I wish to write a game in pure C. I already have SDL. Now the problem I am facing is that, I don't know anything about game programming. Neither terminology(shading,voxel,polygons and the list goes on), neither about geometry involved, nor the concepts and maths of "Depth,Gravity,Collision". And for instance how walking on some texture, you don't fall off of it.

You may want to skip out on the shading, voxels, and all that 3D game stuff for the time being and focus on getting your geometry chops up to speed. That being said, you should study the basics of physics, comprising mostly of Rigid Body Dynamics, as well as review your concepts in geometry. I also suggest you look into vectors, which are a portion of linear algebra. You can learn these concepts by going to Khan's Academy (link in my signature). Rigid Body Dynamics comprise mostly of Newtonian physics. That is going to give you all the necessary tools to figure out how the game is supposed to interact.

Of course, there may be a better way to do this, but that's how I would do it