|
|
RpMeshPS2AllAsyncTextureUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload the texture for the current mesh asynchronously. This macro will, where possible (see below), upload the texture for the current mesh asynchronously - that is, in parallel with VU1's processing of the prior mesh. This may save time by better exploiting the parallelism of the system. The texture will only be uploaded if there is enough space in the texture cache for it *after* taking into account the context 1 [and 2] textures used by the prior mesh. Unless the prior mesh is using very large textures, there is likely to be enough space. This macro is optional, but complements RpMeshPS2AllSyncTextureUpload, which uploads the texture *after* the rendering of the prior mesh has completed. If RpMeshPS2AllAsyncTextureUpload fails to upload the texture, then RpMeshPS2AllSyncTextureUpload will not. You must call RpMeshPS2AllSyncTextureUpload even if RpMeshPS2AllAsyncTextureUpload succeeds, since the former will set up texture renderstate. RpMeshPS2AllSyncTextureUpload should be called second. Both functions should be called before RpMeshPS2AllStartVIFUploads. Given that this macro reads the current mesh's texture out of the RxPS2AllPipeData struct, it is possible to call it many times, changing the texture field of that struct in between calls. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllAsyncTextureUploadMacro and in function form through RpMeshPS2AllAsyncTextureUploadFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
|
RpMeshPS2AllClipInfoUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload information to control clipping and culling. This macro uploads two quadwords describing the clipping or culling frustum. If the current mesh is to be per-triangle culled then the frustum will be larger than the view window, so that triangles fit inside the guard band clipping region. If the mesh is to be clipped, the frustum fits the view window exactly, to minimize the effects of inaccuracy in VU1 clipping calculations. These first two quadwords are followed by another quadword containing clipping/culling renderstate and flags. The macro takes into account transType when generating this quadword, in order to determine whether to cull/clip to the frustum, whether to apply fog or not and what the primitive type is (trilist/tristrip/linelist/linestrip). The first two quadwords are uploaded to the address in VU1 memory given by the global variable 'vuSDClipvec1' and 'vuSDClipvec2' (the addresses are in quadwords, not bytes) and the latter quadword is uploaded to 'vuSDVUSwitch'. This macro uploads a total of rpMESHPS2ALLCLIPINFONUMQW quadwords to the VIF (see RpMeshPS2AllClipInfoUpload). This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllClipInfoUploadMacro and in function form through RpMeshPS2AllClipInfoUploadFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllEndVIFUploads is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to terminate data uploads to VU1 and initiate transfer of mesh instance data. This macro completes the (VIF) DMA packet opened by RpMeshPS2AllStartVIFUploads. At the end of the packet, it initiates upload of the current mesh's instance data for transform and rasterization. It also adds a reference count to the instance data which will be decremented once the transfer is complete (this is used in clearing the resource arena safely). If you wish your mesh to be rendered, then RpMeshPS2AllStartVIFUploads and RpMeshPS2AllEndVIFUploads must both be called. Failing to call them will not result in a crash, but nothing will be rendered. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllEndVIFUploadsMacro and in function form through RpMeshPS2AllEndVIFUploadsFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllGatherMeshMetrics is a macro to gather metrics information on the RpMesh currently being rendered. This is a helper macro which is called from the default RxPipelineNodePS2AllMatPostMeshCallBack for RpAtomics and RpWorldSectors, RpMeshPS2AllPostMeshCallBack. It gathers metrics information on the RpMesh currently being rendered (though in non-RWMETRICS builds, the macro will boil away to nothing during compilation). It may be used in constructing user callbacks. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllGatherMeshMetricsMacro and in function form through RpMeshPS2AllGatherMeshMetricsFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllGIFTagUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload a GIF tag to be used to render the current mesh. This macro uploads a GIF tag specifying renderstate to be used when the triangles of the current mesh are dispatched to the GS for rasterization. This state is taken from current renderstate, including things such as textured/not, fogging/not, alpha-blending/not, perspective-correction/not, gouraud/flat, etc. This GIF tag may be ignored by custom VU1 code (in this case, a custom user GIF tag may be uploaded and this macro omitted). The destination address of the quadword in VU1 memory is given by the global variable 'vuSDgifTag' (the address is in quadwords not bytes). This macro uploads a total of rpMESHPS2ALLGIFTAGNUMQW quadwords to the VIF (see RpMeshPS2AllStartVIFUploads). This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllGIFTagUploadMacro and in function form through RpMeshPS2AllGIFTagUploadFunc, depending on how you wish to balance code size and function call overheads.
|
|
||||||||||||||||
|
RpMeshPS2AllInstanceCallBack is the RxPipelineNodePS2AllMatInstanceCallBack used in the default RenderWare RpMaterial pipeline. See RxPipelineNodePS2AllMatInstanceCallBack for an overview of this callback type. For RpAtomics and RpWorldSectors, this default callback uses the macro RPWORLDSECTORVERIFY to differentiate between RpAtomics and RpWorldSectors and calls the appropriate default instance function (RpWorldSectorPS2AllInstance or RpAtomicPS2AllInstance). These may be used in constructing your own replacement callback.
|
|
|
RpMeshPS2AllMatColUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload the material color for the current mesh. This macro uploads the color of the current mesh's material to VU1, as four floats in a quadword. This takes into account the fact that vertex colors need to be different (on PlayStation 2) for textured and untextured geometry. The destination address of this color in VU1 memory is given by the global variable 'vuSDcolScale' (the address is in quadwords not bytes). This macro uploads a total of rpMESHPS2ALLMATCOLNUMQW quadwords to the VIF (see RpMeshPS2AllStartVIFUploads). This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllMatColUploadMacro and in function form through RpMeshPS2AllMatColUploadFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllMeshInstanceTestCallBack is the RxPipelineNodePS2AllMatMeshInstanceTestCallBack used in the default RenderWare RpMaterial pipeline. See RxPipelineNodePS2AllMatMeshInstanceTestCallBack for an overview of this callback type. For RpAtomics and RpWorldSectors, this default callback is composed of the following helper macros (of which you may use either or both in constructing your own replacement callback), in the order shown here: RpMeshPS2AllTestNumVerts, RpMeshPS2AllTestMeshID
|
|
|
RpMeshPS2AllPostMeshCallBack is the RxPipelineNodePS2AllMatPostMeshCallBack used in the default RenderWare RpMaterial pipeline. See RxPipelineNodePS2AllMatPostMeshCallBack for an overview of this callback type. For RpAtomics and RpWorldSectors, this default callback (only actually used in RWMETRICS builds) is composed of the following helper macro (which you may use in constructing your own replacement callback):
|
|
||||||||||||||||||||
|
RpMeshPS2AllResEntryAllocCallBack is the RxPipelineNodePS2AllMatResEntryAllocCallBack used in the default RenderWare RpMaterial pipeline. See RxPipelineNodePS2AllMatResEntryAllocCallBack for an overview of this callback type. For RpAtomics and RpWorldSectors, this default callback is composed of the following helper macros (of which you may use any or all in constructing your own replacement callback):
|
|
||||||||||||
|
RpMeshPS2AllStartVIFUploads is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to initiate data uploads to VU1. This macro opens a (VIF) DMA packet to send data to VU1. It should be paired with RpMeshPS2AllEndVIFUploads. In between these two calls, any or all of the following macros may be called to upload small amounts of data to VU1:
RpMeshPS2AllStartVIFUploads opens a packet, the size of which is determined by initialQW and extraQW. The size includes an 'initial' DMA tag to transfer initialQW quadwords of data to the VIF (this DMA tag is omitted if initialQW is set to zero) plus extraQW quadwords of additional data which may include further DMA tags. There is also a final 'end' DMA tag to complete the packet. Each of the macros listed above has an associated constant defining how many 'initial' or 'extra' quadwords each uploads. You should sum these values for the macros which you use in order to calculate initialQW and extraQW. For those who understand PlayStation 2 DMA: You may add your own additional VIF uploads into the packet after RpMeshPS2AllStartVIFUploads and before the other macros, as long as you insert the appropriate VIF tag(s) before this data and as long as you take into account the size of this data (including the VIF tag(s)) when calculating initialQW. For those who understand PlayStation 2 DMA: you may insert other DMA tags into the chain (such as ref or call tags - they must still go to the VIF; you cannot change DMA channel within a packet) after RpMeshPS2AllStartVIFUploads and before the other macros, as long as you set initialQW to zero AND insert an appropriate DMA tag at the end of your data which will transfer initialQW quadwords of data to the VIF - such that the macros used thereafter will still function correctly (NOTE: we enable TTE in the packet, so you should zero the bottom 64 bits of your DMA tags so the VIF treats them like a NOP not a garbage VIF tag). You may do whichever DMA transfers you please outside of RpMeshPS2AllStartVIFUploads and RpMeshPS2AllEndVIFUploads, though it will be more efficient to do so between them, as there is a significant cost associated with opening DMA packets. The texture upload is done before RpMeshPS2AllStartVIFUploads because it uses a different DMA channel and because the texture must be in GS memory before the geometry transfer occurs. If you wish your mesh to be rendered, then RpMeshPS2AllStartVIFUploads and RpMeshPS2AllEndVIFUploads must both be called. Failing to call them will not result in a crash, but nothing will be rendered. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllStartVIFUploadsMacro and in function form through RpMeshPS2AllStartVIFUploadsFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllSurfPropsUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload the surface properties for the current mesh. This macro uploads the surface properties of the current mesh's material to VU1, as four floats in a quadword. The fourth float is taken from the spExtra member of the RxPS2AllPipeData struct. The destination address of the quadword in VU1 memory is given by the global variable 'vuSDsurfProps' (the address is in quadwords not bytes). This macro uploads a total of rpMESHPS2ALLSURFPROPSNUMQW quadwords to the VIF (see RpMeshPS2AllStartVIFUploads). This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllSurfPropsUploadMacro and in function form through RpMeshPS2AllSurfPropsUploadFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllSyncTextureUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload the texture for the current mesh. This macro will upload the texture for the current mesh once VU1's processing of the prior mesh has completed. It will also set up renderstate for this texture. If this texture is the same as for the prior mesh, nothing will be done and if it is already in GS memory then it needn't be uploaded. This macro is complemented by RpMeshPS2AllAsyncTextureUpload, which uploads the texture asynchronously. Even if RpMeshPS2AllAsyncTextureUpload is called and succeeds in uploading the texture, RpMeshPS2AllSyncTextureUpload should still be called since it will set up texture renderstate. RpMeshPS2AllSyncTextureUpload should be called second. Both functions should be called before RpMeshPS2AllStartVIFUploads. Given that this macro reads the current mesh's texture out of the RxPS2AllPipeData struct, it is possible to call it many times, changing the texture field of that struct in between calls. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllSyncTextureUploadMacro and in function form through RpMeshPS2AllSyncTextureUploadFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllTestMeshID is a macro to test for changes in an RpMesh's identifier. This is a helper macro which is called from the default RxPipelineNodePS2AllMatMeshInstanceTestCallBack for RpAtomics and RpWorldSectors, RpMeshPS2AllMeshInstanceTestCallBack. It generates an identifier for the mesh, compares it to the existing mesh identifier in the mesh's instance data (it uses RWPS2ALLRESENTRYHEADERFROMRESENTRY and RWPS2ALLRESENTRYHEADERGETMESHIDENTIFIER to extract this from the meshCache member of the RxPS2AllPipeData struct) and updates the meshInstance member if it finds any differences. The macro RPMESHPS2ALLMAKEMESHID can be used to construct the identifier for an RpMesh from its parent RpMeshHeader. RPMESHPS2ALLMESHIDGETFLAGS can be used to extract the RpMeshHeader flags from this indentifier. These macros may be used in constructing user callbacks. A full reinstance (see RxInstanceFlags) will be caused if the RpMeshHeader flags have changed. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllTestMeshIDMacro and in function form through RpMeshPS2AllTestMeshIDFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllTestNumVerts is a macro to test for a change in the number of vertices in a mesh since the mesh was last instanced. This is a helper macro which is called from the default RxPipelineNodePS2AllMatMeshInstanceTestCallBack for RpAtomics and RpWorldSectors, RpMeshPS2AllMeshInstanceTestCallBack. It calculates the number of vertices necessary in instance data for an RpMesh (on PlayStation 2, this is dependent on the primitive type of the mesh since we 'dereference' vertex indices at instance time so that our VU1 code can process geometry without using indixes) and causes a full reinstance (see RxInstanceFlags) if this value has changed since the mesh was last instanced. This macro may be used in constructing user callbacks. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllTestNumVertsMacro and in function form through RpMeshPS2AllTestNumVertsFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllTextureStateUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload texture-related render state information for the current mesh. This macro uploads several pieces of texture-related render state to the GS via the VIF. This includes pixel test modes, filtering modes, mipmap K and L and clamping modes. This macro uploads a total of rpMESHPS2ALLTEXTURESTATENUMQW quadwords to the VIF (see RpMeshPS2AllStartVIFUploads). This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllTextureStateUploadMacro and in function form through RpMeshPS2AllTextureStateUploadFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllVU1CodeIndexSetup is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to select the VU1 code fragment to be used to transform and render the current mesh. This macro sets up the vu1CodeIndex member of the RxPS2AllPipeData struct. This is an index used to select the appropriate VU1 code fragment from the VU1 code array attached to this node. vu1CodeIndex is set up by default to equal the transType member (with the culling flag masked off). This function overrides this, to use the new code indexing scheme used by RpAtomic/RpWorldSector/RwIm3D pipelines since support for back/front-face culling was added, as follows:
vu1CodeIndex = ((rxSKYTRANSTYPELINE & ps2AllPipeData->transType) >> 2) |
((rxSKYTRANSTYPEISO & ps2AllPipeData->transType) >> 2) |
((rxSKYTRANSTYPECULL & ps2AllPipeData->transType) >> 5);
TRI | PERSP | NCULL
TRI | PERSP | CULL
TRI | ISO | NCULL
TRI | ISO | CULL
LINE | PERSP | NCULL
LINE | PERSP | CULL
LINE | ISO | NCULL
LINE | ISO | CULL
Each code fragment is capable of rendering triangles with or without fog, with clipping or culling (CULL/NCULL above refer to back-face culling, not frustum culling/clipping) and the triangle fragments are capable of rendering both trilists and tristrips - predication on these options is achieved with flags uploaded by RpMeshPS2AllClipInfoUpload. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllVU1CodeIndexSetupMacro and in function form through RpMeshPS2AllVU1CodeIndexSetupFunc, depending on how you wish to balance code size and function call overheads.
|
|
|
RpMeshPS2AllVU1CodeUpload is a macro to be called, from RxPipelineNodePS2AllMatBridgeCallBack, to upload the VU1 code fragment to be used to render the current mesh. This macro uploads the VU1 code fragment indexed by the vu1CodeIndex member of the RxPS2AllPipeData struct. For those who know about PlayStation 2 DMA: this macro uses its own DMA tag (the other macros just use VIF tags and rely on a DMA tag being added to the packet before them, probably by RpMeshPS2AllStartVIFUploads), so its uploaded quadwords (and DMA tag) need to be taken account in the numExtraQW parameter of RpMeshPS2AllStartVIFUploads. This is why this macro must come last before RpMeshPS2AllEndVIFUploads. This macro will be a function in a debug build, but it may be used explicitly in macro form through the name RpMeshPS2AllVU1CodeUploadMacro and in function form through RpMeshPS2AllVU1CodeUploadFunc, depending on how you wish to balance code size and function call overheads.
|
© 1993-2003 Criterion Software Limited. All
rights reserved. Built Tue Apr 22 12:46:23 2003. Send Feedback
| Converted from CHM to HTML with chm2web Pro 2.85 (unicode) |