 N64® Functions Menu |
al - Audio Library Functions gDP - DP GBI Macros gdSP - General GBI Macros gSP - SP GBI Macros gt - Turbo Microcode RDP gu - Graphics Utilities Math - Math Functions nuSys - NuSystem os - N64 Operating System sp - Sprite Library Functions uh - Host to Target IO 64DD - N64 Disk DriveNintendo® Confidential |
|
|
|
|
|
gSPZSendMessage
FormatgSPZSendMessage(Gfx *gp)Arguments
- gp is the pointer to the graphics display list
This Z-Sort microcode GBI macro sends an SP_BREAK message to the CPU to inform the CPU of the status of Display List execution.
When the DL execution status is unknown, the CPU cannot determine whether or not processing has been completed, forcing it to wait until RSP processing has ended (until the RSP message is received).
Display List | ZObject A vertex calculation | ZObject B vertex calculation | ZObject C vertex calculation � At this point, end message is sent to CPUIf the Display List is prepared as shown below using this GBI macro, the CPU can know whether or not the vertex calculation for each ZObject has ended and can immediately build ZObjects.
Display List | ZObject A vertex calculation | gSPZSendMessage -> message sent to CPU | ZObject B vertex calculation | gSPZSendMessage -> message sent to CPU | ZObject C vertex calculation � gSPZSendMessage -> message sent to CPUGiven the overhead resulting from actually sending and receiving messages for each Zobject, it may be better to send messages for multiple ZObjects rather than for each object. This is up to you.
Just as with the delivery of normal messages, for the CPU to receive the SP_BREAK message sent from the RSP, a message queue is used. Get the message queue for the SP_BREAK message and connect it to OS_EVENT_SP_BREAK by using osSetEventMesg.
Also, although it is safer to set the size of the queue to greater than the number of gSPZSendMessage in the Display List, this is not necessary. As long as the number of SP_BREAK messages can be controlled, a smaller size presents no problem.
In conventional microcode, rmonThread used this SP_BREAK message. Originally, the message was prepared for microcode BREAK POINT processing when using the GameShop DEBUGGER. This function currently is not used significantly, so it was left up to the user. As a result, when rmonThread is not used, no problem occurs. When it is used, note that the SP_BREAK message queue must be set after creating or starting rmonThread (execute osStartThread to rmonThread).
For detailed information on Z-Sort microcode's GBI macros and data structures, please see the "Z-Sort Microcode" area of the N64 Programming Manual.
See Also
Z-Sort Microcode
gSPZRdpCmd
gSPZSetUMem
gSPZGetUMem
gSPZSetMtx
gSPZGetMtx
gSPZMtxCat
gSPZMtxTrnsp3x3
gSPZViewPort
gSPZMultMPMtx
gSPZSetAmbient
gSPZSetDefuse
gSPZSetLookAt
gSPZXfmLights
gSPZLight
gSPZLightMaterial
gSPZMixS16
gSPZMixS8
gSPZMixU8
gSPZSegment
gSPZSetSubDL
gSPZLinkSubDL
gSPZSendMessage
gSPZWaitSignal
gSPZSegment
gSPZPerspNormalize
|
|
|
|
|
|
|
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
Nintendo® Confidential Warning: all information in this document is confidential and covered by a non-disclosure agreement. You are responsible for keeping this information confidential and protected. Nintendo will vigorously enforce this responsibility. Copyright © 1998 Nintendo of America Inc. All rights reserved Nintendo and N64 are registered trademarks of Nintendo Last updated January 1998 |