Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 19
Текст из файла (страница 19)
It provides a window composition engine much like that found on Apple OS X and Microsoft Vista. Atthe time of writing, there isn’t much additional information available, butby the time this book is published you can expect to see more informationabout ScreenPlay on the main Symbian website at www.symbian.com.62GRAPHICS ON SYMBIAN OS3.1.1 Example CodeThis chapter makes occasional reference to the Roids example gameon the Symbian Developer Network website (developer.symbian.com)which is a complete game with full code made available for UIQ 3 andS60 3rd Edition.
Just search for ‘Roids’ at the main page, or navigatedirectly to developer.symbian.com/ roidsgame.Code fragments beginning with CGfx are part of the example code togo with this chapter. The example code covers the following:• drawing to the screen using a graphics context (GC)• directly manipulating the pixels of the frame buffer• synchronizing updates using the anti-tearing API• loading images using the image conversion library (ICL)• video playback using the Symbian video playback utility.The example code can be downloaded from the Symbian Press websitedeveloper.symbian.com/main/learning/press, and from the book’s pageon the Symbian Developer Network wiki (developer.symbian.com/wiki).3.2 OverviewThe original graphic services provided by Symbian OS evolved from theneed to supply a PDA UI toolkit which shared similarities with desktopsystems. The windowing system and application model were designedwith multitasking in mind and have always been focused on effectivesharing of the display.Though the early frameworks of Symbian OS are very much alive inSymbian OS v9.x, a whole range of additional APIs and features havebeen developed to power the visually rich applications and games builtfor Symbian smartphones of late.
Modern Symbian devices are expectedto deliver sophisticated 3D visuals, smooth animation and bi-directionalvideo streaming out of the box, which is good news for game developerssince many of these APIs are part of the public SDKs for SymbianC++ developers.Not all devices are equal; the role of an operating system, and anymiddleware running on top of it, is to shield applications from differencesin hardware. However, games have traditionally been tuned and releasedseparately for specific devices. It’s very challenging to create a pleasingcross platform game, since gameplay and performance can be influencedby the differences in basic hardware characteristics, particularly thescreen and input methods of a device.OVERVIEW63Symbian OS devices offer little relief to those demanding a homogenousplatform since handset capabilities, software versions, and screen sizesdiffer, depending on the market segment and the device manufacturer.3.2.1 Cross Platform SupportTo illustrate some of the problems with supporting multiple devices,consider the deployment of a simple very game.
Roids is a simpleAsteroids clone which was originally written and tested on S60-baseddevices and the UIQ emulator.1 Roids relies on a 4-way cursor/joystickto give the user dexterous control of a spacecraft. When the UIQ testdevice arrived (a Sony Ericsson M600i), the SIS installation file for thegame installed okay and the game launched; but there was no way ofgenerating 4-way cursor events, since the M600i has no joystick!A modification was required to simulate the joystick events by pressingother keys, which was functional but lost some of the feel of the versionrunning on Nokia E61.
The M600i does however have a touch screenand stylus, which makes it great for games optimized for touch.To this end, it is sensible to set the expectation that, although S60 andUIQ have a strong binary compatibility within their respective platforms(for example S60 3.1 apps should work on S60 3.2 and onwards), somestyles of games may require significant modifications to retain the usabilityor fluidity which characterizes the game, when run on devices differentfrom that for which it was originally designed.
A good tip to remember isthat, before committing to using a particular API on a device, it’s best toassess how widely it’s supported and what the performance is like on thetarget device or devices.A good level of device independence can be achieved by using graphics APIs with wide industry support such as OpenGL ES and OpenVG.These standards work particularly well for games, since 3D and vector game worlds can scale across screen sizes, allowing the developerto focus on the game design while the hardware engineers and handset manufacturers can work on optimizing the implementations to thehardware in question.The reality is that a consistent user experience across a range of devicescan only really be assured by either extensive testing or by establishinga minimum supported device configuration. Developer platforms suchas the N-Gage platform, described in Chapter 8, use both approaches toprovide a common target for game developers.3.2.2 Hitting the MetalGame developers have a long heritage of innovation in creating impressive smooth visuals and extracting optimum performance from a target1As I mentioned in the introduction, you can find the code for Roids, and a white paperdescribing it, on the Symbian Developer Network at developer.symbian.com/roidsgame.64GRAPHICS ON SYMBIAN OSdevice.
The term ‘hitting the metal’ refers to accessing a hardwareresource, such as the screen or keyboard, directly from application code,that is, by avoiding the APIs the operating system wraps over it, dealing with interrupts, and setting up the hardware directly. This approachwas possible when games were developed for dedicated game consolehardware or the game was running as the sole task on a home computer.As an example, an established technique on 1980s devices was todrive the game from the ‘vertical blank.’ This technique allowed programcode to run in the periods when the display hardware was turned off,waiting for the screen to complete its vertical blank (which took about20 µs).
Since the vertical blank period occurred regularly every 25th or30th of a second (depending on the television standard), timing the codeto run during this period guaranteed a regular ‘heartbeat’ to help drivethe game – which made synchronizing updates to the display trivial.The general approach to taking over the machine was very wasteful inmany ways, with game developers having to write and maintain mundaneroutines, such as reading from the disk, which made porting the game toanother platform quite laborious. But despite this, the complete controloffered by these environments meant that each CPU instruction wasexecuted because the game developer said so, and games didn’t need toworry about being pre-empted by phone calls, anti-virus software, andso on. Although the CPUs of those devices were hugely underpoweredcompared to today, games were essentially well bounded real-timesystems which could meet the deadlines of high frame rates.
Many of thegame world archetypes and distinctive graphical effects evolved due totricks discovered when using hardware and APIs not designed for games.The challenges for mobile games are somewhat different. On a multitasking system, the applications are virtualized with direct access to thehardware hidden behind a kernel privilege boundary. It’s common tohave a user side component which exists solely to resolve contention ofa scarce resource between multiple clients.
Even with high CPU speedsand support from specialized graphical processing units (GPUs), the challenge of rendering immersive worlds and sustaining good performanceis still a creative art. While a ‘write once, run many’ approach is bestfor deployment of games to the widest audience and hence makes thebest return on an investment, history shows that specific innovations andcompelling games may occur while developing for one particular device.This chapter, in places, refers to some specific APIs which may only beavailable on certain devices.3.3 On Frame RateAs Jo described in the previous chapter, the number of frames whichare rendered to the screen each second is known as the frame rate,ON FRAME RATE65which is measured in frames per second (abbreviated to fps).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
