Reprinted from:Http://www.lihuasoft.net/article/show.php? Id = 4853
I have written about the game engine for a few months. I have some ideas that need to be summarized. I also want to share some ideas with my friends who are similar to me or who want to cook better than me, expert moxiao ~~
The idea here is to share my process with you as much as possible. What I write is very bad (I do think so). I will write down in the article where I think there are still problems, areas for improvement, or areas that have not yet been well resolved; I hope to discuss with you and welcome suggestions and criticism from experts. just for fun! OK.
(PS: the code in this article is a piece, these don't compile. If you want some code, contact me. I will mail it to you when the engine is almost done, my mailbox:
Xjyhust@gmail.com
Or
Xjyhust@126.com
.)The goal is to write a multi-Renderer game engine. First, let's talk about the graphic rendering part. After all, this is the key. If you want to understand the physical, network, or other content, sorry, no here (maybe it will be too late ). Let's take a look at the two blogs I wrote earlier, "Design and Implementation of multiple Renderer in game engines" (1, 2), which describes a method implemented using a dynamic link library, I will not review it here. Suppose you have completed the most basic implementation above.
The core part of the engine is the premise of everything, so let's start from here. I strongly recommend that you first analyze the format of commonly used 3D models before you start-because the design of the underlying basic data types of the engine is very important, in addition, it is quite difficult to change it later. Looking at the parsing of common model formats can help you design a reasonable underlying data type (texture, material, triangle, etc ). Take the format ms3d of milkshape 3D as an example. On their website, you can go to a C ++ parsing component and check the data type in the header file first. The Code shows that both texture and material have names, all have filename (indicating the texture file name), material has 4 colors (this is consistent with the physical meaning in the graphics), and then texture can be an Alpha texture, the property transparency can be used as a reference for our design. We will stop here. Later we will see how this classic format affects our rendering batch design.
Start to set up the basic data type: Here it is strange that I used a void * in texture *. Well, this is used to store textures in different APIs. For example, if dx is used, I will always regard this void * as lpdirect3dtexture9 *. In the engine, I will use a lot of static conversions between pointers (non-runtime) (hard core C ++ experts can see that my code will say static_cast should be used, instead of using typename in C )(...). Well, I agree, but sometimes I forget or get lazy ).
There are many engines that will separate texture into a class and have corresponding behaviors (member functions). However, I think the essence of texture is a pile of data, since Texture Manager (Texture Manager, simplified as texturemng) is necessary, there seems to be no need for a separate texture class design. We have texturemng management, which seems enough, I don't want to make things too complicated for the moment. (PS: it is a good way to face objects, but the essence of many "things" in the engine is a set of data. Before turning them into classes, consider their related operations, consider the impact of using classes to implement small data bodies... Like quake3 and ogre are two design extremes. Is it better to combine them sometimes ?)
There are also many data types to write, such as many mathematical classes in 3D, such as vector3 and matrix4. Put them first. I like the idea of iterative development-using a short cycle to make simple and runable programs, and then improving them. Let's start with the example in the dx sdk and implement a vertex example first.
We need to define a vertexbuffer abstract class to provide public interfaces for GL and DX. (PS: In a multi-Renderer engine, the use of abstract classes (pure virtual classes) is a design in implementation, that is, the underlying implementation of different APIs is the same interface for users) add the file uhedx9vertexbuffer to the DX9 Renderer. H and uhedx9vertexbuffer. CPP. In uhedx9vertexbuffer. cpp, complete these implementations (let's take a look at the dx sdk, There is nothing worth talking about), write them here, and continue tomorrow...
