Irrlicht engine source code analysis-irrlichtdevice

This article discusses irrlichtdevice and discusses the following issues:
-> Irrlicht abstracts devices.
-> How to implement cross-platform
-> Win32 device Implementation Details

1) engine cornerstone-irrlichtdevice
What device does irrlicht mean? Exploring the irrlichtdevice interface, the irrlicht device is an abstraction of the Application Window environment, which actually corresponds to the application framework on each platform. In the irrlichtdevice interface, there are application lifecycle operations such as run (), closedevice (), yield (), and sleep (), as well as setresizeable (), setwindowcaption: In addition, the device also holds video driver, Scene Manager, Gui enviroment, file system, and other objects, from the interface, you should construct and manage these objects in the specific devices that are implemented. Irrlichtdevice can be regarded as the cornerstone of the engine, supporting the running of the 3D engine on the target platform. If the engine we designed is to be cross-platform, we must make such abstraction.

2) how to implement cross-platform Devices
When using the irrlicht engine, you must first call a global function: createdevice (), which is implemented in the source file irrlicht. in CPP, the real task is createdeviceex (). The declaration of this function is the same as that of createdevice () in irrlicht. h, but implement cirrdevicexxx on different platforms. CPP. Irrlicht uses the compilation option to ensure that only the relevant code of one platform is compiled, so the createdeviceex () definition does not appear multiple times. On Windows, _ irr_use_windows_device _ is defined, while others such as _ irr_use_linux_device _ are not defined. Therefore, the device-related code file is cirrdevicewin32.h/. cpp. In irrcompileconfig. H, it can be found that if _ irr_use_sdl_device _ is defined, _ irr_use_windows_device _ is not defined, and the SDL device works. In short, only one platform is defined, only one device is created, and only one createdeviceex () exists. By using compilation options and macro definitions, the compiler will only compile the code of a certain platform to build an IRR device of a certain platform.

3) Win32 device source code analysis
As mentioned above, on the Win32 platform, only cirrdevicewin32.h/. cpp will be compiled. Check the source code and first find:
Class cirrdevicewin32: Public cirrdevicestub
In computer programming, RMI calls customer-assisted objects stub. cirrdevicestub is a set of common functions that can be used by all device types and a base class for assistance. Let's take a look at this class. The source code is cirrdevicestub. h/. cpp. This class will not create a specific irrdevice (obviously, it is a helper class shared by various platforms, and of course it will not care about a specific device, this class holds and manages some objects that can be seen on irrdevice interfaces, such as filesystem. Of course, filesystem itself is a cross-platform implementation, which is a form, another form is that stub provides a function, but it does not call it. Specifically, createguiandscene () creates guienvironment and scenemanager, which are called in the subclass. In addition, Stub also implements the getxxx () series interface.
Stub only tries to extract some operations that are common to all platforms. The real thing still needs to be implemented on their own platforms.

The following is an analysis of Win32 devices.
<1> Create a device
First look for createdeviceex (), where only a new cirrdevicewin32 object is found, and check whether the object is successfully created. The main creation is still in the cirrdevicewin32 constructor. The main work in the constructor is to create a window (you can also use the externally passed windows hwnd), create a driver, create a GUI and scenemgr (call createguiandscene () in stub ()). The key here is to create a driver. irrlicht can support multiple types of drivers at the same time and select the driver before running. That is to say, these drivers are compiled (instead of compiling only one driver as the device), at createdriver () the createparams driver is used to determine which driver to create. The hardware driver, such as Dx and OpenGL, is in the platform code, and the software driver and null driver are in stub. In the device of the Linux version, we found that only the hardware driver such as OpenGL is supported. Of course, Linux does not support dx.
<2> Run and close the device
From the brief example, we can see that the main loop of the game is carried out by judging whether the device is run. Run () for Win32 is as follows:
View plaincopy to clipboardprint?
Bool cirrdevicewin32: Run ()
{
OS: Timer: Tick ();
MSG;
Bool quit = false;
While (peekmessage (& MSG, null, 0, 0, pm_remove ))
{
Translatemessage (& MSG );
If (externalwindow & msg. hwnd = hwnd)
Wndproc (hwnd, MSG. Message, MSG. wparam, MSG. lparam );
Else
Dispatchmessage (& MSG );
If (msg. Message = wm_quit)
Quit = true;
}
If (! Quit)
Resizeifnecessary ();
If (! Quit)
Polljoysticks ();
_ Irr_implement_managed_marshalling_bugfix;
Return! Quit;
}
Bool cirrdevicewin32: Run ()
{
OS: Timer: Tick ();
MSG;
Bool quit = false;
While (peekmessage (& MSG, null, 0, 0, pm_remove ))
{
Translatemessage (& MSG );
If (externalwindow & msg. hwnd = hwnd)
Wndproc (hwnd, MSG. Message, MSG. wparam, MSG. lparam );
Else
Dispatchmessage (& MSG );
If (msg. Message = wm_quit)
Quit = true;
}
If (! Quit)
Resizeifnecessary ();
If (! Quit)
Polljoysticks ();
_ Irr_implement_managed_marshalling_bugfix;
Return! Quit;
}
OS: Timer: Tick () is used to record the system time. This is global. The irrlicht engine is based on time instead of fixed frames. This issue will be analyzed later. The following is a common peekmessage Windows message loop. The focus is on the return value. Only when the window receives the wm_quit message, run () returns false. The Window quit can either close the window directly or call the closedevice () of the device by the game ():
View plaincopy to clipboardprint?
Void cirrdevicewin32: closedevice ()
{
MSG;
Peekmessage (& MSG, null, wm_quit, wm_quit, pm_remove );
Postquitmessage (0 );
Peekmessage (& MSG, null, wm_quit, wm_quit, pm_remove );
Destroywindow (hwnd );
}
Void cirrdevicewin32: closedevice ()
{
MSG;
Peekmessage (& MSG, null, wm_quit, wm_quit, pm_remove );
Postquitmessage (0 );
Peekmessage (& MSG, null, wm_quit, wm_quit, pm_remove );
Destroywindow (hwnd );
}
<3> Other interfaces
In wndproc, the window message processing function contained in Win32 device processes events such as keyboard and mouse and converts them to irrlicht messages. Device also implements the iimagepresenter interface, which has only one method present. Only the software driver will use it to draw the buffer to the screen. There are also thread control methods such as sleep () and yield.

Summary: A game has a device object. device abstracts the operating systems of different game platforms, provides interfaces for running and disabling, encapsulates the creation of driver, and stores driver and GUI, scene Manager, file system, and other globally unique objects. Imagine if we want to add a new game platform for irrlicht, such as PS3, what should we do? Of course, it is necessary to implement these interfaces in line with IRR semantics, and the program will run as usual, maybe you want to try.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/n5/archive/2009/07/07/4329603.aspx