Game Development Reference
In-Depth Information
by reading the first four characters after the chunk header. If this is 'FACE'
then we are dealing with a conventional polygon; in this limited application
we return 0 to indicate an error if this is a subdivision patch list.
We then read the polygons one at a time. We cannot determine the
number of polygons from the length of the chunk because a polygon can
contain n number of vertices. A different number of vertices will use a
different amount of storage in the file. So we must allocate memory
dynamically. In the sample application memory is allocated as each
polygon is created. Then the contents of the existing polygon array are
copied and the old array deleted. Finally, the member variable 'plys' is set
to point to the new memory area. Another common way to allocate
memory dynamically is to double the storage each time, so that initially
you allocate enough for a single polygon, then 2, 4, 8, 16, 32, etc. This
saves time but is less efficient in terms of storage. Since a loader is called
infrequently, it seems that efficient memory storage wins out over
speed.
The definition of a polygon that we use in the application is as
follows:
typedef struct stPOLYGON{
int numverts; //Number of vertices
int p[4]; //Index into the point array of the vertices
int srfID; //Index into the surface array of the surface
float nx, ny, nz; //Normal for this polygon
}POLYGON;
For every polygon we store the normal in the three float values, nx , ny
and nz . The function to load all the polygons in a 'POLS' chunk is shown
below:
int CLWObject::LoadPolygons(FILE *fp, int length)
{
int r,count;
char buf[4];
numpolygons=0;
if (fread(buf, 1, 4, fp)!=1) return 0;
if (strncmp(buf, ”FACE”, 4)!=0) return 0;
count = 4; //bytes read so far
while(count<length){
r = AddPolygon(fp);
Search Nedrilad ::




Custom Search