About init() and uninit()
First, I feel I have to justify the name. As TANSTAAFL pointed out in a previous post, init() and uninit() are really poor names. As a programmer, I perfer create() and destroy() to them. Anyway, I'll stick with these names until we hit the implementation for two reasons:
- although they are poor and not very descriptive, their meaning is clear enough to fulfill our needs for the time being.
- I have to bear the burden of my previous mistakes... :)
What do these function do? The second one is easy : uninit() will do the exact contrary of init(). Now we cannot define init() as a function that does the exact contrary of uninit() anymore so we'll have to find a better answer.
What does it need to do? It has to make sure that the graphic subsystem is correctly initialized. If it is not, then it must return an error. It must also ensure that we are now able to draw what we want to draw - this phase is a special part of the setup phase: you initialize the underlying rendering state machine to satisfy the needs of the application when it is able to accept your orders.
Here comes the problem: how to initialize a graphic subsystem (probably using a known API) in the first place? I'm not speaking of DX or OpenGL init here. I speak of what they need. In extenso: who is responsble for creating the window?
Our problem is that the window may also be used by other subsystems because of its proeminence in the windowing system design. You may think that I speak about Windows here - and you are wrong. Any windowing system I used (I used quite a few, from Win32 to TVision (yeah! remember da ol'time), from GTK+ to plain XLib) are using more or less the same contests: the input is tied to a particular window. Therefore we not only need the window to deal with the rendering but we may also need it to read the user input. Because of this reason, we are not able to create the window during the graphic engine initialisation.
It means something important: we need to build our graphic engine on top of another software component: the system component, which will enable us to perform all the tasks we need to perform - ranging from reading user input to render the view on the user screen.
We are still lucky - because we don't need a full abstraction of the system application model. We only need a simple way to deal with these things - using the Win32 system, we'll only have to write a bunch of thin classes. The only thing we'll have to worry about: we need a level of abstraction which is good enough to be able to manage systems which do not have any kind of window management.
We'll speak about this is a subsequent entry.
I'm ill. Cold. See you next time? I promise I'll do my best to give you more information :)