I know you don't care but I received my copy of Dave Eberly's 3D Game Engine Architecture. I'll have a look to his new code.
I use a notebook to type this. The kebord of this notebook is really teh sux0rZZ.
What did we say?
Gosh. Even if I agree with you about the weird LIFO journal structure - it do not fit my current needs and in fact I find it pretty good - I suspect you are able to scroll down and read what I said yesterday. To simplify: the preliminary design I did two days ago has a some important issues that we need to correct.
So : how to resolve this issue?
Our main problem arise because we don't have clearly stated our goals. Remember we are designing a 2D graphic engine. We want to be able to reuse this engine later, maybe in another completely different project. Another thing we want to do is to abstract the rendering code from the game code.
The last sentence is very important. It makes us ask ourselves what is the game code? This is a question we didn't consider yet. Hey! What did I say? There are questions we forgot? Oh! Wait wait wait...
Lets me rephrase the whole thing. We tried to design a graphic engine, we did something which is obvioulsy not correct and we just saw that we forgot at least one question?
Speed vs accuracy
This is always the biggest problem with design. It leads to the failure of small and big projects. As developpers, we want to rapidly code something. We do some design, then we code, and we experience some major problem wit our code. Wee have to do "clever" things to correct the problem - and of course we soon forget the exact meaning of this completely crazy piece of code. We, as coders, often fail because we tried to do things too fast.
So, what do we have to do then?
Let's restart with what is perhaps the most important thing is a software design: the specifications. OMG you'll say! Yes, we forgot them! Yes, we forgot them. Writing the specification or such a large project would take a long time, so we'll only stick with the simple lines : as a component, we want our 2D graphic engine to be open to reusability and therefore should not be tied to a particular game type. It have to be able to draw whatever we want to draw using a simple interface. Of course, it should be fast - while this is a part of the specs, we won't emphasize this point.
You might say that we didn't say anything yet that we haven't previoulsy said. This is not totally true. At a first glance we said that we wanted to create a 2D graphic engine. The we added the draw methods. The particular organisation of these two methods gave us some kind of headache - they were obviously not correct since we wanted to do a graphic engine and not the graphic engine of a particular game.
Let's speak about something else
In order to ease our design we have to think about what we want to do. We want to do a game which uses the graphic engine. This single sentence implies that the game and the graphic engine are two separate things. I previously asked the question "what is the game code?", we did not answer it yet. The game code is a collection of data and algorithm which are used to play the game. They are not related to the rendering code - which is performed by the graphic engine.
On one side, the game code, on the other side, the graphic engine. Or, to be clearer: on one side the game model, on the other side the game view.
Sounds like we should be able to use some design pattern at the higher design level.
Nothing else. See you next time? We'll probably speak about the same thing.