Ummon Wrote:So using Python with pyOpenGL will be almost as fast as carbon and openGL?

Likely not. That's not to say that it wouldn't be sufficient depending on what you wish to accomplish with it. But to be clear, that is not what I was trying to imply with my earlier comment about scripting languages. To restate it: There is no point in worrying about the speed of a base API such as Carbon or Cocoa or even SDL, when they are all more than sufficient to the point that you will even have enough left over processing power to use a scripting language for you game logic. Better to choose one based on features instead. That is, of course, only if you want to develop the engine from scratch.

There are fully scriptable game engines out there already if you wish to go that way. I believe Unity uses JavaScript (and maybe C# if I recall correctly). Torque uses a proprietary language called TorqueScript. Other engines use other scripting languages. Some of the advantages to scripting are: it doesn't require a sometimes lengthy recompile of the engine for each little change, scripting languages are more forgiving of errors and memory management, easier to learn, you don't need a compiler or complicated dev tools, and the list goes on and on. The drawback is speed. But as we've been discussing at length here, most of the time that doesn't matter anyway for game logic since the graphics are off-loaded to video hardware.