All the 3d functions that accept a `type' parameter are asking for a polygon rendering mode, which can be any of the following POLYTYPE_* values. If the CPU_MMX flag of the cpu_capabilities global variable is set, the GRGB and truecolor *LIT routines will be optimised using MMX instructions. If the CPU_3DNOW flag is set, the truecolor PTEX*LIT routines will take advantage of the 3DNow! CPU extensions.
Using MMX for *LIT routines has a side effect: normally (without MMX), these routines use the blender functions used also for other lighting functions, set with set_trans_blender() or set_blender_mode(). The MMX versions only use the RGB value passed to set_trans_blender() and do the linear interpolation themselves. Therefore a new set of blender functions passed to set_blender_mode() is ignored.
See also: Polygon rendering, polygon3d, drawing_mode.
Examples using this: ex3d, excamera.
See also: Polygon rendering, polygon3d, makecol.
Examples using this: ex3d, exscn3d, exzbuf.
See also: Polygon rendering, polygon3d, rgb_map.
Examples using this: ex3d.
See also: Polygon rendering, polygon3d.
Examples using this: ex3d.
See also: Polygon rendering, polygon3d, POLYTYPE_ATEX.
Examples using this: ex3d.
See also: Polygon rendering, polygon3d, POLYTYPE_ATEX, POLYTYPE_PTEX.
Examples using this: ex3d.
See also: Polygon rendering, polygon3d, POLYTYPE_ATEX, POLYTYPE_PTEX, color_map, Truecolor transparency.
Examples using this: ex3d.
See also: Polygon rendering, polygon3d, POLYTYPE_ATEX_LIT, POLYTYPE_PTEX_LIT.
Examples using this: ex3d.
See also: Polygon rendering, polygon3d.
Examples using this: ex3d.
See also: Polygon rendering, polygon3d.
Examples using this: ex3d.
typedef struct V3D
{
fixed x, y, z; - position
fixed u, v; - texture map coordinates
int c; - color
} V3D;
typedef struct V3D_f
{
float x, y, z; - position
float u, v; - texture map coordinates
int c; - color
} V3D_f;
The `x' and `y' values specify the position of the vertex in 2d screen coordinates.
The `z' value is only required when doing perspective correct texture mapping, and specifies the depth of the point in 3d world coordinates.
The `u' and `v' coordinates are only required when doing texture mapping, and specify a point on the texture plane to be mapped on to this vertex. The texture plane is an infinite plane with the texture bitmap tiled across it. Each vertex in the polygon has a corresponding vertex on the texture plane, and the image of the resulting polygon in the texture plane will be mapped on to the polygon on the screen.
We refer to pixels in the texture plane as texels. Each texel is a block, not just a point, and whole numbers for u and v refer to the top-left corner of a texel. This has a few implications. If you want to draw a rectangular polygon and map a texture sized 32x32 on to it, you would use the texture coordinates (0,0), (0,32), (32,32) and (32,0), assuming the vertices are specified in anticlockwise order. The texture will then be mapped perfectly on to the polygon. However, note that when we set u=32, the last column of texels seen on the screen is the one at u=31, and the same goes for v. This is because the coordinates refer to the top-left corner of the texels. In effect, texture coordinates at the right and bottom on the texture plane are exclusive.
There is another interesting point here. If you have two polygons side by side sharing two vertices (like the two parts of folded piece of cardboard), and you want to map a texture across them seamlessly, the values of u and v on the vertices at the join will be the same for both polygons. For example, if they are both rectangular, one polygon may use (0,0), (0,32), (32,32) and (32,0), and the other may use (32,0), (32,32), (64,32), (64,0). This would create a seamless join.
Of course you can specify fractional numbers for u and v to indicate a point part-way across a texel. In addition, since the texture plane is infinite, you can specify larger values than the size of the texture. This can be used to tile the texture several times across the polygon.
The `c' value specifies the vertex color, and is interpreted differently by various rendering modes. Read the beginning of chapter "Polygon rendering" for a list of rendering types you can use with this function.
See also: triangle3d, quad3d, polygon, clip3d, cpu_capabilities.
Examples using this: excamera.
Read the beginning of chapter "Polygon rendering" for a list of rendering types you can use with this function.
See also: polygon3d, quad3d, triangle, Polygon rendering.
Read the beginning of chapter "Polygon rendering" for a list of rendering types you can use with this function.
See also: polygon3d, triangle3d, Polygon rendering.
Examples using this: ex3d.
As additional vertices may appear in the process of clipping, so the size of `vout', `vtmp' and `out' should be at least vc * (1.5 ^ n), where `n' is the number of clipping planes (5 or 6), and `^' denotes "to the power of".
The frustum (viewing volume) is defined by -z<x<z, -z<y<z, 0<min_z<z<max_z. If max_z<=min_z, the z<max_z clipping is not done. As you can see, clipping is done in the camera space, with perspective in mind, so this routine should be called after you apply the camera matrix, but before the perspective projection. The routine will correctly interpolate u, v, and c in the vertex structure. However, no provision is made for high/truecolor GCOL.
Return value: Returns the number of vertices after clipping is done.
See also: polygon3d, clip3d.
Examples using this: excamera, exscn3d.
Return value: Returns the number of vertices after clipping is done.
See also: polygon3d, clip3d_f.
A Z-buffer stores the depth of each pixel that is drawn on a viewport. When a 3D object is rendered, the depth of each of its pixels is compared against the value stored into the Z-buffer: if the pixel is closer it is drawn, otherwise it is skipped.
No polygon sorting is needed. However, backface culling should be done because it prevents many invisible polygons being compared against the Z-buffer. Z-buffered rendering is the only algorithm supported by Allegro that directly solves penetrating shapes (see example exzbuf.c, for instance). The price to pay is more complex (and slower) routines.
Z-buffered polygons are designed as an extension of the normal POLYTYPE_* rendering styles. Just OR the POLYTYPE with the value POLYTYPE_ZBUF, and the normal polygon3d(), polygon3d_f(), quad3d(), etc. functions will render z-buffered polygons.
Example:
polygon3d(bmp, POLYTYPE_ATEX | POLYTYPE_ZBUF, tex, vc, vtx);
Of course, the z coordinates have to be valid regardless of rendering style.
A Z-buffered rendering procedure looks like a double-buffered rendering procedure. You should follow four steps: create a Z-buffer at the beginning of the program and make the library use it by calling set_zbuffer(). Then, for each frame, clear the Z-buffer and draw polygons with POLYTYPE_* | POLYTYPE_ZBUF and finally destroy the Z-buffer when leaving the program.
Notes on Z-buffered renderers:
Return value: Returns the pointer to the ZBUFFER or NULL if there was an error. Remember to destroy the ZBUFFER once you are done with it, to avoid having memory leaks.
See also: create_sub_zbuffer, set_zbuffer, clear_zbuffer, destroy_zbuffer.
Examples using this: exzbuf.
When drawing z-buffered to a bitmap, the top left corner of the bitmap is always mapped to the top left corner of the current z-buffer. So this function is primarily useful if you want to draw to a sub-bitmap and use the corresponding sub-area of the z-buffer. In other cases, eg. if you just want to draw to a sub-bitmap of screen (and not to other parts of screen), then you would usually want to create a normal z-buffer (not sub-z-buffer) the size of the visible screen. You don't need to first create a z-buffer the size of the virtual screen and then a sub-z-buffer of that.
Return value: Returns the pointer to the sub ZBUFFER or NULL if there was an error. Remember to destroy the ZBUFFER once you are done with it, to avoid having memory leaks.
See also: create_zbuffer, create_sub_bitmap, destroy_zbuffer.
See also: create_zbuffer, clear_zbuffer, destroy_zbuffer.
Examples using this: exzbuf.
See also: create_zbuffer, set_zbuffer, destroy_zbuffer.
Examples using this: exzbuf.
See also: create_zbuffer, set_zbuffer, clear_zbuffer.
Examples using this: exzbuf.
Allegro provides two simple approaches to remove hidden surfaces:
The scene rendering has approximately the following steps:
For each horizontal line in the viewport an x-sorted edge list is used to keep track of what polygons are "in" and which is the nearest. Vertical coherency is used - the edge list for a scanline is sorted starting from the previous one - it won't change much. The scene rendering routines use the same low-level asm routines as normal polygon3d().
Notes on scene rendering:
Z-buffered rendering works also within the scene renderer. It may be helpful when you have a few intersecting polygons, but most of the polygons may be safely rendered by the normal scanline sorting algorithm. Same as before: just OR the POLYTYPE with POLYTYPE_ZBUF. Also, you have to clear the z-buffer at the start of the frame. Example:
clear_scene(buffer);
if (some_polys_are_zbuf) clear_zbuffer(0.);
while (polygons) {
...
if (this_poly_is_zbuf) type |= POLYTYPE_ZBUF;
scene_polygon3d(type, tex, vc, vtx);
}
render_scene();
The memory allocated is a little less than 150 * (nedge + npoly) bytes.
Return value: Returns zero on success, or a negative number if allocations fail.
See also: scene_polygon3d, render_scene, clear_scene, destroy_scene, scene_gap, create_zbuffer.
Examples using this: exscn3d.
See also: create_scene, scene_polygon3d, render_scene, destroy_scene, scene_gap.
Examples using this: exscn3d.
See also: create_scene, scene_polygon3d, clear_scene, render_scene, scene_gap.
Examples using this: exscn3d.
Arguments are the same as for polygon3d(), except the bitmap is missing. The one passed to clear_scene() will be used.
Unlike polygon3d(), the polygon may be concave or self-intersecting. Shapes that penetrate one another may look OK, but they are not really handled by this code.
Note that the texture is stored as a pointer only, and you should keep the actual bitmap around until render_scene(), where it is used.
Since the FLAT style is implemented with the low-level hline() function, the FLAT style is subject to DRAW_MODEs. All these modes are valid. Along with the polygon, this mode will be stored for the rendering moment, and also all the other related variables (color_map pointer, pattern pointer, anchor, blender values).
The settings of the CPU_MMX and CPU_3DNOW flags of the cpu_capabilities global variable on entry in this routine affect the choice of low-level asm routine that will be used by render_scene() for this polygon.
Return value: Returns zero on success, or a negative number if it won't be rendered for lack of a rendering routine.
See also: create_scene, clear_scene, render_scene, destroy_scene, polygon3d, cpu_capabilities.
Examples using this: exscn3d.
Note that between clear_scene() and render_scene() you shouldn't change the clip rectangle of the destination bitmap. For speed reasons, you should set the clip rectangle to the minimum.
Note also that all the textures passed to scene_polygon3d() are stored as pointers only and actually used in render_scene().
See also: create_scene, clear_scene, destroy_scene, scene_gap, scene_polygon3d.
Examples using this: exscn3d.
The default value means that if the 1/z values (in projected space) differ by only 1/100 (one percent), they are considered to be equal and the x-slopes of the planes are used to find out which plane is getting closer when we move to the right.
Larger values means narrower margins, and increasing the chance of missing true adjacent edges/planes. Smaller values means larger margins, and increasing the chance of mistaking close polygons for adjacent ones. The value of 100 is close to the optimum. However, the optimum shifts slightly with resolution, and may be application-dependent. It is here for you to fine-tune.
See also: create_scene, clear_scene, destroy_scene, render_scene, scene_polygon3d.