Systems and methods of perspective polygon-offset layering

Abstract

To provide a technique for rendering a perspective view of a three-dimensional object used in a two-dimensional gameplay.SOLUTION: Three-dimensional objects are arranged into different layers for a perspective-projection scene. During a rendering process, the objects in the scene are drawn or otherwise tested against a depth buffer. The coordinates used for the depth buffer for each object are offset on the basis of which layer has been assigned to that object.SELECTED DRAWING: Figure 3

Description

[Background technology]

[0001] Technical overview The techniques described herein relate to rendering images. More particularly, the techniques described herein relate to generating perspective views of three-dimensional objects used in two-dimensional gameplay by offsetting objects in a depth buffer. Introduction

[0002] Rendering is the process of generating images from models and other data stored in a computer. It is used, among other things, in movies, computer-aided design, and video games.

[0003] Video games can be complex to create. For example, unlike movies or other types of applications or media, video games typically process player input in real time with output given to the player (e.g., images displayed on a display device). Images are generated at a rate of, for example, 30 times per second. Different techniques can be used in video games to provide different types of perspectives or gameplay. Examples include two-dimensional gameplay, where movement in the game space allows for left-right and / or up-down movement. Classic examples of two-dimensional gameplay are Pong and Super Mario Bros. for the Nintendo Entertainment System (NES).

[0004] Another technique for computer games allows the player to control objects in a three-dimensional game space. The player can manipulate the objects in the x, y, and z directions. A view of the three-dimensional game space is rendered by using virtual camera techniques and shown to the player on a display device. A classic example of a game with three-dimensional gameplay is GoldenEye 007 for the Nintendo 64.

[0005] Thus, different techniques for rendering images may be used in video games, however, it is recognized that there is a constant need in this art for new and improved techniques, systems, and processes. Summary of the Invention

[0006] overview In an exemplary embodiment, a computer system is provided that renders a three-dimensional scene for two-dimensional gameplay. The view of the three-dimensional scene is from a perspective view. During the rendering process for the scene, an object (e.g., its polygons) is offset when written to a depth buffer according to one of a number of layers to which the object is assigned. In an example, the techniques herein allow sorting of three-dimensional objects (e.g., three-dimensional meshes) in a perspective scene by offsetting the polygons of the meshes when they are drawn to the depth buffer. In an example, the meshes in the scene are organized into categories at run time. The category is used to identify in which layer the mesh should be displayed. The layer for the mesh is used to control the offset during depth buffer testing. Thus, the depth buffer testing may be performed regardless of the position of the object in the virtual space for the scene being generated.

[0007] This Summary is provided to introduce various concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Rather, this Summary is intended to provide an overview of the subject matter described in this document. As such, it will be appreciated that the features described above are merely examples, and that other features, aspects, and advantages of the subject matter described herein will become apparent from the following Detailed Description, Figures, and Claims.

[0008] These and other features and advantages will be more fully and completely understood by reference to the following detailed description of exemplary and non-limiting illustrative embodiments taken in conjunction with the drawings. [Brief description of the drawings]

[0009] [Figure 1] 1A-C are wireframe diagrams illustrating different techniques for rendering objects according to an example.

[0010] [Figure 2A] 1A-1C are wireframe diagrams illustrating different techniques that may be used to render objects as part of a three-dimensional video game scene, according to an example embodiment. [Figure 2B] 1A-1C are wireframe diagrams illustrating different techniques that may be used to render objects as part of a three-dimensional video game scene, according to an example embodiment. [Figure 2C] 1A-1C are wireframe diagrams illustrating different techniques that may be used to render objects as part of a three-dimensional video game scene, according to an example embodiment.

[0011] [Diagram 3] 4 is a flowchart of elements included as part of a rendering process in accordance with an example embodiment.

[0012] [Figure 4] 1 is a graphical illustration of how an example virtual object is positioned within world space coordinates of an example virtual game space, according to an example embodiment.

[0013] [Diagram 5] FIG. 1 illustrates an example computing device that may be used in some embodiments to implement features described herein.

[0014] In the following description, for purposes of explanation and non-limiting, specific details are set forth, such as particular nodes, functional elements, techniques, protocols, etc., to provide an understanding of the described technology. It will be apparent to one of ordinary skill in the art that other embodiments may be practiced apart from the specific details described below. In other instances, detailed descriptions of well-known methods, apparatus, techniques, etc. are omitted so as not to obscure the description with unnecessary detail.

[0015] This detailed description uses sections only to orient the reader as to the general subject matter of each section. As will be seen below, the description of many features spans multiple sections, and the headings should not be construed as affecting the meaning of the descriptions contained in any section.

[0016] In many places in this document, we describe software modules (e.g., game applications), software components, software engines (e.g., rendering engines), and / or actions performed by such elements. This is done for ease of description, and whenever this document describes a software module or the like as performing an action, it should be understood that the action is actually performed by the underlying hardware elements (e.g., processors, hardware circuits, and / or memory devices) according to instructions that include the software module or the like. Further details in this regard are provided below, particularly in the description of FIG. 5. Overview

[0017] In an exemplary embodiment, a technique is provided for rendering perspective views of three-dimensional objects used in two-dimensional gameplay. Three-dimensional objects (e.g., three-dimensional meshes, etc.) are placed on different layers for a perspective scene. During the rendering process, objects in the scene are drawn or otherwise tested against a depth buffer. The coordinates used in the depth buffer for each object are offset based on which layer was assigned to its corresponding object. This technique allows for decoupling the view order from the world space coordinates of the objects while still using the depth buffer and other graphics pipeline techniques to render images of the three-dimensional scene. In an example, the techniques herein allow for the creation of two-dimensional games (e.g., two-dimensional gameplay) along with three-dimensional scenes while still preserving or maintaining the original drawing order, but also adjusting the view order. This technique also helps to avoid 3D mesh clipping for overlapping objects in the scene.

[0018] In many places in this document, we describe software (e.g., modules, software engines, services, applications, etc.) and actions performed by the software (e.g., functions as shown in FIG. 3). This is done for ease of explanation, and whenever this document describes software as performing an action, it should be understood that the action is actually performed by underlying hardware elements (e.g., processors and memory devices) according to instructions comprising the software. Such functionality may be provided in the form of firmware and / or hardware implementations in some embodiments. Further details in this regard are provided below, particularly in the description of FIG. 5. Explanation of Figures 1A-2B; Examples

[0019] Figures 1A-2B are wireframe diagrams of different types of images that may be generated according to an example. Figures 1C and 2B correspond to images that may be generated using techniques discussed herein (e.g., in connection with Figure 3), while Figures 1A, 1B, and 2A correspond to other types of rendering techniques.

[0020] In connection with an exemplary embodiment, different kinds of rendering techniques may be implemented. In one example, a rendering technique for two-dimensional gameplay is provided. A possible problem with two-dimensional gameplay is that it may be desirable to have multiple objects or elements occupying the same area in the two-dimensional space (or view) for a video game. An illustrative example of this may be dealing with a video game character and a shape or terrain in a scene. Another example is when a character is climbing a ladder or in front of a background object (such as a table, tree, etc.). When these types of situations arise (objects occupy the same place in the game space), one or more undesirable results may occur due to two (or more) objects overlapping in the space.

[0021] An illustrative example of what can happen when two objects overlap in a game space is shown in FIG. 1A. In this example, object A and object B occupy the same location in the virtual game space. This results in object A and object B clipping each other. If the game space is a three-dimensional game space that uses a depth buffer for sorting (e.g., for visibility sorting), this can result in z-fighting or other undesirable rendering artifacts. This can happen even if it is desirable to have object A (e.g., a game character) and object B (e.g., a table) appear in front of B (e.g., have the game character walk in front of the table). This can happen even if the objects do not occupy exactly the same space due to floating-point precision of the depth buffer. Therefore, if the objects occupy the same space, one or more techniques may be required to display a desired view or appearance to the user as part of the gameplay.

[0022] One example of a rendering technique may work for two-dimensional gameplay using orthogonal projections and two-dimensional quads (e.g., flat and residing in one plane). Two-dimensional quadrants may be advantageous in some instances because they are relatively easy to create. In this technique, the two-dimensional quadrants may be manually sorted, for example, by assigning to each quadrant the order in which it is rendered. In some instances, this type of approach may give control (e.g., complete control) over the drawing order of the quadrants. However, because 2D quadrants are used and the projection is orthogonal, the scene is not three-dimensional (including having no perspective or parallax). Additionally, the sorting for this technique may be handled in software without relying on faster hardware-supported solutions (such as the depth buffer that a GPU provides).

[0023] Another rendering technique that may be used in connection with an example is orthogonal projection, a technique that uses a three-dimensional mesh (e.g., made from triangles or other polygons) and is rendered with the aid of depth buffer sorting (e.g., via a depth buffer provided by the GPU). In this technique, the rendered scene may appear three-dimensional (e.g., via a 3D mesh), but the drawing order / sorting of objects in the scene can be controlled (e.g., via a depth buffer) by moving objects closer to / farther from the virtual camera. However, this type of approach may have a flat appearance (e.g., because the scene does not include perspective). Furthermore, handling parallax may require manually handling objects in the foreground and background rather than using some graphics pipeline technique.

[0024] Another rendering technique that may be used in connection with an example is a technique that uses perspective projection and depth buffer sorting with a 3D mesh. In this technique, the scene includes a perspective view and parallax. However, by positioning objects closer to the viewpoint or farther from the viewpoint, they appear larger / smaller than other objects due to perspective projection. This is shown in connection with B in FIG. 1, where "A" is moved closer to the viewpoint (and in front of "B") and is therefore larger than B in the view. A depth buffer may be used to sort A (and its pixels) before "B". While this kind of technique may be used in connection with an example (e.g., moving objects closer / farther from the viewpoint), such a technique may not be desirable in connection with 2D gameplay (or gameplay that is not fully 3D). This is because, for example, referring to FIG. 1B, if 2D gameplay is desired, it may be advantageous for objects A and B to appear next to each other (e.g., they are at the same depth in the scene, on the same z-plane, or spaced the same distance from the viewpoint) versus being farther apart as clearly shown in FIG. 1B.

[0025] In contrast to the approach shown in FIG. 1B, in one example, a technique that uses a perspective view along with a 3D model sorted using a depth buffer can be used to generate images for 2D gameplay that avoids one or more of the problems used with the other techniques described herein.

[0026] 1C is a wireframe diagram showing object A being positioned in front of object B, but rendered next to or at the same depth (e.g., distance from the viewpoint) as object B. More specifically, all of object A (e.g., the object's polygons and pixels) are forced to be drawn in front of object B, even though both A and B are 3D objects and would "really" be clipped into object B (e.g., as shown in FIG. 1A).

[0027] Note that in FIG. 1A and FIG. 1C, object A and object B are located at exactly the same world space location in the game space. Moreover, both of these images represent renderings using, for example, a GPU depth buffer for sorting. However, the technique used in connection with FIG. 1C (and described in more detail below) results in object A being rendered such that the GPU depth buffer sorts it in front of object B. Note that this approach may appear different from other 3D approaches (e.g., those with full three-dimensional control). Indeed, the approach shown in FIG. 1C and detailed herein may provide one or more desired results (e.g., with respect to how the resulting images are rendered) for games that include two-dimensional gameplay.

[0028] 2A-2C further illustrate different techniques for rendering objects in relation to two-dimensional gameplay of three-dimensional objects located within a three-dimensional game space. The objects in these three scenes correspond to each other (200 / 250 / 270; 202 / 252 / 272; 204 / 254 / 274; and 206 / 256 / 276).

[0029] FIG. 2A is a wireframe of a game scene with two-dimensional gameplay corresponding to that shown in FIG. 1A. In this example, object 204 is a user-controlled object (e.g., a game character) moving along object 200 (e.g., a terrain object). There is also another object 202, which is, for example, a platform or other object. For example, the user can manipulate his object to jump on top of object 202. In this example, the user has moved his object 204 along object 200. However, when this occurs, object 204 clips 202. This is because both objects 202 and 204 are located at the same distance from the viewpoint (e.g., the virtual camera). This situation may then cause z-fighting or other rendering artifacts because the rendering process cannot determine which of objects 204 / 202 is in front and which is behind. Note that in some examples, some of the areas where the objects clip each other may show some of A and some of B. This may be due to the z-fighting problem noted above, where the rendering engine cannot consistently determine which objects (or their pixels) are in front of other objects.

[0030] FIG. 2A also includes object 206 moving laterally across the screen toward object 204. This may be, for example, a projectile or other object that is part of the video game being played. This object moves to a location that overlaps where object 200 is located and clips the terrain where it is located. The disadvantage of this is that as object 206 is moving, it may be desirable to continue to display it to the user so that, for example, the user can move out of the object's path (e.g., dodge it). However, 206 may begin to clip 200 and disappear from view. This is because the front of 200 may be closer to the camera than 206, e.g., 200 occupies a larger amount of space in the z-direction than 206.

[0031] To address one or more of the problems shown in FIG. 2A, the rendering of objects in a scene may be adjusted as shown in FIG. 2B. In FIG. 2B, the objects are all in the same location in the three-dimensional game space as shown in FIG. 2A. However, in FIG. 2B, the view order of the objects is adjusted by modifying the depth values ​​used to test which objects should be drawn using a depth buffer (e.g., on the GPU). As discussed in connection with FIG. 3, offsets are applied to the objects to position them such that 206 and 204 appear in front of 200 and 202 without modifying their positions in the three-dimensional game space (e.g., without moving the objects closer to the location of the virtual camera as is done in FIG. 1B).

[0032] One potential problem with this approach is that modifying the view order (e.g., by adjusting the depth values ​​used in the depth buffer test) can cause the object to appear in a way that can cause the resulting scene to appear inaccurate to the user. Figure 2C illustrates this problem.

[0033] In FIG. 2C, the virtual camera used to generate the image is adjusted to view the object from below. In other words, the virtual camera is moved "down" in the virtual game space and then oriented (e.g., its pitch) is adjusted to look up at the object. Note that the object in FIG. 2C is located at the same world space position as in FIG. 2B, and the same offsets are applied to the object as in FIG. 2B. However, in this case, 274 is not rendered in a way that seems inaccurate. Recall that 274 may correspond to a game character being controlled by a user as the game character walks along the terrain object 270. Thus, if the camera is moved to view the game space from below the terrain object, the image in FIG. 2C of the game scene may be confusing to the user, since 274 does not appear to be walking "on" 270. To address this issue, object 270 may be moved in front of 274. However, if this were to happen, the scene would still need to have 276 in front of 270 (so the user could see this object), while also leaving 274 in front of 272.

[0034] As discussed below, dynamically adjusting how objects are depicted in a scene may be based on the positioning / orientation of the virtual camera's gaze direction. It is also recognized that as more complexity is added to a game (e.g., in terms of more objects in a scene, more rules on how objects can be arranged, more flexibility on camera movement, etc.), the complexity of ordering objects may become more and more computationally expensive, especially if object reordering occurs quickly and / or frequently. Thus, in an exemplary embodiment, the virtual camera may have a fixed gaze direction or orientation. For example, the virtual camera may move only laterally without changing the camera's pitch / yaw direction. In some examples, the camera may be controlled to follow the object that the player manipulates (e.g., the gaze direction is toward object 274 when moving through the game space). In some examples, a given object may be dedicated to a particular one of multiple possible layers (e.g., the object is always in that layer). In an exemplary embodiment, many, most, or all of the objects in a scene may be associated / pre-sorted to a given layer prior to loading and running the game.

[0035] In some examples, additional variables may be used to adjust the order of views of objects in a scene. As an illustrative example, there may be some portion of gameplay where 276 is rendered behind 270. How 276 is presented (behind or in front of 270) may result, for example, from the design of the game level, or from the use of abilities by a user (or non-player character) in the game. Thus, the order of views of objects in a scene may be controlled dynamically, automatically (e.g., without direct manipulation by a user), or manually (e.g., in response to a user command to take an action). Description of Figure 3: Rendering

[0036] 3 is a flowchart of steps that may be included as part of a rendering process (also referred to herein as a rendering process) according to an example embodiment. The process shown in FIG. 3 may be executed multiple times (e.g., 30, 60, etc.) per second for a two-dimensional game being presented to a user. Each time the rendering process (which may include any or all of the elements shown in FIG. 3) is performed, the rendering process may generate a frame (e.g., an image) that is output and displayed. FIG. 2B is an illustrative example of an image that may be created using the rendering techniques described in connection with FIG. 3 in an example.

[0037] At 300, a virtual camera is positioned with the virtual game space. An illustrative example of how the virtual camera may be positioned is shown in FIG. 4. As discussed in more detail herein, the positioning of the virtual camera may affect how objects are depicted (e.g., which layer the object is associated with). In other words, the sorting of objects into various layers may be based on or dependent on the particular angle the virtual camera is using for the perspective viewpoint. For example, as shown in FIG. 2C, when the virtual camera angle is adjusted, the resulting effect of how 274 is depicted may be undesirable. Thus, the layering of 274 compared to 270 may be adjusted based on the needs of the application.

[0038] In an exemplary embodiment, the pitch and yaw of the virtual camera are fixed in the virtual space so that the viewing direction is along the same plane (or parallel to such a plane). In some examples, the virtual camera may be fixed or "moving" as the player-controlled object (e.g., game character, etc.) moves through the scene. Thus, the positioning of the virtual camera in the virtual space (e.g., x, y, z position) may be based or set based on the positioning of the player-controlled object in the game space. If the user provides input to control the player-controlled object to move to the right in the 2D view, the camera moves to the right as well. In some examples, the camera may be controlled to move only sideways, so that if the player-controlled object moves up and down, the camera does not move up and down. In other examples, the camera may follow the player-controlled object up and down as well.

[0039] At 302, objects in the 3D scene are positioned in a virtual space. For example, referring to FIG. 2B, objects 250, 252, 254, and 256 are all positioned in a virtual game space. The positions of the objects in space may be defined by three-dimensional (x, y, and z) world space coordinates. In some examples, each of the objects may be assigned a category indicator or attribute that defines the type of object. The assignment of these indicators may occur at design time (e.g., when a game designer is creating a level or game), at run time (e.g., when a player is playing the game), or both.

[0040] In some examples, an object may be assigned only one indicator. In other examples, an object may be assigned multiple indicators. In some examples, if multiple indicators are assigned, the indicators may be arranged with respect to priority. Illustrative examples of indicators may include terrain, player characters, non-player characters, non-interactive objects, interactive objects, projectile objects, and the like. In some examples, the indicators given to a given object may have additional logic. For example, an object may switch between a projectile object and a non-player character. As such, an object may have conditions on when one indicator is applied and when another indicator is applied, for example, based on processing taking place in the game scene. As another illustrative example, a game may include a number of objects that do not normally interact with each other. However, at a given point in the game (e.g., completion of a level or other trigger event), those objects may be played on a single specific layer such that they can all interact and appear correct within the three-dimensional game space.

[0041] At 304, the labels are used to assign each object to one of a number of different layers in the scene. As a non-limiting illustrative example, there may be 10 different layers for a scene, and each object in the scene may be placed in one of those possible layers. Below are illustrative examples of different layers that may be used in certain illustrative embodiments:

[0042] The first layer may be an Intro / Outtro layer, which may be used to present an object in front of all other objects in the scene (which may include a black / blank screen).

[0043] The second layer may be a projectile layer. This second layer may be for flying objects. This layer may be designed so that the player can always see the flying object. An example of a flying object may be object 276 in FIG. 2C.

[0044] The third layer may be a character layer. This layer may include all characters in the game or other objects that are dynamic or can be interacted with. In some examples, the third layer may be divided into additional layers (e.g., sub-layers) that separate the characters into different layers. This may be used, for example, to show / hide characters in the scene (e.g., behind a tree, etc.). So, for example, a character may walk in front of an NPC during a series of images (e.g., generated by the process of FIG. 3), and then later interact with (or walk behind) that same NPC in another series of images.

[0045] A fourth layer may be a static layer for other objects in the scene that are stationary and do not otherwise move in the game space. An example of this may be object 252 in Figure 2B, which may be a platform, etc. Another example may be some animated object in the scene that does not change position.

[0046] The fifth layer may be a ground or terrain layer. This layer is generally one that allows the player character to walk / run along. An example of this may be object 250 in Figure 2B. Other layers are possible, depending on the type of application, the complexity of the scene being rendered, etc.

[0047] The sixth layer may be a background layer, which may be used to ensure that objects are located in the background.

[0048] In an exemplary embodiment, the angle (e.g., view direction) and / or position of the virtual camera may be used to determine which layer an object should be assigned to. As an illustrative example, the location of object 254 may be in front of 250 in FIG. 2B, but the scene may shift if the camera is moved to view object 274 from below as shown in FIG. 2C. In this case, if 274 were drawn in the same layer as shown in FIG. 2B, it would be drawn in front of 270 (as shown in FIG. 2C). However, in this scene, it may be more appropriate to draw 274 behind 270, but still in front of 272. Thus, the layer on which one or more objects are set may be determined based on the camera angle (or other aspects of gameplay) used in the scene. This may enable new ways of technically dealing with the view order of objects in a scene as the scene changes.

[0049] In one example embodiment, objects that have extensive interaction within one another may be sorted into the same tier, whereas objects that may be in long-term clipping situations with little or no gameplay interaction are sorted into separate tiers.

[0050] In any case, each of the objects in a scene is assigned to a layer. In one example, this assignment is based on the classification of the object (e.g., when the object is designed / a level is created / etc.).

[0051] At 306, an offset is determined to be used in the rendering process. More specifically, the process determines how far each layer should be from each other. In one example, this value should be as small as possible, but still wide enough to offset the widest object in the scene that needs to be sorted. This is exemplarily shown in FIG. 4, where w is calculated based on the width (e.g., z-width) of the largest object in the scene, namely object 400.

[0052] In an exemplary embodiment, the layer depth difference is the same for all layers. In other examples, the layer depth of each layer is calculated individually. In other words, w can be calculated based on the width of the object associated with that particular layer. Thus, referring to FIG. 4 for this example, if 400, 402, and 404 are all in separate layers (406 is in the same layer as 404), an individualized w can be calculated for each of those layers, and then the total offset for a given layer can be calculated by summing the w associated with those layers "behind" the current layer. In any case, the width to be used for the offset for the layer is determined.

[0053] In an example embodiment, the offset calculation is determined to be as small as possible (e.g., to allow for a larger number of layers) while also preserving floating-point precision in relation to the depth buffer, which may also help reduce artifacts in the rendered scene.

[0054] At 308, depth and color buffers to be used to render the scene are initialized. In one example, these may be two-dimensional arrays. The depth buffer may hold the depth of pixels to be rendered for the resulting image, and the color buffer may hold the color to be rendered for pixels in the image. In some examples, these buffers may be provided as part of a GPU used to assist in rendering the scene.

[0055] The process then iterates through the layers in the scene by subjecting the objects in each layer to the rendering process at 310. In some examples, layers are selected randomly. In other examples, the layers (and the objects associated with each layer) are processed back-to-front (e.g., the ground is the first layer processed). In other examples, the layers are processed front-to-back (the intro layer is processed first).

[0056] At 312, for each layer, an offset depth is set for the objects rendered in that layer.

[0057] In some examples, this is accomplished by setting a hardware depth offset as follows: PO(s,w*x), where PO is a polygon offset function, s is some scale, w is the width determined from 306, and x is some fixed scalar applied to w. An illustrative example of using a polygon offset function may be the glPolygonOffset function for OpenGL, where w*x is the unit value in the function. Once this is set, each element of the object being rendered (e.g., each interpolated pixel / vertex / etc.) is offset as defined in the function. In some examples, x may be (or may be based on) a layer number. For example, the innermost back layer (e.g., ground layer) may be assigned 0, and incremented by 1 for each successively closer layer.

[0058] In one example embodiment, it is recognized that grouping objects together using layers allows for decoupling from the actual polygon offset values ​​used for each of those objects, which can be advantageous because the depth space for the depth buffer is different from other spaces (e.g., world space, etc.).

[0059] As another example implementation, the projected z position in the shader can be modified with an offset. In other words, the offset can be defined in the shader. For example, the shader depth offset (Z) can be defined as =s*(1.0-Z / W)+o, where Z and W are the Z and W projected coordinates output from the vertex shader, s is some constant scalar value, and o is an offset based on w determined from 306. In other words, o can be based on w*current layer number.

[0060] In some examples, both of the techniques discussed above (polygon offset commands and shader implementations) may be used. In some examples, certain types of elements in a scene may use the polygon offset commands noted above, while others use shaders. In one exemplary embodiment, particle effects or other in-game effects may be handled via shaders, while other in-game objects (e.g., game characters, etc.) are rendered by using polygon offset commands.

[0061] Using these techniques to offset the world space coordinates of an object (or its elements) causes the depth buffer values ​​to be scaled or offset in a way that preserves the view of the object being rendered.

[0062] Next, at 314, each object undergoes a process relative to the depth buffer, with the offset value prepared for the object. Specifically, each pixel (or other element of the object) is selected at 316 and tested against the depth buffer at 318. As noted above, the world space coordinates of the object's elements are modified for the offset depth. In other words, the depth value of each object is adjusted based on the offset defined for the given object. If no pixels remain to be tested for this object, the next object in the layer is selected.

[0063] At 320, if the calculated depth (taking into account the offset depth from 312) is closer to the viewpoint (e.g., the virtual camera position or a position based on that position) than the current value in the depth buffer, then the depth is written to the depth buffer at 322. If the calculated depth is not smaller, then the next pixel (or other element of the object) is selected to be tested.

[0064] It will be appreciated that in an example embodiment, any or all of elements 314-322 (as well as other elements described in FIG. 3) may be executed on a GPU, and thus processing for these steps may occur on the GPU's hardware. As an illustrative example, testing of the depth buffer for pixels / objects may occur in parallel using the processing power of the GPU. Thus, the techniques herein may be applied to different types of hardware architectures.

[0065] It should be noted that the values ​​written to the depth buffer need not be absolute values. Rather, in some examples, the depth buffer may store a value proportional to or related to its depth in world space. This value may be, for example, a value between 0 and 1. The values ​​written to or used in relation to the depth buffer may be based on a projection matrix that includes values ​​of the virtual camera being used (e.g., near / far / field of view values, etc.). The depth buffer values ​​may also be non-linear, with each unit step in the depth buffer resulting in more depth within the scene in world space (e.g., at an exponential rate).

[0066] In some examples, once a new value is written to the depth buffer, a color value for that pixel is also determined and written to the color buffer at 324. The color value may be, for example, the RGB value of the corresponding pixel. In other examples, the depth buffer may be filled first before generating the color buffer.

[0067] Returning to 314, once each object in the selected layer has been processed (e.g., 316-324), the process selects the next layer and repeats the processing from 312-324 for that layer. As noted above, there may be multiple different layers (e.g., three, four, five, six or more) in a given scene.

[0068] Once all layers have been processed (or the process determines that no other layers need to be processed), additional processing may occur to generate and output images as part of the video game at 330. It will be appreciated that other processing steps may occur before, during, or after the processing shown in FIG 3 in connection with generating images that are displayed to the user as part of the video game.

[0069] In an example embodiment, objects in a scene may be processed in any order of the steps discussed in Figure 3. For example, objects in a first layer may be processed, then objects in a second layer, then another object in the first layer. Thus, it is not necessary to process all objects in a given layer before moving on to another layer. In an example, objects / pixels may be processed in parallel (e.g., depending on the hardware implementation on the GPU, etc.). Description of Figure 4

[0070] Figure 4 graphically illustrates how example virtual objects are positioned in world space coordinates of an example virtual game space, according to an example embodiment. The virtual objects illustrated in Figure 4 may correspond to those shown in the example discussed in connection with Figures 2A-2C (e.g., 400 corresponds to 200, 402 corresponds to 202, 404 corresponds to 204, and 406 corresponds to 206). The view illustrated in Figure 4 is given as an overhead view of the objects located in the virtual space. The objects are positioned at the same z-depth from the virtual camera 300 and along the same plane of the y-axis.

[0071] As discussed in relation to Figure 3, objects placed within a scene may be tested to determine the widest width of an object in the scene, in this case 400 being the widest object, thus determining the w parameter set in Figure 3.

[0072] In one example, the process may determine the widest width of each object in each layer. Thus, for example, if 400 is in a first layer and 402, 404, and 406 are in a second layer, the width used for the first layer will be that of 400, and the width used for the second layer will be 402 (e.g., the widest object in the second layer). The offsets for each layer may then be used to generate offsets for the objects in that layer.

[0073] In one example, the assignment of objects to layers can be dynamic and based on gameplay elements in the video game and / or user-provided input. In other words, objects can be assigned to different layers at different times during gameplay. As an illustrative example, assume a ladder object is added that connects two terrain elements in a scene (e.g., connecting 250 and 252). As a character moves through the scene, the character may be rendered in the character layer (as discussed above), while the two terrain elements are rendered in the terrain layer and the ladder is rendered in the static objects layer. When the character reaches a position in front of where the ladder is located, the character is then drawn in front of the ladder (because the two are in different layers).

[0074] If the user wishes to interact with the ladder (e.g., climb the ladder), the user may provide an input (e.g., press a button on the controller). In this case, the character object may be dynamically adjusted to be drawn within the stationary ladder. This may cause the character to be rendered in a manner that indicates the character interacting with the ladder. Once the character has climbed the ladder and is no longer interacting with the ladder, the character may be returned to the character layer (or other layer) as appropriate.

[0075] In one example, objects in a scene may be located along different z-depths (which may be relatively small, for example, compared to the z-depth of the three-dimensional game space) along with the virtual game space. Referring to the ladder example above, if the ladder and the game character are at the same z coordinate, the character will clip through the ladder as he climbs it. Also, if the character is positioned at a different layer (e.g., the character layer) than the ladder, the ladder will be behind the character and the interaction may appear odd or incorrect. Thus, in one example, the z position in the world space position of an object relative to the virtual game space may be offset slightly depending on the interaction two or more objects may have in the scene. By rendering the game character just in front of the ladder (and using the same layer), it may resemble the player character climbing the ladder.

[0076] As noted above, objects in a scene may be dynamically assigned to one of a number of different layers. The assignment of an object to a given layer may be responsive to or based on receipt of input from a player. For example, if a user is playing a video game and the user provides an input (e.g., presses a button) with the intent of causing a controlled character to interact with an object in the scene, the character may be located in the same layer as that object (e.g., as discussed in the ladder example above). In other examples, an object with which an interaction is taking place may be located in the same layer as the player character. Once the interaction is over, the object may return to its original layer.

[0077] In an example embodiment, the assignment of objects to a given layer may be automatic (e.g., without requiring explicit input from a user) based on one or more factors in the game. For example, during a game, non-player characters may be automatically moved between layers to be exposed to and then hidden from the player. This type of processing may result in new and interesting effects being presented to game players as they play. Thus, a game scene may include triggers or other elements that control how objects in that scene are assigned to layers. In some examples, the assignment of objects to layers may be based on timer expiration, virtual camera movement (or a change in the virtual camera's viewing direction). A technical advantage of this type of implementation is that a hardware-based depth buffer (e.g., of a GPU) may be used to facilitate sorting / rendering of objects in a scene. This allows for faster processing than manual sorting that may be present, for example, in the 2D quadrant implementation discussed above.

[0078] As discussed herein, the gameplay provided, in one example, is two-dimensional gameplay that only allows a character to move horizontally or vertically within a game space displayed to a user. In other words, the gameplay is restricted along a two-dimensional plane. In one example embodiment, the two-dimensional plane may be defined at a fixed distance away from the virtual camera.

[0079] In an exemplary embodiment, such two-dimensional gameplay includes so-called 2.5-dimensional gameplay, where movement is still primarily constrained along a two-dimensional plane, but allows for a small amount of depth in the gameplay. An illustrative example of this could be having 254 from FIG. 2B disappear behind 252 in some circumstances. In that type of example, 254 "moves back" in the game space. However, in an exemplary embodiment, it is recognized that the degrees of freedom in the x- and y-planes are substantially greater than the degrees of freedom in the z-plane. Description of Figure 5

[0080] 5 is a block diagram of an exemplary computing device 500 (which may also be referred to, for example, as a "computing device," "computer system," or "computing system") according to some embodiments. In some examples, the computing device 500 may be referred to as a gaming device or gaming system. In some examples, the computing device 500 may include or store (e.g., in memory device 504) a gaming program (e.g., a video game application program) that includes or has access to game data and a rendering module. The video game application program may be executed by the computing device 500 and may include one or more computer processes or threads of execution.

[0081] The game data may be stored in the memory device 504 and may include data of virtual objects to be rendered, three-dimensional mesh data or mesh data, and asset information that may be loaded and used by the game program to play the video game. The rendering module may include code for implementing the functions shown in FIG. 3. As will be appreciated, additional elements for additional rendering operations may also be included in and handled by the rendering module. In some examples, the additional processing may include lighting, animation, culling, and the like. The game program may also include a game program logic module. This module may define the different rules of the video game and how the user, and the like, can control the objects.

[0082] In some embodiments, the computing device 500 includes one or more processors 502 (which may be referred to as “hardware processors” or individually as a “hardware processor”), one or more memory devices 504, one or more network interface devices 506, one or more display interfaces 508, and one or more user input adaptors 510. Additionally, in some embodiments, the computing device 500 is connected to or includes a display device 512. As described below, these elements (e.g., the processor 502, the memory devices 504, the network interface devices 506, the display interfaces 508, the user input adaptors 510, the display devices 512) are hardware devices (e.g., electronic circuits or combinations of circuits) configured to perform a variety of different functions for the computing device 500. In some embodiments, these components of the computing device 500 may collectively be referred to as computing resources (e.g., resources used to perform instruction execution and including processors (one or more processors 502), storage (one or more memory devices 504), and I / O (network interface device 506, one or more display interfaces 508, and one or more user input adapters 510)). In some instances, the term processing resources may be used interchangeably with the term computing resources. In some embodiments, multiple instances of the computing device 500 may be deployed in a distributed computing system.

[0083] In some embodiments, each or any of the processors 502 is or includes, for example, a single-core or multi-core processor, a microprocessor (e.g., which may be referred to as a central processing unit or CPU), a digital signal processor (DSP), a microprocessor associated with a DSP core, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, or a system on a chip (SOC) (e.g., an integrated circuit that includes a CPU as well as other hardware components such as memory, networking interfaces, etc.), and / or in some embodiments, each or any of the processors 502 uses an instruction set architecture such as x86 or Advanced RISC Machine (ARM).

[0084] In some embodiments, each or any of the processors 502 is or includes a graphical processing unit (GPU), which may be, for example, an electronic circuit designed to generate images or the like. As discussed herein, a GPU may include one or more specialized buffers, such as a depth buffer, that may be used to assist in rendering and displaying images. Use of the hardware resources of a GPU may be faster or more efficient than an equivalent software implementation running on a CPU.

[0085] One or more of the processors 502 may be referred to as a processing system in some examples. In some examples, the processing system may include a memory device 504 that stores computer-executable instructions executed by one or more of the processors 502.

[0086] In some embodiments, each or any of the memory devices 504 is or includes a random access memory (RAM) (such as dynamic RAM (DRAM) or static RAM (SRAM)), a flash memory (e.g., based on NAND or NOR technology), a hard disk, a magneto-optical medium, an optical medium, a cache memory, a register (e.g., that holds instructions), or other type of device that performs volatile or non-volatile storage of data and / or instructions (e.g., software executed on or by the processor 502). The memory devices 504 are examples of non-transitory computer-readable storage devices. Memory devices as discussed herein may include memory provided on the same "die" as the processor (e.g., internal to the die on which the processor is located) and memory provided external to the die that includes the processor. Examples of "on-die" memory may include cache and registers, while "off-die" or external memory may include DRAM. As discussed herein, on-die memory in the form of cache or registers may provide faster access at the expense of being more expensive to produce.

[0087] In some embodiments, each or any of the network interface devices 506 includes one or more circuits (such as a baseband processor and / or a wired or wireless transceiver) to implement layer 1, layer 2, and / or higher layers for one or more wired communication technologies (such as Ethernet (IEEE 802.3)) and / or wireless communication technologies (such as Bluetooth, WiFi (e.g., IEEE 802.11), GSM, CDMA2000, UMTS, LTE, LTE-Advanced (LTE-A), LTE Pro, Fifth Generation New Radio (5G NR), and / or other short-range, medium-range, and / or long-range wireless communication technologies). The transceiver may include circuitry for a transmitter and a receiver. The transmitter and receiver may share a common housing and may share some or all of the circuitry within the housing to transmit and receive. In some embodiments, the transmitter and receiver of a transceiver may not share any common circuitry and / or may be in the same or separate housings.

[0088] In some embodiments, data is communicated over an electronic data network, which includes implementations in which data is communicated from one computer process space to another, and thus may include, for example, inter-process communication, pipes, sockets, and communication occurring over direct cables, cross-connect cables, Fibre Channel, wired and wireless networks, etc. In one example, network interface device 506 may include ports or other connections that allow such connections to be made and that electronically communicate data between various components of a distributed computing system.

[0089] In some embodiments, each or any of the display interfaces 508 is or includes one or more circuits that receive data from the processors 502, generate corresponding image data based on the received data (e.g., via a discrete GPU, an integrated GPU, a CPU that performs graphical processing, etc.), and / or output the generated image data to a display device 512 that displays the image data (e.g., a high-definition multimedia interface (HDMI), a display port interface, a video graphics array (VGA) interface, a digital video interface (DVI), etc.). Alternatively or additionally, in some embodiments, each or any of the display interfaces 508 is or includes, for example, a video card, a video adapter, or a graphics processing unit (GPU). In other words, each or any of the display interfaces 508 may include a processor therein that is used to generate image data. The generation or such images may be performed in conjunction with processing performed by one or more of the processors 502.

[0090] In some embodiments, each or any of the user input adaptors 510 is or includes one or more circuits that receive and process user input data from one or more user input devices (514) included in, attached to, or otherwise in communication with the computing device 500, and output data to the processor 502 based on the received input data. Alternatively or additionally, in some embodiments, each or any of the user input adaptors 510 is or includes, for example, a PS / 2 interface, a USB interface, a touch screen controller, etc. and / or the user input adaptors 510 facilitate input from the user input devices 514.

[0091] In some embodiments, the display device 512 may be a liquid crystal display (LCD) display, a light emitting diode (LED) display, or other types of display devices. In embodiments in which the display device 512 is a component of the computing device 500 (e.g., the computing device and the display device are included in a single housing), the display device 512 may be a touch screen display or a non-touch screen display. In embodiments in which the display device 512 is connected to the computing device 500 (e.g., is external to the computing device 500 and communicates with the computing device 500 via wired and / or wireless communication techniques), the display device 512 may be, for example, an external monitor, projector, television, display screen, etc.

[0092] In some embodiments, each or any of the input devices 514 is or includes mechanical and / or electronic devices that generate a signal provided to the user input adaptor 510 in response to a physical phenomenon. Examples of input devices 514 include, for example, a keyboard, a mouse, a trackpad, a touch screen, a button, a joystick, a sensor (e.g., an acceleration sensor, a gyro sensor, a temperature sensor, etc.). In some examples, one or more of the input devices 514 generate a signal provided in response to a user providing an input, for example by pressing a button or activating a joystick. In other examples, one or more of the input devices generate a signal based on a sensed physical quantity (e.g., force, temperature, etc.). In some embodiments, each or any of the input devices 514 is a component of a computing device (e.g., a button provided on a housing that includes the processor 502, the memory device 504, the network interface device 506, the display interface 508, the user input adaptor 510, etc.).

[0093] In some embodiments, each or any of the external devices 516 includes additional computing devices (e.g., other instances of computing device 500) that communicate with computing device 500. Examples may include server computers, client computer systems, mobile computing devices, cloud-based computer systems, computing nodes, Internet of Things (IoT) devices, etc., all of which may communicate with computing device 500. In general, external devices 516 may include devices that communicate (e.g., electronically) with computing device 500. As an example, computing device 500 may be a gaming device that communicates over the Internet with a server computer system that is an example of external device 516. Conversely, computing device 500 may be a server computer system that communicates with a gaming device that is an example external device 516.

[0094] In various embodiments, the computing device 500 includes one, two, three, four, or more of each or any of the above-mentioned elements (e.g., the processor 502, the memory device 504, the network interface device 506, the display interface 508, and the user input adapter 510). Alternatively or additionally, in some embodiments, the computing device 500 includes one or more of a processing system including the processor 502, a memory or storage system including the memory device 504, and a network interface system including the network interface device 506. Alternatively or additionally, in some embodiments, the computing device 500 includes a system-on-chip (SoC) or multiple SoCs, where each or any of the above-mentioned elements (or various combinations or subsets thereof) are included in a single SoC or distributed across multiple SoCs in various combinations. For example, a single SoC (or multiple SoCs) may include the processor 502 and the network interface device 506. Alternatively, a single SoC (or multiple SoCs) may include the processor 502, the network interface unit 506, and the memory device 504, etc.

[0095] The computing device 500 may, in some embodiments, be arranged such that the processor 502 includes a multi- or single-core processor, the network interface device 506 includes a first network interface device (e.g., implementing WiFi, Bluetooth, NFC, etc.) and a second network interface device implementing one or more cellular communication technologies (e.g., 3G, 4G LTE, CDMA, etc.), and the memory device 504 includes RAM, flash memory, or a hard disk. As another example, the computing device 500 may be arranged such that the processor 502 includes two, three, four, five, or more multi-core processors, the network interface device 506 includes a first network interface device implementing Ethernet and a second network interface device implementing WiFi and / or Bluetooth, and the memory device 504 includes RAM and flash memory or a hard disk.

[0096] As previously noted, whenever a software module or process is described in this document as performing any action, that action is actually performed by the underlying hardware elements according to the instructions provided by the software module.

[0097] Consistent with the previous paragraph, as an example, in an embodiment in which an instance of the computing device 500 is used to implement a gaming device, the memory device 504 may load and / or store a gaming program that a user plays on the gaming device. The processor 502 (e.g., a combination of CPU and GPU processing) may be used to operate a rendering module of the gaming program, and the display device 512 (e.g., an LCD, etc.) may be used to output images based on the execution or execution of the gaming program. A video game controller may be an example of an input device 514 that may be used to allow a user to provide input. The input is then processed by the user input adapter 510 and / or the gaming program that the user is playing.

[0098] The above-described hardware configuration shown in FIG. 5 is provided as an example, and the subject matter described herein may be utilized with a variety of different hardware architectures and elements. For example, in many of the figures in this document, individual function / act blocks are shown. In various embodiments, the functionality of these blocks may be realized (a) using individual hardware circuits, (b) using application specific integrated circuits (ASICs) specifically configured to perform the described functions / acts, (c) using one or more digital signal processors (DSPs) specifically configured to perform the described functions / acts, (d) using the hardware configuration described above with reference to FIG. 5, (e) via other hardware arrangements, architectures, and configurations, and / or via a combination of the techniques described in (a)-(e). Technical advantages of the described subject matter

[0099] In an example embodiment, techniques are provided for generating three-dimensional scenes that can be used in conjunction with two-dimensional gameplay. The techniques discussed herein provide increased (e.g., complete) control over the visual order in which objects in a scene are rendered relative to the position of a virtual camera.

[0100] In one example, the visual order of objects in a scene can be dynamically, automatically changed, or driven by a user. This allows logic in the scene to control the visual order of how objects are presented. This also enables new and interesting techniques for dealing with (or avoiding) interactions between objects in a scene. If it is desired to visually depict an interaction, then objects in a scene can be moved to the same layer. Conversely, (and possibly for the same two objects that previously had an interaction), if such interaction is not desired, then objects can be moved to a different layer.

[0101] The techniques discussed herein can (and do) leverage the use of a GPU hardware depth buffer, which is a technical advantage over manually sorting objects in a scene, which may be as fast as using a GPU-provided depth buffer, but typically will not be the case.

[0102] In an exemplary embodiment, the techniques herein for generating three-dimensional scenes for two-dimensional gameplay may require fewer draw calls than other methods that may use techniques that overwrite a depth buffer. In other words, other techniques used in conjunction with two-dimensional gameplay may use multiple passes or multiple draw calls that overwrite data in a depth buffer to ensure that some objects are visually pushed forward (e.g., that the objects are always seen). Relative to such other techniques, in conjunction with an exemplary embodiment herein, rendering of a scene may be accomplished with fewer draw calls (e.g., a single draw call / 1). Such techniques may not require overwriting of a depth buffer as other techniques. In an example, this allows for the use of a single depth buffer (or testing once against a single buffer for each rendering process) versus using multiple depth buffers according to certain prior techniques. Thus, it is recognized that the techniques discussed herein provide technical advantages over prior techniques in that the generation of an image may require fewer draw calls, use of a single depth buffer, or a single pass against a depth buffer during the rendering process.

[0103] In some examples, the techniques herein allow for easier reuse of graphical assets in games. For example, meshes for 3D objects from other games that operate entirely in a three-dimensional game space (or in a two-dimensional space) may be repurposed into games that offer 2D gameplay. Control of the virtual game space and view ordering of objects relative to the virtual space may provide new ways of using such objects.

[0104] In an example embodiment, the perspective polygon offset technique may be applied to different kinds of rendering engines or pipelines. As an illustrative example, the technique may be used in a pipeline where the order in which objects are drawn is not front-to-back. Instead, the order may be random or based on other considerations. In another example, the order may be front-to-back, with objects in layers closer to the camera drawn first. Such an implementation may provide performance or efficiency benefits. The perspective polygon offset technique may also be adapted to existing rendering renders / rendering engines (e.g., which already have a defined drawing order for objects / the order in which objects are drawn). Selected terms

[0105] Elements described in this document include acts, features, components, items, attributes, and other terms. Whenever this document describes a given element as being present in "some embodiments," "various embodiments," "an embodiment," "an exemplary embodiment," "some exemplary embodiments," "an example," "case," "exemplary case," or any other similar language is used, it should be understood that the given element is present in at least one embodiment, but not necessarily in all embodiments. Consistent with the above, whenever it is described in this document that an action "may," "can," or "could" be performed, it should be understood that a feature, element, or component "may," "can," or "might" be included within or applicable to a given context, that a given item "may," "can," or "might" have a given attribute, or any similar phrase related to the terms "may," "can," or "might," is used, and that a given action, feature, element, component, attribute, etc. is present in at least one embodiment, but not necessarily in all embodiments.

[0106] Terms and phrases used in this document and variations thereof should be construed as open-ended rather than limiting unless specifically stated otherwise. In the above examples, "and / or" includes any and all combinations of one or more of the associated listed items (e.g., a and / or b means a, b, or a and b). The singular forms "a," "an," and "the" should be construed to mean "at least one," "one or more," etc. The term "examples" may be used interchangeably with the term embodiment and is used to provide examples of the subject matter under discussion, but is not an exhaustive or limiting list thereof. The terms "comprise" and "include" (as well as other conjugations and other variations) specify the presence of the associated listed elements, but do not preclude the presence or addition of one or more other elements. When an element is described as an "option," such description should not be understood to indicate that other elements are not required unless so described.

[0107] As used herein, the term "non-transitory computer-readable storage medium" includes registers, cache memory, ROM, semiconductor memory devices (such as D-RAM, S-RAM, or other RAM), magnetic media such as flash memory, hard disks, magneto-optical media, optical media such as CD-ROM, DVD, or Blu-ray disks, or other types of volatile or non-volatile storage devices for non-transitory electronic data storage. The term "non-transitory computer-readable storage medium" does not include transitory, propagating electromagnetic signals.

[0108] The claims are not intended to envisage a means-plus-function interpretation unless the claim explicitly uses the phrase "means for" or "steps for." Any claim element that is intended to be interpreted as a means-plus-function statement, if any, will expressly indicate that intention by reciting the phrase "means for" or "steps for." The above applies to claim elements in any type of claim (method claim, apparatus claim, or other type of claim) and, for the avoidance of doubt, also applies to claim elements incorporated within a method claim. Consistent with the preceding sentence, no claim element (in any claim of any type) should be interpreted as a means-plus-function interpretation unless the claim element is explicitly recited using the phrase "means for" or "steps for."

[0109] Whenever a hardware element (e.g., a processor, a network interface, a display interface, a user input adapter, a memory device, or other hardware element) or a combination of hardware elements is described herein as being "configured" to perform some action, it should be understood that such language specifies the physical state of the configuration of the hardware elements, and not merely the intended use or capability of the hardware elements. The physical state of the configuration of the hardware elements essentially links the action described after the phrase "configured to" to the physical characteristics of the hardware elements described before the phrase "configured to." In some embodiments, the physical state of the configuration of the hardware elements may be realized as an application specific integrated circuit (ASIC) that includes one or more electronic circuits that are configured to perform an action, or a field programmable gate array (FPGA) that includes programmable electronic logic circuits that are arranged in series or parallel to perform an action according to one or more instructions (e.g., via a configuration file for the FPGA). In some embodiments, the physical state of a configuration of hardware elements may be determined by storing (e.g., in a memory device) program code (e.g., instructions in the form of firmware, software, etc.) that, when executed by a hardware processor, causes the hardware elements to act in accordance with the program code (e.g., through the configuration of registers, memory, etc.).

[0110] Thus, a hardware element (or multiple hardware elements) can be understood to be configured to perform an action even when the identified hardware element is not currently performing the action or is not operational (e.g., not turned on, not powered, not being used, etc.). Consistent with the above, the phrase "configured to" in the claims should not be construed / considered to be a means-plus-function in any claim type (method claim, apparatus claim, or other type of claim). This includes claim elements (such as hardware elements) that are incorporated in a method claim. Additional Applications of the Described Subject Matter

[0111] Although process steps, algorithms, and the like, including but not limited to with reference to FIG. 3, may be described or claimed in a particular order, such processes may be configured to work in different orders. In other words, any sequence or order of steps that may be explicitly described or claimed in this document does not necessarily indicate a requirement that the steps be performed in that order. Rather, steps of processes described herein may be performed in any order possible. Furthermore, even if some steps are described or implied as occurring non-concurrently (e.g., because one step is described after another step), they may be performed simultaneously (or in parallel). Furthermore, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications, does not imply that the illustrated process or any of its steps are required, or that the illustrated process is preferred.

[0112] Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above description should be construed to imply that any particular element, step, range, or function is essential. All structural and functional equivalents to the elements of the above-described embodiments known to those skilled in the art are intended to be expressly incorporated herein by reference and encompassed. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the present invention, for it to be encompassed by the invention. Any embodiment, feature, element, component, or step in this document is not intended to be provided to the public.

Claims

1. 1. A computer system comprising: a memory device configured to store three-dimensional object data for a plurality of virtual objects positioned within the three-dimensional game space; a processing system comprising instructions that, when executed by at least one hardware processor of the processing system, cause the at least one hardware processor to perform an operation, the operation comprising: executing a video game application program; placing the plurality of virtual objects within the three-dimensional game space as part of the video game application program; as part of the video game application program, positioning a virtual camera within the three-dimensional game space to view the plurality of virtual objects from a perspective viewpoint; assigning each one of the plurality of virtual objects to one of a plurality of different layers; and offsetting a depth buffer value used for each of the plurality of objects when tested against a depth buffer as part of a rendering process to generate an image of the three-dimensional game space for the video game application program, the amount by which each object is offset being based on which of a plurality of layers the object is assigned to, said operations comprising: and outputting the generated image to a display device.

2. The computer system of claim 1 , wherein the operations further comprise repeating the rendering process at least 30 times per second.

3. The operation includes: processing input provided by a user using an input device coupled to said computer system; 2. The computer system of claim 1, further comprising controlling at least one of the plurality of virtual objects in the three-dimensional game space to move it to another location using the three-dimensional game space.

4. The computer system of claim 3 , wherein the at least one of the plurality of virtual objects is controllable by the user to move only in x and y directions within a virtual game space.

5. 4. The computer system of claim 3, wherein the video game application program does not process input that changes how far the at least one of the plurality of virtual objects is from the virtual camera in world space coordinates of the virtual game space.

6. The operations further comprise calculating an offset value based on a width of one of the virtual objects having a widest z-width; 2. The computer system of claim 1, wherein the depth value used for each corresponding object in the buffer is offset by the offset value in combination with the one of the layers to which the corresponding object is assigned.

7. 7. The computer system of claim 6, wherein the offset value is calculated as part of the rendering process that generates the image, and is calculated each time a new image is generated.

8. The computer system of claim 1 , wherein the offsetting is performed without changing world space positions of the objects.

9. the yaw and pitch values ​​of the virtual camera are fixed relative to the video game application program; The computer system of claim 1 , wherein the actions further comprise moving the virtual camera laterally to follow at least one of the plurality of virtual objects.

10. The rendering process is performed on a plurality of frames; 2. The computer system of claim 1, wherein the operations further comprise changing which of the plurality of layers a first object of the plurality of objects is assigned to from one of the plurality of frames to another of the plurality of frames.

11. 11. The computer system of claim 10, wherein the operations further comprise processing input provided by a user using an input device connected to the computer system, and changing which layer the first object is assigned to is based on processing the input provided by the user.

12. 11. The computer system of claim 10, wherein changing which tier the first object is assigned to is based on triggering a condition within the video game application program to automatically change the tier to which the first object is assigned.

13. The computer system of claim 1 , wherein the plurality of different tiers is at least five different tiers.

14. The computer system of claim 1 , wherein at least two of the plurality of virtual objects are positioned at locations within the three-dimensional game space that at least partially overlap or clip each other within the three-dimensional game space.

15. 15. The computer system of claim 14, wherein one of the at least two of the plurality of virtual objects is displayed in the image as a virtual object that is completely in front of the other of the at least two of the plurality of virtual objects without clipping the other of the at least two of the plurality of virtual objects.

16. the memory device is further configured to store a category attribute for each one of the plurality of virtual objects; The computer system of claim 1 , wherein each one of the plurality of virtual objects is assigned to one of the plurality of different tiers based on the categorical attribute of the corresponding object.

17. The computer system of claim 1 , wherein the depth buffer is located on a graphics processing unit (GPU).

18. 1. A computer program product stored on a non-transitory storage medium, the computer program product for execution by a computer system including at least one hardware processor, the computer program product comprising instructions configured to cause the at least one hardware processor to perform operations, the operations including: accessing three-dimensional object data for a plurality of virtual objects positioned along the three-dimensional game space; executing a video game application program; placing the plurality of virtual objects within the three-dimensional game space as part of the video game application program; as part of the video game application program, placing a virtual camera in the three-dimensional game space to view the plurality of virtual objects from a perspective viewpoint; assigning each one of the plurality of virtual objects to one of a plurality of different layers; and offsetting a depth buffer value used for each of the plurality of objects when tested against a depth buffer as part of a rendering process to generate an image of the three-dimensional game space for the video game application program, the amount by which each object is offset being based on which of a plurality of layers the object is assigned to, said operations comprising: outputting the generated image to a display device.

19. The rendering process is performed on a plurality of frames; 20. The computer program product of claim 18, wherein the operations further comprise changing which of the multiple layers a first object of the multiple objects is assigned to from one of the multiple frames to another of the multiple frames.

20. 1. A method for execution on a computer system, comprising: accessing three-dimensional object data for a plurality of virtual objects positioned along the three-dimensional game space; executing a video game application program; placing the plurality of virtual objects within the three-dimensional game space as part of the video game application program; as part of the video game application program, placing a virtual camera in the three-dimensional game space to view the plurality of virtual objects from a perspective viewpoint; assigning each one of the plurality of virtual objects to one of a plurality of different layers; and offsetting a depth buffer value used for each of the plurality of objects when tested against a depth buffer as part of a rendering process to generate an image of the three-dimensional game space for the video game application program, the amount by which each object is offset being based on which of a plurality of layers the object is assigned to, the method comprising: outputting the generated image to a display device.

Images