Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 18
Текст из файла (страница 18)
Symbian OS is a multitasking operatingsystem, meaning that other applications are running alongside the game.So, because the memory resources available are finite, the availablememory may suddenly be very limited.It would make a bad user experience if, halfway through shootingan enemy, the game crashed or closed because there was insufficientmemory to continue. It is important, therefore, for a game to reserve allthe memory it will need at start up, so it can guarantee to satisfy allmemory allocation requests. If the memory cannot be reserved, the gamestartup should fail and ask the user to shut down other applications beforetrying to play.It is quite straightforward to allocate a pool of memory to a game, bysetting the minimum size of its heap using the EPOCHEAPSIZE specifierin its MMP file.4 If the game process succeeds in launching, then thisamount of memory is available to the heap – for all memory allocationsin the main thread, or any other thread within the process, as long asit uses the same heap.
This approach makes writing code that allocatesheap-based objects within the game quite straightforward – you don’thave to check that the allocation has succeeded in release builds, as longas you profile and test every code path to ensure that, internally, the gamedoes not use more memory than was pre-allocated to it.However, if your game launches any separate processes (e.g., SymbianOS servers) or places heavy demands on those already running (forexample, by creating multiple sessions with servers, each of which usesresources in the kernel) then this approach will not be sufficient toguarantee the game will run if the phone’s free memory runs low.
Again,the game should attempt to allocate the resources it needs, includingthose in other processes, at startup – or have a means of graceful failureif this is not practical and a later resource allocation fails.When pre-allocating memory for the game, it is important to make aneducated guess at what is required, rather than simply reserve as muchof the memory as is available on the device.
Games for the N-Gageplatform, for example, which are typically the highest quality rich contentgames available on Symbian OS v9, limit themselves to a maximumallocatable heap size of 10 MB.5 So if you are writing a basic casualgame, you should certainly try to stay well under this limit! Your gamewill not be popular if it prevents normal use of the phone, such that it4The minimum size of the heap specifies the RAM that is initially mapped for the heap’suse.
By default it is set at 4 KB. The process can then obtain more heap memory on demanduntil the maximum value, also set through use of the EPOCHEAPSIZE specifier, is reached.By default, the maximum heap size is set at 1 MB.5N-Gage games are tested and certified prior to release (as we’ll describe in Chapter 8)and the 10 MB limit is enforced throughout the launch, execution and termination of thegame.MATHS AND FLOATING POINT SUPPORT59cannot run in parallel with other applications. Since many applicationsfor Symbian OS v9 require Symbian Signing, which verifies the generalbehaviour and ‘good citizenship’ of the application, you need to staywithin self imposed limits. You should also consider advice and bestpractice for memory usage on Symbian OS, including regular testing formemory leaks, for example, by using debug heap checking macros like__UHEAP_MARK.
Wherever possible, de-allocate and reuse memory thatis no longer required to minimize the total amount your game needs.Some developers create memory pools for managing their memoryallocations in order to minimize fragmentation of the heap, use memorymore efficiently, and often improve performance. A common approachis to create a fixed-size pool for persistent data and then use a separatepool for transient data, which is recycled when it is no longer needed inorder to minimize fragmentation.You can find more information about working efficiently with limitedmemory in most Symbian Press C++ programming books, and generaladvice in Small Memory Software: Patterns for Systems with LimitedMemory by Noble and Weir, listed in the References chapter at the end ofthis book.
There is also a set of tools available for checking memory usageand profiling code on Symbian OS. You can find more information aboutthese from the Symbian Developer Network (developer.symbian.com).Disk space refers to the non-volatile shared memory used to store aninstalled game, rather than the main memory used to store the game’smodifiable data as it executes. Some Symbian smartphones, like theNokia N81 8 GB and N95 8 GB have large amounts of space (8 GB)for internal data storage, but the typical internal storage size for otherSymbian OS v9 smartphones can be as limited as 10 MB. However, userscan extend their storage with removable drives such as mini SD or microSD cards or Memory Sticks. The drive letter for the removable media mayvary on different handsets and UI platforms (for example, the removablemedia is sometimes the D: drive and sometimes the E: drive).
You canuse the RFs::Drive() method to determine the type of drive, andRFs::Volume() to discover the free space available on it.When installing a game, there must be sufficient disk space to containthe installation package for the game, and subsequently decompressand install the game and its asset files. It is desirable to keep a gamefootprint – the storage space it occupies – as small as possible if it is tobe downloaded over-the-air (OTA), since a very large game will be morecostly and slower to download over a phone network.2.8 Maths and Floating Point SupportGames that require a number of physics-heavy calculations (for example,those modeling acceleration, rotations, and scaling) typically use floating60SYMBIAN OS GAME BASICSpoint numbers. Most current ARM architectures do not support floatingpoint instructions in hardware, and these have to be emulated in software.6 This makes the use of floating point numbers expensive in termsof processing speed when thousands of operations are required.
Wherepossible, calculations should instead be implemented using integers orfixed-point arithmetic, or they should be performed in advance on a PCand stored in static lookup tables to be used at run time in the game. It israre that high precision is required for geometric operations such as sin,cos, and square root, so there is room for optimization, for example, forsin and cos, the Taylor series can be used to approximate sin and cos toa number of decimal places.The use of 32-bit integers should be preferred where possible; 64-bitintegers have run-time performance and memory consumption overheads,and are rarely needed in practice.2.9 Tools and Further ReadingThis chapter has discussed some of the basic aspects of creating a wellbehaved game loop, handling input, managing interruptions and userinactivity, and coping with resource limitations.Where the performance of the game is critical, we advise you to analyzethe code for each device it is to run on, since devices and platforms canhave very different characteristics.
A good tool for performance analysisis the Performance Investigator, delivered with Carbide.c++ Professionaland OEM Editions. A profiling tool, it runs on an S60 3rd Editiondevice and collects information about processes, memory, CPU usage,and battery usage. Within Carbide.c++, the trace data collected canbe reviewed and analyzed. More information, and a white paper thatdescribes the Performance Investigator tool, giving an example of how touse it, can be found at www.forum.nokia.com/carbide.For more information about general C++ development on Symbian OS,we recommend the Symbian Press programming series, described in theReferences and Resources section of this book.
There are also a numberof papers available on the developer websites listed in that section,including a discussion forum specifically for C++ games development forS60 on Forum Nokia at discussion.forum.nokia.com/forum.6Some of the high-end phones based on ARM11 processors do have floating pointsupport, for example, the Nokia N95. To use it, code must be compiled with a particularversion of the RVCT compiler, with floating point hardware support options enabled. Theresultant binaries do not execute on hardware without floating point support.3Graphics on Symbian OSTwm Davies(twmdesign.co.uk/theblog)3.1 IntroductionThis chapter aims to provide the reader with an understanding of thefundamental graphics services on Symbian OS.
It covers a range of topicsfrom the basics of drawing geometric shapes to the playback of video. Atthe same time, it addresses some of the challenges of drawing efficientgraphics to the screen.Symbian OS is a generic mobile OS and, as such, provides APIs to suita variety of graphical applications, from list boxes and rich text editors tocomplex 3D projections. As a result, the range of graphics APIs is vast andthere seems to be many ways of achieving the same task. This chapterfocuses on a cross section of APIs and usage patterns which are mostuseful to have in a game developer’s tool chest and provides fragmentsof code which demonstrate correct usage of Symbian APIs.The discussion and example code projects found within this chapterare based on Symbian OS v9.2, tested on the Nokia N95 and SonyEricsson M600i (based on Symbian OS v9.1) smartphones.
I expect thecontent to remain compatible with changes to the Symbian OS graphicsarchitecture that are anticipated in v9.5.Speaking of which, in October 2007, Symbian announced ScreenPlay(www.symbian.com/symbianos/screenplay) which is the name for thenew graphics architecture for Symbian OS.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
