Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 53
Текст из файла (страница 53)
Setting up EGL for use with,say, Open GL ES generally requires the following steps:1.Get the main native display using eglGetDisplay().2.Initialize EGL by calling eglInitialize().3.Specify the properties of the configuration you would prefer. Aconfiguration includes attributes such as buffer size, colour depthand the existence (or not) of ancillary buffers such as the stencilbuffer.4.Use the eglGetConfigs() and eglChooseConfig() methodsin sequence to find the best match based on the device characteristics.5.Create a window surface with eglCreateWindowSurface()which is where frame-buffer contents will be blitted across to wheneglSwapBuffers() is called during each iteration of the gameloop.6.Create an EGL graphics context using the eglCreateContext()method and the configuration found at step 4.
The context storesstate information used by the OpenGL ES graphics pipeline and anystate changes made by it will be updated in the context object. It willbe initialized to default OpenGL ES values.7.Bind the context, surface and display together by calling eglMakeCurrent(). This tells OpenGL ES which context to use since youcan actually have multiple context within the same application.OPENGL ES231The setup process described above would normally be performed inthe second-phase constructor (the ConstructL() method) of a CBasederived class, with the display, context and surface objects being ownedmembers of the class.It is also vital to free up all EGL resources (as in any resourceconstrained environment) and the obvious place to do this is in the classdestructor. This normally consists of four steps:1.
Set the current context to nothing with eglMakeCurrent().2. For each context that was created, call eglDestroyContext().3. Free up the EGL surface with eglDestroySurface().4. Terminate the display by calling eglTerminate().By providing this abstraction layer, the EGL standard promotes standardization across devices and will greatly ease game ports across thewide range of windowing systems available in the mobile device market.It plays a key role in the OpenKODE standard by acting as the communications layer for interactions between sub-systems such as OpenVG andOpenGL ES, the latter of which is the subject of the next section.7.8 OpenGL ESAs a concept, OpenGL ES ranks right up there with the greatest of allhuman achievements and no – I’m not exaggerating. If you’ve actuallybeen lucky enough to witness just how good hardware accelerated 3Dgraphics can look on a mobile phone, you’ll know what I mean. It notonly stands on its own as a mature technology, but it also providessupport to other higher level libraries, such as the Mobile 3D GraphicsAPI for Java ME.Symbian has provided a software based implementation of the OpenGLES 1.0 standard since Symbian OS v8.0a, and both S60 3rd Edition andUIQ 3 SDKs provide plug-ins to upgrade it to OpenGL ES 1.1.8 In fact, theS60 3rd Edition FP1 SDK includes the OpenGL ES 1.1 plug-in by default.Currently, Symbian smartphones with support for hardware accelerated3D graphics include the N82, N93 and N95 from Nokia, the P990, M600and W950i from Sony Ericsson and the MOTORIZR Z8 from Motorola.8You can find the plug-in for S60 3rd Edition development at: www.forum.nokia.com/info/sw.nokia.com/id/36331d44-414a-4b82-8b20-85f1183e7029/OpenGL ES 1 1 Plugin.html or by searching for ‘OpenGL ES 1.1 Plug-in’ from the main page of the Forum Nokiaweb site at www.forum.nokia.com.The OpenGL ES SDK for UIQ 3 is available from developer.uiq.com/devtools uiqsdk.html.232 C/C++ STANDARDS SUPPORT FOR GAMES DEVELOPERS ON SYMBIAN OSClearly, this opens the way to a level of quality in game graphics that hasnot been seen on mobile phones before.
The Nokia devices all have thePowerVR MBX graphics processor from Imagination Technologies, whichyou can read about at www.imgtec.com/PowerVR/Products/Graphics/MBXLite/index.asp. Sony Ericsson devices contain the ‘Lite’ version ofthe same processor.OpenGL is a software interface to graphics hardware that has been a2D and 3D graphics standard on PCs for well over a decade. Although itis the graphics world’s workhorse, it wasn’t designed to run on embeddeddevices such as set-top boxes, PDAs, and mobile phones with theirrelatively limited processor speeds, memory budgets and low powerconstraints. Also, most embedded devices don’t support floating pointoperations in hardware because FPUs add to manufacturing costs.
Whilemost emulate floating point operations in software, this is way too slowfor the speeds needed for real-time 3D graphics rendering in a high-endgame. In the absence of an FPU, the only way to go is to use a fixed pointrepresentation for decimal numbers, which we’ll have a brief look at inthe next section.So in 2002, the Khronos Group looked at the OpenGL 1.3 standard andcreated the OpenGL ES 1.0 specification. To address the wide variance inembedded device capabilities, three profiles were defined – the Commonprofile, the Common-Lite profile and the Safety Critical (OpenGL ES-SC).The last is intended for use in automotive and avionics displays and usesa minimal implementation, so that the safety certification process is aseasy as possible.Both the Common and Common-Lite profiles are subsets of OpenGL.They introduce support for S15.16 fixed point decimal numbers whichcan be used for vertex attributes, command parameters, 3D matrix opsetc.
The main difference between the two profiles is that the Commonprofile also supports normal floating point decimal numbers, whereas theCommon-Lite only allows the use of fixed point numbers.When version 1.0 was defined, the devices around were fairly limited,and so they had to be pretty strict about what could stay and what hadto go. It was envisioned (correctly) that later versions could include moreadvanced functionality to take advantage of better hardware as it becameavailable. In the meantime, many redundant or expensive APIs wereremoved or made optional, data types (doubles) were removed, and newversions of existing functions were added to allow the use of smaller datatypes like unsigned bytes.Other features that were removed include support for display lists andglBegin()/glEnd() since all vertex data in OpenGL ES is specifiedusing vertex arrays exclusively. You also can’t specify user-defined clipplanes and most of the imaging support has been removed as well.
Texturing is also limited – you can’t control the level of detail (LOD) in mipmapgeneration, cube maps are out and so are 1D and 3D textures. For a moreOPENGL ES233detailed summary of the differences between OpenGL and OpenGL ES,it’s worth reading the difference specification available on the Khronoswebsite at www.khronos.org/registry/gles/specs/1.1/es cm spec 1.1.10.pdf.OpenGL ES 1.1 is all the rage at the moment. It is based on OpenGL1.5, which introduced a wide range of new functionality and, whileobviously not all of it could be included, some significant features foundtheir way into OpenGL ES 1.1:• ability to perform most multi-texturing operations (because implementations must now support at least two texture units)• automatic mipmap generation• required support for at least one clip plane• ability to query most dynamic states• support for vertex buffer objects (VBOs).This last feature is particularly valuable for embedded devices.
VBOsallow you to store frequently used geometry in video memory whichmeans it doesn’t have to travel across the bus every time you want touse it. When you put data in a buffer you also specify how you intendto use the data (provided once or provided repeatedly) which allowsOpenGL/OpenGL ES to optimize for performance.Now even though times are changing and we’re starting to see someof the first devices on the market with dedicated FPUs, it’s still a goodidea to avoid using floating point values altogether. At this stage, there’sjust not enough market penetration and it’s usually unnecessary, as fixedpoint arithmetic will generally provide sufficient accuracy for renderingand simulation calculations.So it’s 2007/2008. OpenGL ES 1.1 is widely used, and there’s supportfor development on the latest Symbian smartphones using the most recentSDKs. We’re seeing the first hardware accelerated 3D graphics handsetsappearing on the market using the PowerVR GPU and it’s all new andexciting.
There’s only one thing missing – shaders.Vertex and fragment shaders are simply small programs that replacesections of the traditional fixed function pipeline. Apart from the fact thatusing shaders allows a wide range of operations and effects that are justnot possible with fixed functionality, the important thing is that whenyou use shaders you have far more control over what is done at keysteps. So this allows you as the programmer to optimize rendering andreduce power consumption, since you get to choose which operationsare applied and which aren’t.OpenGL 2.0 introduced shaders and frame buffer objects, which allowyou to render to texture – so you can draw a scene and then use that234 C/C++ STANDARDS SUPPORT FOR GAMES DEVELOPERS ON SYMBIAN OSimage as a texture for some other world object, if that’s what you want todo.
High level shaders are written using the OpenGL Shading Language(OpenGL SL) which looks a lot like C but has specific constructs forgraphics programming.For embedded systems, the equivalent version is OpenGL ES 2.0(www.khronos.org/opengles/2 X); clearly, the optimizations outlinedabove are going to be even more valuable when you’re working withmobile phones. The shading language also has a cut-down version calledthe OpenGL ES SL (no surprises there).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
