![]()
CHAPTER 1 | |
|
Getting to Know the iDevice Hardware and Unity iOS |
The technical understanding behind creating game assets is more in-depth than just modeling low-resolution geometry. Before we can get into actual modeling or creating texture maps, weâll first need to have a solid understanding of the hardware and game engine that the content will run on. Each platform or device will have itâs own limitations, and what might run well on one platform doesnât mean it will run as well on another. For instance, the faster processor in the iPhone 4 or iPad, in some cases, may help in the processing draw calls than the slower processor in the iPhone 3GS. Another good example is that although the iPad has a 400 MHz boost in chip performance, the lack of an upgraded GPU introduces new bottlenecks in performance to be aware of. This is where the projectâs âgame budgetâ comes into play. Your game budget is the blueprint or guide through which your game content is created. There are three specifications to be aware of when evaluating the hardware of the iPhone and iPad, which are memory bandwidth, polygon rate, and pixel fill rate. For instance, if you have a fast-paced game concept, youâll need to denote a high frame rate in your game budget such as 30â60 frames per second (fps), and all of the content you create must be optimized to allow the game to meet this frame rate budget. Youâll also need to take into consideration that with the iPad, youâre essentially rendering to a pixel count that is over five times that of the iPhone 3GS and around 1.2 times that of the iPhone 4 screen, which results in 5â1.2 times the amount of data being processed per frame. Without a solid understanding of the capabilities and limitations of the device your game is targeting, you wonât know what optimizations to the game content that will be needed to achieve your gameâs budgeted frame rate. Essentially, it would be like working in the dark.
The goal of this chapter is to turn the lights on so to speak by familiarizing you with the iPhone and iPad hardware as well as take a look under the hood of the Unity iOS game engine. By familiarizing ourselves with the different iDevices and whatâs going on under the hood of Unity iOS, we can then understand the âwhyâ behind building optimized content for these devices. We will also be able to properly determine the frame rate, poly-count, and texture size budgets in our overall game budget, which is determined by a balance of the type of game youâre creating and the targeted frame rate, all of which is ultimately controlled by the hardwareâs memory bandwidth, polygon rate, and pixel fill rate.
Technically Artistic
When discussing game development, topics can quickly become very technical and programmatic as weâre discussing real-time graphic implementations and mobile hardware limitations. Being a 3D artist, I found that it wasnât the modeling and texturing that was difficult in creating game art, but it was in understanding the technical limitations of the hardware and OpenGL implementations to creating real-time graphics that I had a tough time. Not to worry, this chapterâs main goal is to discuss the following topics from the point of view of the game artist.
iDevice Hardware
In this section, weâre going to discuss the hardware for the iPhone and iPad, and at this point, Iâd like to make a couple of distinctions between the device models. Throughout the book, I will refer to the term âiDevicesâ to encompass all of the devices, i.e., iPhone, iPad, and iPod Touch. The term âiOSâ is Appleâs official name for the OS or operating system common to all of the iDevices. Iâd also like to add that this book will not be covering the iPhone 3G or the iPod Touch second generation and below. As of the writing of this book, these devices are second- and third-generation devices, and I wanted to concentrate on the most current devices. Iâll break this section into two categories, which are the ARM central processing unit (CPU) and PowerVR SGX graphics processing unit (GPU). As we cover the iDevice hardware, weâll also discuss how these categories relate to Unity iOS.
ARM CPU
The CPU is the processing unit, and the iDevices use the ARM architecture with the Cortex-A8 core at version ARMv7-A, and from an artistâs perspective, the CPU handles calculations. In Fig. 1.1, you can see a break down of the hardware differences in each of the iDevices. Each model of the iDevices contains different or updated hardware that can affect your gameâs performance such as how the hardware affects pixel fill rate.
Both the iPad and iPhone 4 contain the A4 processor. The iPhone 3GS and iPod Touch third generation both use an ARM Cortex-A8 that has been under-clocked to 600 MHz. As far as performance goes across these three devices, you can say as a basic rule that the iPad is the fastest in terms of processing, followed by the iPhone 4 due to the A4 being under-clocked and finally not far behind at all is the 3GS. Again, I stress that this is a very basic rule, and your content will really drive these results in terms of how pixel fill rate and polygon throughput affect your game. Profiling your game on the devices with your specific content is the safest and most accurate way to gauge performance, but it can be helpful to have general ideas in place about the device capabilities in the early stages of development.
There are many aspects to how the CPU affects your Unity iOS powered game. For instance, the CPU also processes scripts and physics calculations as well as holding the entire OS and other programs being run. Since this book is on creating game art, weâll focus the next subsections to be particular to the gameâs art content on our game objects and what operations are important to the CPU in these terms.
On a particular note, just because one might be more oriented toward the art-side of game development doesnât mean they should steer clear of code, and it certainly doesnât mean that artists canât understand technical aspects. In fact, with independent game development, thereâs a high probability that not only are you building 3D content but youâre coding the game as well. More often than not, I see great scripts and programs written by amazing artists instead of hardcore programmers. The point here being, scripting sometimes has the negative connotation of something to be feared and I say that couldnât be further from the truth. You never know what youâre capable of until you jump in and give it a shot.
Draw Calls
The draw call can be thought of as a ârequestâ to the GPU to draw the objects in your scene and can be the area in which the CPU causes a bottleneck in performance. As weâll discuss in the GPU section, the iPhone and iPad uses OpenGL ES 2.0 (OGLES) emulating OGLES 1.1 shaders on the hardware level, and with this implementation, vertex data is copied for each draw call on every frame of the game loop. The vertex data is the vertices that make up our 3D objects and the information attached to each vertex such as position, normal and UV data, just like a 3D meshâs vertices in modo has positional, normal, and UV coordinate data.
The vertex data is transformed or moved in 3D space on the CPU. The result of this transformation is appended to an internal vertex buffer. This vertex buffer is like a big list or a container that holds all of the vertex data. Since the vertex data is copied on the CPU, this takes up around one-third of the frame time on the CPU side, which wastes memory bandwidth due to the fact that the iPhone shares its memory between the CPU and GPU. On the iPhone and iPad, we need to pay close attention to the vertex count of our objects and keep this count as low as possible as the vertex count is more important than actual triangle count. As youâll read in Chapter 2, weâll talk about how to determine what the maximum number of vertices you can render per individual frame.
Game Loop
Inside the Unity iOS game loop is where the components of our game are updated. The game loop is always running regardless of user input. From a 3D artistâs perspective, you can think of the game loop as an animation. In a 3D animation, your scene runs at a given frame rate, and in each frame of the animation, something is calculated such as key-frame interpolation. A game engineâs game loop is basically doing the same thing.
I used to get confused by the âper frameâ section of that statement. It helped me as a 3D artist to think about my game scene just like a scene in modo. For instance, if I have an animation setup in modo, the render camera will render the portion of that scene that the camera can see in its view frustum as set in the cameraâs properties, for each frame of the animation. The same is true in Unity iOS. In Fig. 1.2, you can see an illustration that depicts the way in which I visualize a sceneâs total vertex count per frame.
With each frame of the game loop, only a certain amount of vertices are visible within the cameraâs view frustum for a given frame, and within this frame, we should keep the vertex count for all of the objects in the scene to around 10 k. Now, this is a suggestion as to what works best on the iDevice hardware, but depending on your game and game content, this could possibly be pushed. The point being, with game development, there arenât any absolute answers when it comes to optimization. You have to optimize content to your gameâs performance standards, i.e., your frame rate budget. There are a lot of techniques to optimizing our vertex count as weâll discuss in the modeling chapters, and there are also rendering optimizations for the cameraâs view such as occlusion culling for controlling vertices that are sent to the vertex buffer.
Itâs obvious that the faster the CPU, the faster the calculations are going to be. However, just because you have more power doesnât necessarily mean you should throw more vertices to the system without regard to other performance considerations such as pixel fill rate as weâll discuss later in this chapter.
Batching
Batching is a means to automatically reduce draw calls in your scene. There are two methods in Unity iOS, which are dynamic and static batching. Itâs important to note that draw calls are a performance bottleneck that can largely be dependent on the CPU. Draw calls are generated each time the CPU needs to send data to...
