>>8
I'm interested in your analogy here. Here is an example of an isomorphism:
The group of the real numbers with the operation of addition is isomorphic to the group of the positive real numbers with the operation of multiplication. One isomorphism is f(x) = e^x.
Proof:
f(x+y) = e^(x+y) = (e^x)*(e^y) = f(x)*f(y)
f is an onto function from R to (0, \infty). It is also one to one.
>>12
OpenGL might create matrices for the transformations you want, but if you don't understand that concept of composing transformations and how they can collapse to a single matrix through multiplication then the API isn't going to make much sense to you. And you never know when some property of how affine coordinates are implemented could end up being important. Ultimately, if you don't understand the functionality of the library, you wont be able to use it effectively. In fact, it isn't that hard to implement OpenGL in software, although you would never use such an implementation unless the hardware wasn't available for some reason. It isn't the implementation that is difficult, but rather the concepts employed in the interface. There are other components to a game engine besides the rendering. Similarly, there are libraries for physics, AI, etc. But in order to integrate these libraries into the game you want to build, you need to have a deep understanding of their functionality. Sometimes you can still treat the library as a black box, and sometimes learning how to use the library is just as difficult as implementing it.