3D Graphics Engine Essentials

by Eric Lengyel

A crash course on topics that every 3D engine designer needs to master

Overview

This year marks the beginning of an era in which all 3D computer games are requiring hardware acceleration. Using a 3D accelerator removes the burden of writing a software-based triangle rasterizer, but designing a high-quality game engine still requires a lot of work. This article discusses how to perform and efficiently implement calculations that today's hardware does not handle such as coordinate transformations, triangle clipping, and visibility determination. I am going to assume that the reader is familiar with the fundamentals of vector and matrix mathematics that I use heavily in this article. The bibliography lists a couple of sources, including a recent MacTech article, which can provide a good introduction to this material.

The intention is to present all of the material in this article in a platform-independent manner. It is up to the reader to implement any code which is specific to a particular 3D acceleration API such as OpenGL or QuickDraw3D RAVE. The code accompanying this article is general in nature and does not depend on any specific API. The structures that we will use are shown in Listing 1 and include generic vector and matrix containers as well as structures which encapsulate vertices and triangles. All of the functions which are described in this article are implemented as methods of the MyEngine class shown in Listing 2. Details about these structures and functions are given in the sections that follow.

Coordinate Transformations

At the lowest level, the 3D hardware receives a list of vertices and a list of triangles to draw on the screen. Each vertex carries (x, y) screen coordinates, a z depth value, a color, an alpha value, and (u, v) texture map coordinates. Each triangle simply indicates which three members of the vertex list serve as its corners. (See the Vertex and Triangle structures shown in Listing 1.) The problem at hand is how to calculate where on the screen a given point in 3D space should appear for a given camera position and orientation.

Every 3D engine needs to deal with three different coordinate systems which I will introduce here and discuss in more detail shortly. The first is called world space or global space. This is the coordinate system in which everything is absolute, and it's the system in which we specify our camera position and the position of every object in the world. The second coordinate system is called object space or local space. Each object has its own space in which the origin corresponds to the position of the object in world space. The third coordinate system is called camera space. In camera space, the camera resides at the origin, the x and y coordinate axes are aligned to the coordinate system of the screen (x points to the right, and y points downward), and the z axis points in the direction that the camera is facing (and thus the z coordinate in camera space represents depth). It should be noted here that many 3D graphics systems have the y axis pointing upward in camera space, but this results in evil things such as left-handed coordinate systems unless the z axis is also reversed (as is the case with OpenGL). In any event, it makes life more complicated that it needs to be, so I will avoid these variants and stick to what I believe to be the more intuitive y-down system.

In order to obtain screen coordinates for a given 3D point, we must do two things. First we have to transform the point into camera space, and then we have to project it onto the viewing plane which represents our screen. Clipping will take place between these two operations so that we never project points that will not actually participate in the final rendering of a scene. The transformation and projection of points is handled quite nicely in theory by using four-dimensional homogeneous coordinates, although in practice we will not use these coordinates to their fullest extent for efficiency reasons.

Let's begin with a transformation in normal 3D coordinates. Suppose that we had a scene that contained a single cube. In the cube's object space, it is convenient to place the origin at one of the corners and orient the coordinate axes to be parallel with the cube's sides. We want to be able to move the cube anywhere in the scene and to rotate it arbitrarily. Thus, we have to maintain world space coordinates for the position of the cube's origin, and we need to maintain a rotation matrix which represents the orientation of the cube's local axes in world space. Let us call the cube's world space position P and its rotation matrix M. Then to transform a point A from the cube's object space to its global position Aworld in world space, we calculate

(1)

This is the object to world or local to global transformation. We can go the other way and transform from world space to object space by solving equation (1) for A, which gives us

(2)

Note that the columns of the matrix M are simply the vectors which correspond to the directions that the object's axes point in world space. This is useful since we are going to calculate the camera to world transform just like we would for any other object in the scene. The camera's local x, y, and z axes correspond respectively to the world space right direction R, down direction D, and view direction V of our camera's configuration. This means that we transform a point Acamera from camera space to world space with the equation

(3)

where Pcamera is the camera's world space position. However, we will normally want to transform points from world space to camera space, so the inverse of this transform is much more useful. If R, D, and V are normalized to unit length then the inverse of the rotation matrix is just its transpose, which we will call C, and the world to camera transformation is given by

(4)

When we are projecting vertices from a triangle mesh onto the screen, we never need to know the actual world space coordinates of each vertex. We can transform directly from object space to camera space by composing the object to world and world to camera transformations as follows.

(5)

Performing transformations in this manner is tedious since we need to use both of the matrices C and M, and we have to perform two matrix-vector multiplies. The problem is further compounded if a hierarchical scene is being utilized in which objects may have sub-objects which have their own local coordinate spaces, thus requiring additional steps to transform from sub-object space to camera space.

Fortunately, there is a more compact and elegant method for handling these transformations. It turns out that we can use the previously mentioned homogeneous coordinates, and in the process we can combine the 3x3 rotation matrix and translation vector needed in the transformations that we have been working with so far into a single 4x4 matrix. This simplifies the composition operation since all we have to do multiply the matrices corresponding to each transformation together.

First, the definition of homogeneous coordinates is necessary. A homogeneous point P is represented by four coordinates:

(6)

The corresponding three-dimensional point P3D is obtained by dividing each coordinate by w and discarding the fourth coordinate (which always becomes 1):

(7)

A 3D point with coordinates (x, y, z) can be represented in homogeneous coordinates by (x, y, z, 1). This gives us a four-dimensional vector which can be operated on by four-dimensional matrices. In fact, as will be demonstrated later, the projection of a point onto the view plane can be performed by using a 4x4 matrix that modifies the fourth coordinate of a vector.

Referring back to the 3x3 rotation matrix M and world space position P from the object to world transformation in equation (1), we see that we can produce the same transformation with a 4x4 matrix having the form.

(8)

Multiplying this matrix by a point A = (Ax, Ay, Az, 1) yields the same result as multiplying M by A3D and then adding P. An important fact is that the fourth coordinate of A remains 1 when multiplied by a matrix of the form shown in equation (8). Additionally, when two matrices of this form are multiplied together, the fourth row of the product is always (0, 0, 0, 1). This information will allow us to make some optimizations when we implement the calculations.

Using the notation from equation (4), the world to camera transform can be accomplished in homogeneous coordinates by using the matrix.

(9)

The product TcameraTworld gives us a single 4x4 matrix which transforms points from object space directly into camera space. This product only has to be calculated once for each object, and it replaces the relatively messy equation (5).

Most 3D acceleration API's require that the z-coordinate of a vertex in camera space be in the range 0.0 to 1.0. (The Glide API is an exception to this convention.) This means that we have to scale everything in the z direction so that 1.0 represents the furthest distance that anything in the scene will be from the camera. Calling this distance zmax, we can include the scale in the world to camera transformation by using the matrix.

(10)

This is the final world to camera transformation that needs to be calculated whenever the camera position or orientation changes (which may be for every frame).

Now that we are able to transform our vertices into camera space, we need to discuss the method used to project them onto the view plane. We first need to choose the distance from the camera to the view plane. Shorter view plane distances result in wider fields of view. As shown in Figure 1, the screen is represented by a rectangle on the view plane whose x-coordinate ranges from -1.0 to 1.0 and whose y-coordinate ranges from -h to h, where h is the height to width ratio (h = 0.75 for a 640x480 display). For a desired horizontal field of view angle q, the view plane distance d is given by.

(11)

A point which has already been transformed into camera space can be projected onto the view plane through multiplication by the matrix.

(12)

This matrix transforms a point Q = (x, y, z, 1) into the point Q¢ = (x, y, z, z/d). When we divide by the w component, w = z/d, we obtain the 3D point,

(13)

which lies in the view plane. Of course, in the real world we don't need to perform the matrix multiplication, but this does demonstrate that all we need to do in order to project a point onto the view plane is calculate 1/w = d/z.

Figure 1. Camera Space and View Plane Configuration.

Once we have multiplied the x and y components of a point by 1/w, we have resolution-independent view plane coordinates. To obtain actual screen coordinates, we need to scale the x value from the range [-1.0, 1.0] to the range [0, swidth] and the y value from the range [-h, h] to the range [0, sheight], where swidth and sheight are the dimensions of the display in pixels. This is accomplished through the equations

and

(14) and (15)

The implementation details for the transformation and projection of vertices are summarized by the steps below. The TransformVertices function shown in Listing 3 transforms an array of vertices from object space to camera space and temporarily stores them in a private array of the MyEngine class where they are used during the clipping phase.

Calculate the world to camera transformation matrix Tcamera given by equation (10). The fourth row of this matrix is always (0, 0, 0, 1), so it may be suppressed for efficiency. As done with the Matrix4D structure shown in Listing 1, we can consider it to be a 3x4 matrix that behaves like a 4x4 matrix.

For a given object in the scene, calculate the matrix product TcameraTworld, where Tworld is the object to world transformation. Again, the fourth rows of these matrices may be ignored since they will always be (0, 0, 0, 1).

For each vertex V belonging to the object, transform the point from object space to camera space by calculating Vcamera = TcameraTworldV. Once again, there is no need to use the fourth coordinate of the vector V.

Clip all of the triangles belonging to the object (see the section entitled "Clipping").

For each vertex V that was transformed in step 3, calculate 1/w = d/Vz. Screen coordinates are given by equations (14) and (15) where xview = Vx/w and yview = Vy/w.

Pass the values xscreen, yscreen, Vz, and 1/w to the 3D acceleration API. (In QuickDraw 3D RAVE, these values correspond to the x, y, z, and invW fields of the TQAVGouraud and TQAVTexture structures.)

Repeat steps 2-6 for each object in the scene which is potentially visible (see the section entitled "Visibility Determination").

Listing 1: Useful structures

Vector3D

This structure is used to hold a 3D point or a direction vector. Operators are overloaded for addition, subtraction, scalar multiplication, and the dot product.

Matrix4D

This structure is used to hold a 4x4 transformation matrix whose fourth row is always (0, 0, 0, 1). Multiplication operators are overloaded for the matrix-vector product and the matrix-matrix product. The Inverse function calculates the inverse of a matrix.

Triangle

Mesh

This structure contains an array of vertices and an array of triangles which compose a single mesh. The objectToWorldTransform matrix defines the mesh's position and orientation as given by equation (8). The bounding sphere information is used for visibility determination.

Listing 2: Engine class

MyEngine

The MyEngine class encapsulates information about the camera configuration and holds pointers to storage for transformed vertices and clipped triangles. The functions which perform coordinate transformations, triangle clipping, and visibility determination are implemented as methods of this class.

PrepareToRender

This function computes the world to camera transformation matrix and the world space normal vectors for the four side planes of the view frustum. It should be called once for each rendered frame before any RenderMesh calls are made.

Listing 3: Vertex transformation

TransformVertices

This function transforms an array of vertices from an object's local space into camera space. Each vertex's color, transparency, and mapping is simply copied to the array of transformed vertices here, but the routine could be modified so that a translation to the native vertex format of the 3D acceleration API being used is performed.

Clipping

Figure 2 illustrates the view frustum, the volume of space shaped like a truncated pyramid whose apex lies at the camera position, that coincides with the exact visible region for a given camera configuration. The view frustum is composed of four side planes which pass through the camera position, the front plane or near plane which is usually placed at z = d (d being the view plane distance from the previous section), and the back plane or far plane which is placed at z = 1.0.

Figure 2. The View Frustum.

After the three vertices used by a particular triangle have been transformed into camera space, there are three possibilities. The first is that all three vertices lie inside the view frustum. In this case, we say that the triangle is trivially accepted and pass it on unaltered to be rendered. The second possibility is that all three vertices lie outside the view frustum. When this happens, we say that the triangle is trivially rejected and do not consider it any further for rendering. The remaining possibility is that some of the vertices lie inside the view frustum and the rest lie outside. For this case, the triangle must be clipped into one or two smaller triangles which do lie completely inside the view frustum.

For each triangle, clipping occurs in camera space one plane at a time. If it is known that everything in the scene is within the distance zmax from the camera, then it is safe to ignore the back plane. For each plane, we consider the side facing the view frustum to be the positive side, and the side facing away to be the negative side. Thus a point is inside the view frustum if and only if it does not lie on the negative side of any of the six planes. A point lying exactly on one of the planes is still considered to be inside the view frustum.

For a given clipping plane, we need to classify the three vertices of a triangle as either lying on the positive side of the plane (which for our purposes includes vertices that lie exactly on the plane) or lying on the negative side of the plane. If it is ever the case that all three vertices lie on the negative side of any plane, then the triangle should be immediately discarded because it is not visible. If all three vertices lie on the positive side of the plane, then no clipping needs to occur for that plane and the triangle should be passed on to be checked against the other clipping planes. The remaining two possibilities are illustrated in Figure 3. If two vertices lie on the negative side of the plane, then the triangle needs to be clipped to coincide with the part of its area which lies on the positive side of the plane. If only one vertex lies on the negative side of the plane, then the polygon corresponding to the area lying on the positive side of the plane is a quadrilateral, and thus needs to be split into two triangles.

Figure 3. Clipped Triangles.

The method by which we classify vertices as lying on the positive or negative side of a clipping plane depends on which plane we are considering. For the front and back planes, we simply compare the z coordinate of a vertex to the distance separating the plane from the camera. Thus a vertex lies on the positive side of the front plane if z >= d, and a vertex lies on the positive side of the back plane if z <= 1.0. For the remaining four side planes, we can determine the location of a vertex relative to one of the planes by calculating the dot product between the vertex position and the plane's normal vector. A negative dot product indicates that the point lies on the negative side of the plane. The table below lists the inward-facing normal vectors for each plane of the view frustum where d is the view plane distance and h is the height to width ratio of the screen.

Plane

Normal

Front

(0, 0, 1)

Back

(0, 0, -1)

Left

(d, 0, 1)

Right

(-d, 0, 1)

Top

(0, d, h)

Bottom

(0, -d, h)

After determining that a triangle is split by a clipping plane (by observing that one or two vertices lie on the negative side of the plane), we must find the actual points of intersection along the triangle's edges. These points will serve as the vertices for the clipped triangle(s). The line segment connecting two vertices V1 and V2 can be described by the parametric equation

(16)

where t ranges from 0.0 to 1.0. A plane is described by the equation

(17)

where N is the plane's normal vector and D is the distance from the origin to the plane along the direction of N. To determine at what value of t a line segment intersects a plane, we substitute the function P(t) from equation (16) for P in equation (17). This gives us.

(18)

Solving this equation for t, we obtain.

(19)

The value of D is the view plane distance d for the front plane, 1.0 for the back plane, and 0.0 for the side planes since they pass through the camera space origin. Once the value of t has been calculated, we simply plug it into equation (16) to obtain the interpolated vertex position.

When implementing vertex interpolation for a clipping function, it is very important to consistently choose which vertex is to be V1 and which vertex is to be V2 for equation (19). Consider the case when there are two adjacent triangles which share an edge that intersects one of the clipping planes. If, when the first triangle is clipped, V1 is chosen to be the vertex lying on the positive side of the plane, and when the second triangle is clipped, V1 is chosen to be the vertex lying on the negative side of the plane, the resulting values of t may not be exactly the same due to different floating point round-off errors. This would cause the interpolated vertex for the first triangle to be slightly misaligned with the interpolated vertex for the second triangle, possibly causing visible artifacts along the clipped edge.

The ClipTriangle function shown in Listing 4 demonstrates a good triangle clipping implementation. When the function needs to interpolate vertices, it always chooses the vertex lying on the negative side of a clipping plane as V1 for the application of equation (19). The clipFlags parameter indicates to the clipping function which planes actually need to be considered. The next section describes a method for selecting its initial value. Any triangle that is created during the clipping process is recursively clipped using a value for clipFlags which excludes any planes against which its corresponding original triangle has already been clipped.

Listing 4: Triangle clipping

InterpolateVertices

This routine produces a new vertex whose position, color, transparency, and texture mapping coordinates are the result of interpolating between two given vertices using a given parameter t, where 0.0 <= t <= 1.0.

ClipTriangle

This routine clips a given triangle to the view frustum. It is assumed that all three vertices are closer to the camera than the back plane. The resulting clipped triangle(s) are added to the triangle array pointed to by MyEngine::triangleArray. The clipFlags parameter is a combination of the following bit flags, which indicate which planes need to be considered for the triangle.

Visibility Determination

Visibility determination is the mechanism by which an engine figures out early in the rendering process what parts of a scene are potentially visible for a given camera configuration. Determining the potentially visible set (sometimes abbreviated PVS) of objects usually involves algorithms which are very specific to a particular engine, and the process often appears to be more of an art than a science. The highest level of visibility determination is heavily dependent on the type of environment an engine has to deal with. The methods that an engine would use to determine what interior walls of a castle are visible are completely different from the methods that would be used to determine the visibility of large objects in outer space. Discussing the complex systems in use by today's state-of-the-art engines to determine the visibility of large structures in a large environment is beyond the scope of this article. This section describes the lower levels of visibility determination and provides a method for quickly determining whether all or part of an object might intersect the view frustum (thus making it potentially visible).

We have already visited the lowest level of visibility determination in the previous section. Triangle-level visibility is handled in part by the clipping algorithm, which is able to determine whether a triangle is completely visible, partially visible, or not visible at all. Before a triangle is clipped, however, we should check to see whether it is actually facing the camera. As long as solid models are being used, any triangle which is facing away from the camera will be completely obscured by some other part of the model. The process of removing these triangles from the rendering pipeline is called backface culling. We can quickly determine that a triangle is facing away from the camera by calculating the dot product between the triangle's normal vector and the direction to the camera. If the dot product is positive, then the triangle is facing the camera; otherwise, it should be culled. The direction to the camera for a particular triangle can be obtained by subtracting any one of the triangle's three vertices from the camera position. However, the vertex positions are represented in a model's local coordinate space and the camera position is represented in world space. Before performing any backface culling calculations for a particular model, we need to transform the global camera position into the model's object space. This is easily accomplished by multiplying the camera position by the inverse of the model's object to world transformation matrix as demonstrated in the RenderMesh function shown in Listing 6.

At the next higher level above individual triangles, we need to be able to determine the visibility of entire models such as characters and projectiles. Model-level visibility is the primary topic of this section and will be accomplished through the use of bounding volumes. Bounding volumes are shapes which have a simple geometry and completely encompass the models to which they correspond. The simplest geometry that can be used for a model's bounding volume is a sphere. The easiest way to obtain a decent bounding sphere for a triangle mesh is to calculate the average of the mesh's vertex coordinates to serve as the center and the maximum distance from any vertex to the center to serve as the radius. For most meshes it is possible to construct a bounding volume such as an ellipsoid or a box which contains less empty space around a model than a sphere does, but such a volume would require considerably more expensive visibility calculations. We therefore restrict our discussion to bounding spheres in the interests of simplicity and efficiency.

Before we spend valuable processor time transforming a mesh's vertices into camera space and clipping its triangles to the view frustum, we want to make sure that the mesh's bounding sphere actually falls at least partially within the camera's field of view. We apply this test by measuring the distance from the bounding sphere's center to each of the view frustum's planes in world space. If the sphere's center falls on the negative side of any plane by a distance greater than or equal to its radius, then no part of the model surrounded by the sphere is visible and thus should not be rendered. If the sphere's center falls on the positive side of a plane by a distance greater than or equal to its radius, then we know that no vertex in the mesh falls on the negative side of the plane. This information enables us to make an optimization later by excluding that plane when the mesh's triangles are clipped. The only bits in the clipFlags parameter which is passed to the ClipTriangle function that need to be set are those that correspond to planes for which the distance from the plane to the bounding sphere's center is less than the sphere's radius.

In order to perform the bounding sphere calculations in world space, we need to know the world space normal vectors for each of the view frustum planes. The normal vector for the front plane is simply the camera's viewing direction. The normal vectors for the four side planes are calculated in the PrepareToRender function shown in Listing 2. The actual bounding sphere visibility test is implemented in the SphereVisible function shown in Listing 5. This function returns a boolean value indicating whether the sphere is at least partially visible, and if so, also returns a set of flags indicating which planes have to be checked during the clipping process.

Listing 5: Bounding sphere visibility test

SphereVisible

This function returns a boolean value indicating whether a mesh's bounding sphere is visible. If true, then the clipFlags parameter is set to indicate which planes the sphere intersects and thus need to be considered for clipping.

Summary

This article has covered several fundamental topics with which every 3D engine designer needs to be familiar. We now have all of the mathematical tools which are necessary to render an arbitrary triangle mesh on the screen. These tools are combined in the RenderMesh function shown in Listing 6. This function takes a mesh and first determines whether is it visible by calling the SphereVisible function. If it is visible, then the mesh's vertices are transformed into camera space with the TransformVertices function. Finally, backface culling and clipping are performed one triangle at a time.

This is as far as we can go and still maintain platform-independence. The only remaining step is to transform the vertices into screen space (by applying equations (14) and (15)) and send them to the 3D acceleration API. We could gain some efficiency by changing the vertexArray and triangleArray members of the MyEngine class to be arrays of the native vertex and triangle structures of the API being used (for instance, TQAVTexture and TQAIndexedTriangle under QuickDraw 3D RAVE). If this is done, then the TransformVertices function would have to be modified to store the camera space vertices in the API's native format, and the InterpolateVertices function would have to be modified to work with this format as well.

There are, of course, many additional components to every 3D engine that this article has not explored such as lighting, animation, and collision detection, whose design depends more heavily on an engine's ultimate application than the material presented herein. The goal has been to provide a good starting point for those who wish to create their own 3D universe and to provide a strong foundation on which to build these higher-level systems.

Listing 6: Rendering a mesh

RenderMesh

This function does everything which is necessary to render a mesh. The PrepareToRender function should be called before any RenderMesh calls are made.

Eric Lengyel has recently joined Apple Computer where he is working on graphics technology for MacOS X. He can be reached at lengyel@apple.com.

Community Search:

MacTech Search:

Software Updates via MacUpdate

MacFamilyTree 7.3.4 - Create and explore...

MacFamilyTree gives genealogy a facelift: it's modern, interactive, incredibly fast, and easy to use. We're convinced that generations of chroniclers would have loved to trade in their genealogy... Read more

Yummy FTP 1.10.2 - FTP/SFTP/FTPS client...

Yummy FTP is an FTP + SFTP + FTPS file transfer client which focuses on speed, reliability and productivity.
Whether you need to transfer a few files or a few thousand, schedule automatic backups, or... Read more

VueScan 9.5.08 - Scanner software with a...

VueScan is a scanning program that works with most high-quality flatbed and film scanners to produce scans that have excellent color fidelity and color balance. VueScan is easy to use, and has... Read more

Iridient Developer 3.0.1 - Powerful imag...

Iridient Developer (was RAW Developer) is a powerful image conversion application designed specifically for OS X. Iridient Developer gives advanced photographers total control over every aspect of... Read more

Air Video Server HD 2.1.0 - Stream video...

Air Video Server HD streams videos instantly from your computer on your iPhone, iPad, iPod touch or Apple TV. No need to worry about converting or transferring files.
We took everything that was... Read more

Duplicate Annihilator 5.7.5 - Find and d...

Duplicate Annihilator takes on the time-consuming task of comparing the images in your iPhoto library using effective algorithms to make sure that no duplicate escapes.
Duplicate Annihilator... Read more

BusyContacts 1.0.2 - Fast, efficient con...

BusyContacts is a contact manager for OS X that makes creating, finding, and managing contacts faster and more efficient. It brings to contact management the same power, flexibility, and sharing... Read more

Capture One Pro 8.2.0.82 - RAW workflow...

Capture One Pro 8 is a professional RAW converter offering you ultimate image quality with accurate colors and incredible detail from more than 300 high-end cameras -- straight out of the box. It... Read more

Backblaze 4.0.0.872 - Online backup serv...

Backblaze is an online backup service designed from the ground-up for the Mac.With unlimited storage available for $5 per month, as well as a free 15-day trial, peace of mind is within reach with... Read more

Little Snitch 3.5.2 - Alerts you about o...

Little Snitch gives you control over your private outgoing data.
Track background activity As soon as your computer connects to the Internet, applications often have permission to send any... Read more

Pie In The Sky: A Pizza Odyssey 1.0
Device: iOS Universal
Category: Games
Price: $2.99, Version: 1.0 (iTunes)
Description:
A game about delivering pizza. In space.
| Read more »

Chosen Gives Hopeful Singers, Songwriter...

If YouTube videos and reality TV shows like The Voice have taught us one thing, it’s that there are a lot of people out there who are anxious to show the world their talents. And if they’ve taught us a second thing, it’s that there’s an almost... | Read more »

Android's Popular OfficeSuite Now A...

Once only available for Android devices, OfficeSuite has finally landed on the app store. The Mobile Systems app lets you view, edit, create, and share Word, Excel, and PowerPoint documents as well as convert them to/from PDFs. It's touted as being... | Read more »

Warhammer: Arcane Magic is Coming Soon,...

Turbo Tape Games has announced that they're joining forces with Games Workshop to bring the turn-based strategy board game, Warhammer: Arcane Magic, to life on the iOS.
| Read more »

Fast & Furious: Legacy's Creati...

| Read more »

N-Fusion and 505's Ember is Totally...

| Read more »

These are All the Apple Watch Apps and G...

The Apple Watch is less than a month from hitting store shelves, and once you get your hands on it you're probably going to want some apps and games to install. Fear not! We've compiled a list of all the Apple Watch apps and games we've been able to... | Read more »

Appy to Have Known You - Lee Hamlet Look...

Being at 148Apps these past 2 years has been an awesome experience that has taught me a great deal, and working with such a great team has been a privilege. Thank you to Rob Rich, and to both Rob LeFebvre and Jeff Scott before him, for helping me... | Read more »

Hands-On With Allstar Heroes - A Promisi...

Let’s get this out of the way quickly. Allstar Heroes looks a lot like a certain other recent action RPG release, but it turns out that while it’s not yet available here, Allstar Heroes has been around for much longer than that other title. Now that... | Read more »

Macho Man and Steve Austin Join the Rank...

WWE Immortals, by Warner Bros. Interactive Entertainment and WWE, has gotten a superstar update. You'll now have access to Macho Man Randy Savage and Steve Austin. Both characters have two different versions: Macho Man Randy Savage Renegade or Macho... | Read more »

Price Scanner via MacPrices.net

Adobe Brings Powerful Layout-Design Capabilit...

Adobe today announced the availability of Adobe Comp CC, a free iPad app that enables rapid creation of layout concepts for mobile, Web and print projects. With Comp CC, designers can rough out and... Read more

Apple offering refurbished 27-inch 5K iMacs f...

The Apple Store is offering Apple Certified Refurbished 27″ 3.5GHz 5K iMacs for $2119 including free shipping. Their price is $380 off the price of new models, and it’s the lowest price available for... Read more

16GB iPad mini on sale for $199, save $50

Walmart has 16GB iPad minis (1st generation) available for $199.99 on their online store, including free shipping. Their price is $50 off MSRP. Online orders only.
Read more

The Apple Store has Apple Certified Refurbished 13″ 2.6GHz/128GB Retina MacBook Pros available for $979 including free shipping. Original MSRP for this model was $1299.
Read more

Save up to $600 with Apple refurbished Mac Pr...

The Apple Store is offering Apple Certified Refurbished Mac Pros for up to $600 off the cost of new models. An Apple one-year warranty is included with each Mac Pro, and shipping is free. The... Read more

Samsung Galaxy S 6 and Galaxy S 6 edge U.S. P...

Samsung Electronics America, Inc. has announced the Galaxy S 6 and Galaxy S 6 edge will be available in the U.S. beginning April 10, with pre-orders being accepted now.
“We have completely reimagined... Read more

13-inch 2.5GHz MacBook Pro (refurbished) avai...

The Apple Store has Apple Certified Refurbished 13″ 2.5GHz MacBook Pros available for $829, or $270 off the cost of new models. Apple’s one-year warranty is standard, and shipping is free:
- 13″ 2.... Read more

MacTech is a registered trademark of Xplain Corporation. Xplain, "The journal of Apple technology", Apple Expo, Explain It, MacDev, MacDev-1, THINK Reference, NetProfessional, Apple Expo, MacTech Central, MacTech Domains, MacNews, MacForge, and the MacTutorMan are trademarks or service marks of Xplain Corporation. Sprocket is a registered trademark of eSprocket Corporation. Other trademarks and copyrights appearing in this printing or software remain the property of their respective holders. Not responsible for typographical errors.

All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.