## n64prev Previewer

- Purpose
- n64prev Previewer Package
- Memory Map
- Main Program Flow
- Hierarchal Structure and Link of Drawings
- Operating the n64prev Previewer
- The Object Display Driver
- Correcting the Program
- Revision History

## Purpose

The n64prev Previewer has been designed and implemented to display the NIFF converter and the output data of niff2gfx.

Because N64 is a game machine, the N64 Previewer has been developed specifically with game making in mind, so it can be applied to your game software with minimum effort.

## n64prev Previewer Package

The n64prev Previewer uses NuSystem and is designed based on the display driver, which draws the output file consisting of the display list from the N64 and reference structure from the NIFF data.
Source files are largely divided into the following blocks:

The activation part and main:

- main.c

The service routine (including the interface with NuSystem):

- pack.h
- pub.h
- malloc.c, malloc.h
- gfx.c, gfx.h
- expad.c, expad.h
- exgu.c, exgu.h

The display manager:

- nd.h
- ndman.c
- ndeval.c
- nddisp.c

The key operation (two types):

- tbmove.c, tbmove.h
- trckball.c, trckball.h
- cruise.c, cruise.h

The sample model data :

- premodel.c
- n64.c

## Memory Map

Figure 1: Previewer Memory Map

## Main Program Flow

The figure below illustrates the main program flow of n64prev Previewer.

Figure 2: Main Game Program Flow

## Hierarchical Structure and Links of Drawings

The figure below uses the example of an automobile to demonstrate the hierarchical structure of drawings in n64prev Previewer.

Figure 3: Hierarchical Structure of an Automobile Drawing

Assuming that the object of the hierarchical structure above is ndEntryObject(), the following two links can be made.

Figure 4: Drawing Links

## The Object Display Driver

The object display driver is the 3D object manager. It has two layers of links, link and a bi-direction link that activates the model data created in niff2gfx.
The object display driver is composed of the processing unit, called "instance." Though the creation and deletion are provided with different functions, the internal structure is the same; and it treats the object and animation in the same way.
Note: The service function that provides the link operation for instance has not been prepared at the present time.
It uses the layer structure link for executing the animation or calculating the display coordinate system. And it provides the drawing in order of the surface type following the twin-direction link of the display priority base, and implements the model display on contradiction.

### Specification

The Object Display Driver reserves and releases the most memory resources by way of a general memory manager.
In the case of a game that creates and deletes the object or animation frequently, resource management should be set up to use a pre-defined array of fixed-length data to get a performance improvement in memory management.
Because the ndEntryObject() function receives the NDR_OBJ structure, which is the object database, and creates the instance, the created status is unique.
The ndEntryAnimation() function uses the only NDR_ANIM structure in the animation database and isn't defined. It passes some instance numbers, which have already been created, and sets the format that executes the animation for the preceding instance.
In the ndEvalInstance() function, a flag checks to see if an update to the matrix is needed for each NDC_ITYPE_OBJECT object. If it doesn't need to, it is not supposed to create the Mtx buffer. In this way, you can shorten the processing time consumed by unused Mtx calculations.
In the current version, the end process isn't provided when the object instance that operates the animation is deleted. Because the link among the animation time keeper instance, the animation instance, and the object instance is weak, you need to manage these things on the application side.
The instance has the callback pointer. The callback occurs when the instance appears in an ndEvalInstance() or ndDeleteInstance() function. Please be careful that you do not call functions in which the link of instances is changeable (like ndDeleteINstance() or ndEntry*Instance()) within this callback routine. The priority change of instances or functions, which stretch the link again with the parent change, have not yet been prepared.

## Correcting the Program

### The Memory Manager

The n64prev Previewer memory manager needs a lot of resources. In the case of a game, you cannot always take time to reserve and release the resources. So, you need to design the program so it doesn't use the memory manager itself to determine cases.
There is room to reconsider area memory. If you plan well, you can create a memory manager that has a high enough speed, can be disposable, and corresponds to the variable length memory.

### The Relational Routine for Gfx

Gfx* is a return value for the gfxBegin() function. The memory that this pointer indicates is only a unilateral writing for the memory from the CPU. Because it accesses in units of 8 bytes, the whole processing time may become fast if you use it by converting to the pointer of the non-cache area.

Copyright 1997-1999 NINTENDO Co., Ltd.
1998-1999 MONEGI CORPORATION
All rights reserved.