Engine Analysis of RPG maker (1) (2)

Preface:

The original copyright of this series of tutorials is owned by bsucat. This article is for favorites and sharing only. For reprinting, please mark the source of the original author as follows to show respect !!

Author: bsucat

Original article: http://blog.csdn.net/bsucat/archive/2010/03/01/5334619.aspx

 

Directory

 

0. Preface

1. How RM works

1.1 Overview

1.2 imaginary Structure

2. Image Module

2.1 10 s of secrets

2.2 performance and bias

2.3 draw Pipeline

(To be continued)

 

 

0. Preface

Who is suitable for reading this article?

The scope of knowledge involved in this article may be unfamiliar to everyone. Indeed, this article is not suitable for beginners to read and is useless for most people. But for anyone who wants to know the internal operating principles of RM, the content of this article should be worth sharing and discussing.

What is the rgss version mentioned in this article?

Rm is not a commercial software that exposes source code, and you are also disgusted with RM's decompilation (and I do not have that capability, it's just a speculative analysis of the RM underlying Engine Based on my personal experience. If there is something wrong, please be sure to understand and correct it.

In addition, because I am familiar with rmxp, this article mainly analyzes rgss instead of rgss2. Compared with rgss, rgss2 does not change much in the underlying implementation, but it is more standardized and adds some functions. Therefore, most of the content in this article is also applicable to rgss2.

 

1. How RM works

 

1.1 Overview

Many people may have criticized RM for its shortcomings, but RPG maker XP is indeed a modern 2D game production tool. In terms of organizational structure, rmxp uses a very popular structure of game content separated from the game engine. The game logic is flexible and independent into a module, as shown in.

 

 

 
Don't think this is simple. In fact, it is not easy to design a script system on the engine. Fortunately, RM has already helped us. Next let's take a look at how RM is implemented.

 

Generally, a script can be used in two ways. One is that a host language (such as C) loads a script to process part of the content, but the control is still in the host language, the other is that the host loses control after loading the script, and the control is in the script language. Rm obviously belongs to the latter. After RM initializes a series of tasks, it calls Ruby's c API (such as ruby_run? I'm not familiar with Ruby's c API, just guessing) to give the Ruby interpreter control. Therefore, the entire game running process we can feel is completely controlled by rgss.

Rgss is already at the highest level in the entire RM software layer. As shown in.

 
 

Under the script layer, it is the game engine. Rm abstracts engine functions and encapsulates some operations by extending the ruby library. Users do not have to worry about how the underlying engine runs, such as using DirectX, managing memory, and processing Windows message loops. As long as users know how to use rgss, they can use the engine to make their own games smoothly.

 

This encapsulated content is transparent to users, and you do not need to understand it normally. However, for those who are eager to learn more, today we will discuss this part of J.

 

1.2 imaginary Structure

By default, a game contains at least three files: game.exe, game. ini, and rgssxxxx. dll. Come and guess. There is something in it (not a pure guess ).

 

Game.exe is the main game program and game. INI is the configuration file. When game.exe starts running, it starts from game. INI reads the relevant information, such as the title of the window, the name of the DLL file that will be dynamically loaded (that is, rgssxxxx. DLL), and where to find the script to be run by the Ruby interpreter (such as the default script. rxdata) and so on. Parsing the INI file is very simple. You just need to call the INI File Processing API provided by windows. So I guess RM does the same thing (otherwise ?!).

Game.exe does not have much content related to the game engine, or even a Windows message loop (which will be analyzed later). It is more like a "zombie ". The behind-the-scenes hacker is rgssxxxx. dll. In this DLL, a game engine implemented by DirectX is encapsulated. By calling the APIS provided by game.exe, game.exe achieves everything we want (well, maybe you want more ......).

 

 

In a game program, the general process is as follows:

 

This loop is also reflected in the default scripts of rgss:

 

# Main Loop <br/> loop DO <br/> # refresh the game screen <br/> graphics. update <br/> # refresh input information <br/> input. update <br/> # refresh the screen <br/> Update <br/> # interrupt the loop if the screen is switched <br/> If $ scene! = Self <br/> Break <br/> end <br/> # Main Loop <br/> loop DO <br/> # refresh the game screen <br /> graphics. update <br/> # refresh input information <br/> input. update <br/> # refresh the screen <br/> Update <br/> # interrupt the loop if the screen is switched <br/> If $ scene! = Self <br/> Break <br/> end

 

In this loop, the update statement is responsible for the game logic processing task, graphics. from the literal point of view, update is obviously the processing of game images (actually more content ......), So where can I process window messages?

 

2.

Image Module

 

 

2.1 10 s of secrets

If you have written a poor path-seeking script, the prompt bar "script backed up" appears in the game window. I believe you need to call Graphics at least once every 10 s for rgss. update restrictions are no stranger. Some people think that this 10 s limit is unreasonable and is the performance bottleneck of RM. However, after my careful consideration, this is not the case.

Those familiar with Windows Programming know that Windows programs are message-driven. If there is no message loop update, the whole program will be stuck. Previously, when rm's game.exe program is running, the Ruby interpreter occupies control of the entire program. Let's just put it in game.exe. Once the script is called, it cannot be returned. In this way, the window message update task can only be handed over to the script.

If the script does not call the update of window messages, the entire program will be stuck. Therefore, to prevent the program from being terminated due to the slow running of the program due to a bad script written by the user, it is necessary to add the limit that the program will be automatically terminated as long as the message update is not called for 10 s.

So, that's right. The lost window message processing is actually encapsulated in graphics. Update.

 

Therefore, the graphics. Update function now looks like this: window message processing + rendering image. But is it just like this?

I wonder if you have noticed that the attribute values of the graphics. frame_rate and graphics. frame_count modules indicate that RM has frame rate control. The two attributes are described in the RM document. The Frame Rate Control is obviously encapsulated in graphics. Update for processing (what is Frame Rate Control ?! This is not something new. Please search for "regulating frame rate ").

Currently, we know that graphics. update includes window message processing, Frame Rate Control, and image rendering, and it may actually contain more things (Modify the title or something ?! Tian knows ?!), However, we don't care about that now. Next, I want to talk about image rendering.

 

2.2 performance and bias

Rm's image engine uses DirectDraw. There is no doubt about this. This may be the opinion that I swear the most in this article ......

However, rgssxxxx. dll does not directly link the DirectDraw library file, but is loaded at runtime. Here, by the way, Microsoft has not provided DirectDraw documentation support since DirectX 8, and later, it directly abandoned DirectDraw. However, DirectX is a COM component, so even if Microsoft does not update ddraw, it can still run smoothly in any new version compatible with it.

People who use RM often have two prejudices. The first is to think that Ruby's interpreter is relatively slow, leading to poor performance; the second is to think that DirectDraw is a dead product, based on its RM engine, it will inevitably have poor performance.

I am not familiar with tests on Ruby interpreter speed about the first bias, but as far as my personal experience is concerned, it is a well-designed rgss script structure, it is impossible to slow down. Many people do not consider performance overhead when writing scripts. Every frame has to do a lot of useless loop checks, so the Ruby interpreter is panting (Poor Ruby mother! J). This is the culprit in slowing down the speed of the Ruby interpreter.

Well, let's go back to the question of our image module, that is, the second prejudice against DirectDraw. Of course, Microsoft has completely abandoned DirectDraw, and DirectDraw can only be regarded as a semi-finished product, but this does not mean that DirectDraw is a low-performance thing. In fact, DirectDraw can meet the vast majority of 2D image production needs, and the efficiency is very good.

Some people may wonder why the DirectDraw can be used to develop 2D engines since it can meet the needs of 2D game development? As I mentioned earlier, DirectDraw is only a semi-finished product. Many functions are not implemented by Microsoft, and developers need to expand themselves, which undoubtedly increases the difficulty of developers. I have discussed this issue in a Foreign Forum. At last, many people come to the conclusion that many hardware vendors have already abandoned the product's 2d acceleration, that is, blitter support (yes, bits in the bitmap class probably call it ), 3D acceleration supports almost every video card currently (I don't know if this conclusion is true, it's what people say !), So direct3d is a wise choice ......

In other words, the above two points are definitely not the performance bottleneck that causes your game to run slowly. When the game is slow, check whether you have written some inefficient scripts first, instead of simply blaming RM for its stupidity!