The very idea of using something as fast as C for OOP makes me very excited. I'm not talking about objective-c or C++. You can google "object oriented C" and there will be a pdf that pops up of a book, an article someone wrote explaining how to write C in an OOP way.

Since I'm basically an Action Script 3.0 programmer, I'm wondering have any one who programms in C tried using the OOP methods described?

Most of the things that people tout as the advantages of OOP, are exactly the things you should be doing with or without it.

Programming in C with a more `object oriented` nature generally applies to making wiser use of data structures and pointers then the newbie will often first consider. You might consider a look at LibWWW or GTK+ (C bindings, not C++).

On a side note:

Typical game implementations that I've seen, either build their control handling as a massive switch over key events (I believe even vi did this), or create a input management class that invokes a method on a registered objects descended from abstract base class XYZ after looking up the binding. Registering callbacks some times even saves a pointer to some special object rather then a function pointer. This generally sucks up costs for (several) vtable operations, numerous method resolutions, will likely incur dynamic memory allocations in the data structures, and some people will even process the controls in a O(n) like fashion every frame.

The system I've been piecing together for Stargella, polls input events and uses the key that was pressed to index into a table of function pointers: which is effectively a sniper shot compared to using std::map or related bits of C++ voodoo. Making my system more of a simple matter of pointer arithmetic to trigger the call backs, then would be the cost of hunting it down through an STL map, vector, or list (etc).

That is a fair difference between `typical C++` and `typical C` was of implementing the same thing.

A more objectual change, will be making the game register structures instead of funcptrs with the input system, allowing one to more easily change the concept of a keybinding without complicating the input system. The main reason for the change, being to bundle the question of whether input handling for control XYZ is supposed to be buffered or unbuffered, etc.

I like what I've been hearing about C. I like that it is fast and simple. It's like a tank or cannon. Simple, reliable, and ubiquitous. It runs everything above it, which is everything most people use the computer for. Then only thing beneath it is assembly and machine code. It like feeding bullets into a machine gun and shooting the gun at the same time. You are right in the middle of the power a computer has, not the being shot at if you can understand my analogy.

C can do anything and do it better than any other language today and doesn't consume the overhead they do.

I'm definitely going punch away at writing more C code and nailing those graphics frameworks down like Cairo and Gtk+.