This article is some key points when the Gamer and the idea are discussing "what extent to which abstraction can achieve". The idea hopes to make a system, every module of this engine can be used alone, this is the focus of our debate. Fortunately, we finally got a consensus: "For the system, the meaning of invariance is higher than variability." Indeed, one system atomic part, such as files, CODEC, etc. These small systems can be disassembled, any engine can, not a patent of which engine, but when involving several large systems, This is a more troublesome thing, forced dismounts may lead to more horrible results. Therefore, talking about variability under the premise of invariance, it has made everything goes.
-------------------------------------------------- -------------------------------------------------- --------------------
Recently, I recommended a engine. The name is Irrlicht. I seem to have a lot of hate that I can't hate this engine.
. I am a bit quite, because I'm writing this kind of thing, it is not written by it. It is not a job. It is a three-minute heat, but it is more than understanding the understanding of the architecture. Over. In addition, it is watching the OGRE recommended before, I feel that a engine is more excessive, and can you reach? It is already the point of "the truth and then a step is a fallacy", so I don't have to look at it.
After the SourceForge was Irrlicht, it was found that the author was so bt, such as OGRE, the engine layer is not enough to abstract engine layer and the elephant engine layer, but also fully write the abstraction layer into an interface class, and make an extremely abstraction The interface layer. These interface layers are basically split in the following manner: Base, Video (Render), IO (File), Core (Math and Physics), Scene, GUI. This has fundamentally shaken a deep-rooted concept that I inherited from Ogre: The engine wants to "self". " For IrrLicht, you can divide it into two projects: "Abstract Interface" project and "realization" project, both only interface contact, even you can implement IO and Scene in an elephant layer, another implementing VIDEO and SCENE (Base must be abstract itself to be implemented, this intermediate includes an iUnkown interface that is impending photographed, as long as you strictly follow the standards of the abstract interface. Is this necessary?
Software development needs to follow a standard, standard meaning in philosophy is to follow a certain "invariance", for example, we can always determine that when we are in the file IO, you can always call CPPSTD or CSTD functions, we Always determine that we are developing, using DX or OpenGL API. Only the possibility and necessary discussions can only be discussed on the basis of invariance. OGRE is the first of GAMER's first combining the constant and variable engine. Before this, Gamer has only a "Holy Sword 2" engine that Gamer has a very powerful "Holy Sword 2" engine.
Not long ago, the guidelines say a true nonsense, "OGRE's variability is the interface invariance"
. Looking for variables in C , if you do not follow the contact of the interface, can any other uncapacity can follow? In addition to the interface invariance, OGRE achieves a large extent in the implementation of the interface, which is estimated to be a number of people studying and drawing on it. But OGRE may get more and more far, you can try to cut the OGRE's module, for yourself, and you may find that OGRE's invariance seems to have exceeded interface invariance. The category, in design, unable to avoid each module relationship, so that OGRE has spent a certain effort to solve these problems, these modules are in designing, perhaps a new invariance. If you cut the OGRE rendering module: including Renderable, Renderueue, Material, Texture, Rendertarget, all those related to rendering this concept, you will find that they can't make the most perfect integration with other systems that have been designed with you. . If you need a seamless, perfect convergence, you can only help other systems: resources, data, control, etc., you find that these systems are likely to just It is one after another. In this two difficult choices, we seem to have seen some deeper things: how should modular design ideas be implemented? Here is different designs for each system, and each benefit, it is meaningless. It can only be said that in a certain issue, it is disadvantaged on a certain issue.
Now let's take an OGRE's road: OGRE is incorporated into the "invariant" angle in each system, in this case, this is a great, perfect, data-driven, integrated system, this The system can be changed on the interface. However, as mentioned earlier, such a system, its important interrelationship has to collapse one ring because of the "invariant" angle, it has to introduce other rings. Although this invariance is generally no longer touched for OGRE, this invariance is based on some of our reality, such as the graphic API, which is DX and OpenGL (line therefore Not changed), the file operation is to take data to memory (Datachunk and the Resource system he supported therefore constant). For example, we write documents and resource systems, want to replace OGRE's ideas, but OGRE Other system design ideas is in the way of Resource-Datachunk, this alternative is also a more troublesome thing.
Because the Resource system has been determined at the Ogremain level, it is changed, unless the entire OGremain is changed. We don't want to manage Frame's update rate as Ogre, in fact, we need very simple, and OGRE is relatively complicated (slow), but we will only lament,
Because the Frame update rate These classes are written in Ogremain, that is, we unless you reorganize OgRemain's related classes. Why do we encounter such problems?
So we have concluded that OGRE assumes so many things, although it guarantees a solid foundation core structure, let some of the destruction of things now, and some of us can only act in accordance with the hypothesis of OGRE. That is, although OGRE is supported by modularization, but in accordance with the principle of OGRE, it cannot be modular in the sky.
From the above discussion we can see that we need a engine, first ensure its stability, so it can propose scalability under the premise of stability. The degree of stability here is not yet defined, can make a hand feet. OGRE is undoubted by the hand and feet, so that you will not be able to put all things into your own flag, OGRE itself is not doubtful, and the bad news is that when we touch these stable problems, there is no Start. It can be said that in the current state of technical state, all engines have this problem, just like all the sun will easily. This is a small contradiction between stability and extensibility. The basic philosophical principles of all engines, or all architectures are to find variable (unchanged foundation and variable housing models), unchanged, and variable is a pair of engines. The contradiction between symbiosis, irrlicht is no exception. It can be said that IrrLicht has no essential difference between Irrlicht and OGRE.
The abstract structure of the OGRE is not preparing to prepare an abstract concrete structure, all in Ogremain, once you need to change, it will be quite serious. Is there any way to let a engine can be divided into mutual correlation modules on an abstract layer? According to the previous statement, this seems to destroy a engine with the integrity of survival. Insciently, the divided system is challenged due to the split gap and integrity. In rendering, you need to take into account the texture file, even if you have to consider this relationship in an abstract sense, if you destroy this relationship in order to divide the module, it is possible to lead to a series of unpredictable results. We noticed a feature of IRR, leaving us a lot of space in high-level abstraction, for example, we can consider the readfile object from IO in Render, but only consider the file name. In-internal implementation, if you want to quench IO, you can implement it with readfile. If you don't want it, use your own way, because render gives you just a file name, you can use a lot of things you need. To get it. Although all systems are organized in this way for IRR, the system that organizes this is undoubtedly organized in other ways. In this way, we turn the invariance, from the object level (File object) to the identification level (file name). This will undoubtedly let the contact between the subjects are spread. It is only to be resolved in the elephant layer. And in the elephant layer, it is the IO that comes with IRR, which is your own question. This is your own problem. Thus, under the premise of the isolation module, use an abstract manner to disrupt the object contact, and turn it with a logo connection, and the effect will be much better. But in the end, you can't avoid the connection between the two systems, this invariance, you can put it from the abstraction layer to the love layer, but no matter which layer, you have to achieve it, this means:
You must implement it in the engine. So from the perspective of the engine, this is something that will never escape, but OGRE is more absolute, and Irrlicht is more mild.
------------------------------------------ SO, that kind of right The engine abstraction is a set of modules, which seems to have no great significance, because the relationship between modules You must consider. Of course, you can use a lot of design patterns to achieve a greater extent, but in fact, the connection is even if the design mode cannot be eliminated. Correct practice,
It is a steadyness of the stability, and the argument is correct. It is like an extended system under the other of the changing premise, just like Ogre and IRR, rather than imputation of how troublesome. Then I want to ask you, why do you want to modify it? Since you feel bad, why do you want to use this engine?
Using the engine is a contract, the contract itself is to follow the agreement. If you are not prepared to follow its agreement, then you don't want to enter into this contract, the ancestor is still right: "Different, don't worry and seek"! !
