Symbian game programming (2)

Translation: huwell

Window Server Window Server is used by all GUI applications, which is provided to an interface to make them more convenient to interact with other applications. The main task of this Server is to manage system resources, like access to the screen and keyboard, which is performed using the Client-Server architecture in the Symbian system, so the control of the shared resource is more powerful. Customer and Server run in different processes, can not directly access their memory address area, so communication between them is to pass through a message, this channel between Client and Server becomes a session, After the session is open, a Client can use the session to send a message to the Server side to complete a request for Server. This message includes a 32 bit request type operator code, and a maximum of 4 32 bit of parameters. After the request is complete, Server returns a 32bit completion code to the client, and Server can use inter-process communication services to send and receive additional data. Each Client application communicates with Window Server uses a Window Server Session class: RWSSession, this class's main task is to coordinate asynchronous events sent to the application, such as redraw events, Priority Key Events, and standard events include user input Events, Window Server will determine which applications and windows accept this event. For example, a keyboard event can only be sent to a window with focus, while a redrawing time can only be sent to the currently visible window in the application. Due to the Higher Process Priority of The Window Server, The Events Are Handled with Higher Priority Than Applications' Other Requests. (1) Requirements for Window Server are typically processed by: 1). window server's client side processes the request. 2). A context switch from the client process to the server process occurs. 3). the window server processes the request, 4). A context switch back to the client process occurs. this method ensures that The request has been processed when the request is processed in the correct step, and when the last control is re-returned to the client, the request has been processed. In any case, environmental switches between the two processes are very complicated, which will have a relatively large overhead.

Even though, the window server has been implemented as a fixed process, which has a fixed virtual address area and hence does not need also has its address pointers to be updated, the context switch originates unfounded speed losses. The clients, raising a request, to wait for a synchronous response. for most of the requests, including drawing methods, this is unnecessary. Because of these drawbacks, the asynchronous function calls are buffered in a client side window server buffer. in the GT versions of the Symbian OS the buffer size has been fixed to 640 bytes. Series 60 has grown the buffer to 6400 bytes, and added support for applications to alter the buffer size. (Note) Larger buffer size is especially valuable in applications where drawing consists of a number of drawing functions or Large Amount of TEXT. THIS CAN BEEN As Decreased Flickering. The Buffer Size Can Be Changed In The ConstructL of The Application's UI Class: Void CMYAPPUI :: ConstructL () {baseconstructl (); // ws buffer size can be set after the BaseContructL is called RWsSession & ws = iEikonEnv-> WsSession (); TInt bufsize = 10000; ws.SetBufferSizeL (bufsize); // Continue normal app UI contruction iMyView = new (ELeave) CMyMainView; iMyView-> CONSTRUCTL (IMYVIEW);} This way, all Methods will be sent to Window Server in a Message when the buffer is sent, so that only two environment switches occur, thereby reducing the load .

Usually buffer occurs in the following cases: 1, buffering 2, one synchronous method is called 3, EventReady (), redReady () or priorityKeyReady () is called 4, flush () is called, or 5, one can cause buffering overflow method is called If a drawing is initiated in response to another event than a window server event, an explicit Flush should be called. This is the case, for example, in games, where drawing is usually initiated in response to a timer event . (2) Windows application draws on the screen To use Windows, they are managed by Window Server. The following figure depicts the relationship between different WINDOW classes: border = 0> (WindowsGroup.gif) All windows They are all derived from the base class: rwindowtreenode, this base class specifies their Z-Order. The displayable window is also derived from an abstract base class, which is rwindowbase. Rwindow is a standard window that can be drawn or redrawn according to the requirements of the program. RBACKEDupWindow shows such a window that stores its own content in a backup bitmap. When RBackedupWindow is valid, The Window Server Redraws It AutomaticLom The Backup Bitmap, WITHOUT Requiring An Application RedRAW. All from RwindowBase is born class, with a display mode (Display Mode) for specifying its color depth. The display mode is defined by the TDISPlayMode type, and the specific mode is generally consistent with the screen. RWindowGroup is a non-drawable window that is invisible on the screen. The main function of rwindowGroup and to form a group for the applications' Other Windows. Generally speaking that there is a Window Group for all button events. The applications are all a tree hierarchy, and the most endpoint is Windonw Group, so each drawable window has a parent window and one or more brothers and sub-windows. The z-Order of the window is specified by their original location, this location and their parent window and keeps unique in the brothers window. Of course, we can change the Drawing ORDER of its window by changing this location. The front window and the Window Group have 0. The original location of Window Group is also associated with their priority. There is an API to access the original location of the window and define in rwindowtreenode. (3) Control Environment The Window Server Provides a Relative Low-Level Interface, Which Should Be Encapsulated in Active Objects Due to the Asynchronous Services.

The application can implement it, but the system provides an intermediate layer between Window Server and our programs, which is Control Environment (CONE), which encapsulates the service provided by Window Server. CONE runs in the process of each program and is used by all applications with GUI. The base class of the CONE is CCoeenv, which is an active object that is executed when its Runl function is accepted from the Window Server. The main task of CONE is to evaluate these events and forward them to each of the appropriate components. CONE provides a clear stack, an Active Scheduler, and some utility. CONE uses this Active Scheduler to manage asynchronous services from Window Server. The priority of the keyboard event exceeds the redraw event so that the program can respond faster in response to the user's input. CONE provides the control (Control), which is the most basic interactive unit in the Symbian system, and each Drawable window contains one or more controls, which is inherited from abstract base class CCoecontrol. A Control, which has the entire window is called Window-Owning Control, and only partial window is called a non-window-owning control, such as parasitic controls. Why introduce the control there because they provide more advantages than the window. First, they saves memory more than the window, and they also reduce the necessary client-server communication between an application and Window Server, because it is necessary to redraw a Component only one event, regardless of how much contrap it has. The redraw events are generated for windows and thus a component which consists of more than one window, would need more than one redraw requests. Also the logic to detect intersections, is simpler with controls. Control as can be nested like window, a compound control Two functions should be overloaded: CountComponentControls and ComponentControl. Compound Control also needs to handle assignment issues for button events. Maintain a control stack in a CONE to manage the Channeling for the Application, the control stack includes a list of controls that need to press the key event. The event will be passed to them based on their position in the stack. CONE CANTROL AND CCOEAPPUI DERIVED CLASS Using The IcoEenv Class Member. If they are not available, you can get used by static functions ccoeenv :: static (), which will return a pointer to CCoeenv. Note that this method can only be used without a way to access it because Thread-Local Static (TLS) is used here, it is very slow. (4) UI Library CONE does not provide any specific UI components, which are provided by the UI library. S60 provides a UI library, AVKON, which is extended and modified from the standard Symbian system UI library - ookon - Avkon provides a variety of components that are tailored for S60 screen. The AVKON UI component can be divided into 3 large categories according to their layout on the screen: Status PANE, Main PANE, and Control Pane.

See the figure below: Border = 0> (ThreePane.gif) Status Pane includes several sub-PANE: Signal Pane, Context Pane, Title Pane, Battery Pane, UNI Indicator Pane, and Navi Pane. Each program has an instance of a state PANE, which is automatically generated when the application starts start. Here Signal Pane, Battery Pane, and UNI Indicator Pane are belonging to a System Side Server, which cannot be changed by the application, and other PANEs are possible. Main is where the application data is displayed normally. The Avkon UI library provides a variety of components that can also generate their own controls for Main Pane. The components provided by the Avkon UI library include: List Boxes, Grids, Form, and Different types of pop-ups such as inquiry and options menu. The Control Pane includes SoftKeys and a scroll indicator. Although Main Pane's region has adapted to most of the needs, but to games, more spaces are generally required :), larger game view space encompasses the playability of the game. If you want to overwrite the entire screen, you can call the CCoecontrol :: setExtentTowholescreen function for the clockwise call. Such status and control pane are hidden. They can be done by calling the CCoecontrol :: MakeVisible function (for efalse). Bitmaps ---- Symbian operating system can be considered a Bitmap-Oriented OS. The Symbian system provides its own bitmap format, MBM, which is a multi-bit file. MBM uses a bitmap conversion tool BMCONV from the Windows bitmap. As an MBM, it can include multiple bitmaps, BMCONV generates the Ocean bitmap Header file, the MBG file, which lists the ID of all bitmaps to access them. When a bitmap is to be loaded from an MBM file, you should include the corresponding header file according to the INCLUDE, and the correct ID is given as a given parameter. BMCONV can run from the command line, or in a project file as follows: start bitmap [target-file] header targetpath [targetpath] SourcePath [SourcePath] Source [color-depth] [Source-Bitmap] End BMCONV may generate two Different types of Symbian bitmaps: ROM and NON-ROM bitmaps. The bitmap of the Non-ROM is a general file storage bitmap. It is compressed using Run-length Encoding (RLE), which can be loaded into RAM when they are used, and in order to speed up the drawing speed, the ROM bitmap is not compressed. Therefore, they can be used directly from the ROM. By default, BMConve is generated by file storage bitmap, namely Non-ROM. Note that when making a Sprite diagram, we will use the Mask bitmap because there is only black and white, so it is best stored for 1bit, and S60 provides a command line tool called Makemask, which can generate 1bit in 8bit Bitmaps. . Although the Symbian system provides some APIs to set the palette of the bitmap, but is not implemented.

The Apis Were SuppleMENTED BEFORE ANY Support for Color Displays WAS IMPLEMENTED. Bitmap is managed by the Cfbsbitmap class, which provides a method of generating a load bitmap and defines their own colors depth and size. It uses the RFBSSession class to access the FBS, so the Session class is hidden to the user. CfbsbitMap also provides a method of directly accessing bitmap data. You can get a pointer to the data address by DataAdDress members, or you can access a Specific Scan Line by accessing GetScanline members. The bitmap is also divided into two different stacks in the FBS according to their size, with 4KB as boundaries. Large-sized graphics can be automated disk defragmentation. Because of the need to organize, this pile should be able to locked, here TbitMaputil can provide a stack of lock and unlock, and when we need to lock the heap when the image Data of the bitmap is edited. Drawing and copy provide automatic locking. // Lock the heap if a large bitmap if (bitmap-> IsLargeBitmap ()) {TBitmapUtil bitmapUtil (bitmap); bitmapUtil.Begin (TPoint (0,0));} // Edit bitmap TSize bitmapSize = bitmap-> SizeInPixels ( ); Tuint16 * bitmapdata = (tuint16 *) Bitmap-> dataaddress (); tuint16 color = 0; for (Tint Y = 0; Y islargebitmap ()) {bitmaputil.end ();} This can make bitmaps to draw faster than cfbsbitmaps, Window Server is available Its own bitmap class, cwsbitmap. It avoids additional environmental switches between Window Server and FBS, master Bitmap Handle by autonomy. This cwsbitmap is derived from cfbsbitmap. Note that when the drawing speed is high, we should use cwsbitmap. Drawing --- Application Use Windows to draw on the screen, you can use CWSScreenDevice to implement it, it is connected to CWindowGC, so Graphics's Context and Device have. The Drawing Methods of Cwindowgc Are Buffered On The Client Side Window Server Buffer. Drawing can be triggered when the system or application is initialized, the system initialization is caused when the window is generated, or when the content of the window is invalid. When a window is to be redrawged, Window Server will send a redraw evenet to the application. CONE can handle the redraw processing of the control, which is why each control should process the DRAW method, so that its RedRaw event can be completed correctly.

void CExampleControl :: Draw (const TRect & / * aRect * /) const {// Get the system graphics context CWindowGc & gc = SystemGc (); // Set drawing settings gc.SetBrushStyle (CGraphicsContext :: ESolidBrush); gc.SetBrushColor (KRgbRed ); // Draw gc.drawline (TPOINT (10, 10), TPOINT (30, 10));} The above TRECT parameters indicate that the specific invalid area, most of the controls are ignored this parameter because of their weight Painting is very simple, even if the entire area is not too slow. Drawing of the application requires a change in application data or status. CCoecontrol provides non-virtual functions DRAWNOW () to make Window Server's redraw. CCoecontrol also provides a Drawdeferred method that allows the window to be invalid and re-emit a RedRaw Event from Window Server. The difference between these two methods is that the Drawnow enforcement control immediately redraws yourself, but Drawdeffered is a low priority redraw, because CONE sets the user input to high priority, so the user's input event must first deal with. These methods, no matter how it is aggravated the burden of operation, usually should only tell it to redraw the part. As shown in the following code: void CExampleControl :: DrawBitmap (const TPoint & aPoint, const CFbsBitmap * aBitmap) {// Get the system graphics context and control rectangle CWindowGc & gc = SystemGc (); // Establish drawing rectangle TRect rect = TRect (aPoint, TSIZE (ABITMAP.IWIDTH, ABITMAP.IHEIGHT); // Activate Graphics Context ActiVateGc (); // Invalidate Window Window (). Invalidate (Rect); Window (). BeginredRAW (RECT); // Draw A Bitmap GC. Drawbitmap (Apoint, Abitmap); Window (). Endredraw (); // deactivate graphics context deactivategc ();} (1) sprites sprites is a masked bitmap, which can be moved with a window that does not rehab it. Two different types of Sprites: Pointer and Animated Bitmaps are available in the Symbian system. As shown (spritesclass.gif) rwsspritebase is an abstract sprites base class, which has one or more TSPRITEMBERS, which contains sprite's bitmap data, TspriteMember also defines Mask bitmaps, and bitmap positioning, and rotation Time lapse.

RWSSPRITE is a concrete class of sprites, in addition to constructing, it only provides a method, setPost, we can use it to move this sprite, the following code demonstrates the above content: rwssprite sprite = rwssprite (ieikonenv-> wssession () ); User :: leaveiferror (sprite.construct (window (), tpoint (0, 0); for (Tint i = 0; i <8; i = 2) {IMEMBER [I / 2] .IBITMAP = New (Eleave) cfbsbitmap (); User :: Leaveiferror (Member.Ibitmap-> Load (KbitmapFile, I, Efalse); IMEMBER [I / 2] .Ibitmap = new (eleive) cfbsbitmap (); user :: LeaveifeIFerror (Member.imaskbitmap-> LOAD (KbitmapFile, I 1, Efalse); Imember [I / 2] .iinvertmask = Efalse; Imember [I / 2] .ioffset = TPOINT (0, 0); Imember [I / 2 ] .IINTERVAL = TTIMEINTERVALMICROSECOND32 (100000); User :: Leaveiferror (sprite.Appendme process);} Note Sprite should call RWSSPRITEBASE:: Activate to activate. This SpriteBase :: actiTi You can display it on the screen and move. The Sprite's content can be changed by calling rwsspritebase :: UpdateMember. Cfbsbitmaps are Also Accessible to the window Server, Only the Bitmap Handles of a Sprite Are Sent To The Window Server. This Makes Updating of a Sprite's Bitmaps Con SideRably Fast. When a Sprite is no longer needed, we should call RWSSPRITEBASE :: Close to release the occupied Window Server resource. This does not release the client's member data, which should be deleted. RWSPointercursor can generate a CURSORS, use the RWSSPRITE, only a bit difference, that is, when Pointer is already active, not displayed on the screen until rwindowtreenode :: setPointerCursor is called. (2) Double Buffering When the game contains multiple pictures that need to be moved and more frequent, we should try to fill the client's buffer so that all objects can be updated once. For the user, the screen flicker may occur, we can solve this problem by double buffering methods, the picture first can draw into the OFF-Screen bitmap, and finally do the Window Server action to draw to the screen. . Especially in one second, update the screen multiple times, this method should be used. A OFF-Screen bitmap can generate it by using a bitmap Graphics Context and Graphics Device class: cfbsbitgc, and cfbsbitmapDevice.

When the program is to draw a bitmap in the window, it gets converted Into The Same Display Mode Than the window. This will slow down. For the game, if you want to use a bitmap performance, you should complete this conversion at the beginning of the animation. Liezi can refer to the following: CFbsBitmap * CExampleControl :: LoadAndConvertBitmapL (Const TDesC & aFileName, TInt aBitmapId) {// Load the bitmap CFbsBitmap * originalBitmap = new (ELeave) CFbsBitmap (); CleanupStack :: PushL (originalBitmap); User :: LeaveIfError (originalBitmap-> Load (aFileName, aBitmapId, EFalse)); // Create a new bitmap, graphics device and context CFbsBitmap * newBitmap = new (ELeave) CFbsBitmap (); CleanupStack :: PushL (newBitmap); newBitmap-> Create ( originalBitmap-> SizeInPixels (), Window () -> DisplayMode ()); CFbsBitmapDevice * graphicsDevice = CFbsBitmapDevice :: NewL (bitmapConverted); CleanupStack :: PushL (graphicsDevice); CFbsBitGc * graphicsContext; User :: LeaveIfError (graphicsDevice-> CreateContext (graphicsContext)); TPoint zero (0,0); // Blit the loaded bitmap to the new bitmap bitmapContext-> BitBlt (zero, originalBitmap); CleanupStack :: Pop (3); delete bitmapContext; delete bitmapDevice; delete originalBitmap; Return NewbitMap; If the game has multiple bitmaps that need to be transformed, we should finish it once in initialization scenes or levels. Thereby hide these operations for users. Direct Draw ---- Draw on the screen, use Window Server, which requires the switch to switch, so that the speed of drawing is reduced. Can we spare to Window Server, get rid of the scene switch (CONTEXT SWITCH)? Yes, the program can directly access the screen, and there are two methods in the Symbian to draw directly on the screen. CfbssCreenDevice is such a Graphics Device, which can directly address the screen driver, scdv.dll. After generating cfbsbitgc, it can be used as the other Grahics Device. This can be drawn directly to the screen without having to pass Window Server. The other method is to address the screen.

We can be accomplished by using UserSrv categories: TPckgBuf infoPckg; TScreenInfoV01 & screenInfo = infoPckg (); UserSvr :: ScreenInfo (infoPckg); TUint16 * screenMemory = screenInfo.iScreenAddress 16; 32byte screen memory has a head, we write memory It needs to take it into account. The way to write screen memory is more fast than using CfbssCreenDevice. In some Symbian OS based terminals the screen is automatically updated from the screen memory when the memory is changed, whereas in other. Note that only the effective screen memory address on the target machine terminals the drawing needs to be explicitly activated, so the code required by the The actual machine is still organized, see the following code: #ifdef __wins__ // Emulator Environment // Draw to an off-screen bitmap #else // Hardware Environment // DRAW Directly to the Screen Memory #ENDIF above two method belts Come to a drawback because the Window Server is discarded, so the program will not notify - such as other windows or windows to the front desk. Although the program receives an event when the focus is lost, but this cannot stop painting in time, and the screen may mess. Here is an unapprounded API (before 6.x series) can solve this problem, this API includes two classes: MDirectScreenAccess, which provides a callback function to the application, one is CDirectScreenAccess, which provides with Window Communication between Server. The following code demonstrates how it is constructed: iDRawer = cdirectScreenAccess :: newl (ieikonenv-> wssession (), * ieikonenv-> screenDeendevice (), window (), * this); ieikonenv-> wssession (). Flush () ; iDrawer-> StartL (); iDrawer-> ScreenDevice () -> SetAutoUpdate (ETrue); CDirectScreenAccess where the NewL method would require a window server session, graphics device, CONE application window, and a point derived from the MDirectedScreenAccess Class for parameters.

Before being called to activate the direct draw support in CDirectScreenAccess :: StartL, the client side window server buffer should be flsushed. To make the screen automatically updated, SetAutoUpdate method screen device should call (ETrue use as a parameter), after the work is completed Direct drawing can start working, CDirectScreenAccess generates cfbsbitgc this graphics context, we can draw: idRAWER-> GC () -> Bitblt (TPOINT (0, 0), IbitMap); before another window When the front desk, CDIRECTSCREENACCESS will get an event from Window Server to terminate the drawing. At this time, CDIRECTSCREENACCESS calls the AbortNow method of the MDirectScreenAccess, and our program needs to be overloaded to handle it, in order to prevent screen mess, Window Server will not overlap Drawing on the window, knowing the Abort Drawing event is processed. Article Source: http://symbian.org.cn/bbs/viewtopic.php? T = 907