| QA1 | Can operations be done directly from the CPU to the frame buffer? |
| QA2 | Can I use gsSPCullDisplayList() at the top-most level? |
| QA3 | Can I apply translucent processing to a character on which gDPSetFillColor was used? |
| QA4 | Can I correct the fact that screen display positions have shifted from where they were until now? |
| QA5 | How do I go about creating a polygon in the Copy Mode? |
| QA6 | Do data have to be in the ~.PPM file format in order to do morphing? |
| QA7 | The screen coordinate settings don't seem to have any effect on a vertex buffer which is the subject of clipping... |
| QA8 | How can I use the CPU to directly transfer data in RAM to the frame buffer without using texture RAM? |
| QA9 | I'd like to store Z-axis data in its own buffer and perform quasi-Z-axis movement criteria... |
| QA10 | What is the exact relationship between the screen effects of osViSetSpecialFeatures(OS_VI_DITHER_FILTER_ON) and gsDPSetColorDither()? |
| QA11 | How is the FZERO-X setup screen rendered? |
| QA12 | How do I use the macro key function? |
| QA13 | Can I read the 9th bit of the RDRAM? |
| QA14 | The triple frame buffer... |
| QA15 | How do I convert RGBA:5551 data to RGBA:8888? |
Q1 Can operations be done directly from the CPU to the frame buffer?
A1 It is possible, but it is not possible (by normal methods) to manipulate bits which are hidden with respect to anti-aliasing.
Q2 Can I use gsSPCullDisplayList() at the top-most level?
A2 gsSPCullDisplayList() is a macro for skipping the display list within the bounding box. The entire display list from gsSPCullDisplayList() until gsSPEndDisplayList() is skipped. Accordingly, if this macro is used at the highest level, everything including the gsDPFullSync() command will be skipped, so you need to be careful. (This might be useful at times, like when multiple tasks are used and gsSPFullSync() is not included.)
Q3 Can I apply translucent processing to a character on which gDPSetFillColor() was used?
A3 Translucent processing cannot be performed when the Fill mode is being used.
Q4 Can I correct the fact that screen display positions have shifted from where they were until now?
A4 With the N64 Emulation Software Ver2.0c1, the display positions of graphics are shifted about 4 dots "up" and 4 dots to the "left" from where they were in previous versions. The coordinates that were supposed to be in the center of the screen in previous versions were shifted about 4 dots in each of the "down" and "right" directions from center, therefore this was done to correct this problem. Unfortunately, there is no plan to return this to the previous state. See the following technique if you are interested in modifying the program that you are currently working on (excerpted from the "Blockmonkey" sample program).
int ModifyHStart(void)
{
int RegisterValue;
RegisterValue = OriginalVideoMode.comRegs.hStart;
(*CurrentVideoModePtr).comRegs.hStart=
(((((RegisterValue >>16) & 0xffff) + HorizontalOffset) % 0xffff) <<16)|
(((((RegisterValue >>0) & 0xffff) + HorizontalOffset) % 0xffff) <<0);
}
int ModifyVStart(void)
{
int RegisterValue
/* Do Field 0 change */
RegisterValue = OriginalVideoMode.fldRegs[0].vStart;
(*CurrentVideoModePtr).fldRegs[0].vStart=
(((((RegisterValue >>16) & 0xffff) + HorizontalOffset) % 0xffff) <<16)|
(((((RegisterValue >>0) & 0xffff) + HorizontalOffset) % 0xffff) <<0);
/* Do Field 1 change */
RegisterValue = OriginalVideoMode.fldRegs[1].vStart;
(((((RegisterValue >>16) & 0xffff) + HorizontalOffset) % 0xffff) <<16)|
(((((RegisterValue >>0) & 0xffff) + HorizontalOffset) % 0xffff) <<0);
}
static void ModifyScreenPosition(void)
{
if(HorizontalOffest) ModifyHStart();
if(VerticalOffest) ModifyVStart();
}
Q5 How do I go about creating a polygon in the Copy Mode?
A5 Polygons cannot be created in Copy Mode. Use 1Cycle Mode or 2Cycle Mode when creating polygons.
Q6 Do data have to be in the ~.PPM file format in order to do morphing?
A6 The morphdemo program is set up so as to read ~.ppm files, but ~.rgb files can be used in morphing without any problems if the segment(s) in which screen data are read is changed so that an ~.rgb file is read.
Q7 This question concerns gSPModifyVertex().
When I substitute the screen coordinate values x=100,y=100 into the 0th SP vertex buffer, I use
gSPModifyVertex( glp++, 0, G_MWO_POINT_XYSCREEN, ((100 << 2) << 16 )|((100 << 2) & 65535) );
or the like, but there are times, depending on the immediately previous polygon rendering mode, when the screen coordinates which were set by the preceding gSPModifyVertex have no effect. I tried this using a variety of modes, but it seems that the screen coordinate settings are disabled for the vertex buffer that was the subject of clipping during rendering of the immediately previous polygon.
Environment
u-code: F3DEX.NoN.fifo
OSver.: 2.0g
A7 I was able to confirm this symptom. Likewise, it seems that the vertices that were subject to clipping are not being rendered. (The symptoms should change with gSPClipRatio). I think that the only thing you can do is to perform rendering without clipping (because the vertices that were clipped were not rendered), but I'll let you know if a better way of preventing this is found.
Q8 I want to use the CPU to directly transfer data in RAM to the frame buffer without using texture RAM. How should I go about accessing?
A8 The NINTENDO64 frame buffer utilizes a part of RDRAM. Thus, you can directly read and write from the CPU. (Of course, this assumes no read/writes from the RDP and no VI readouts.) In the case of a 16bit frame buffer, use the RGBA5551 format to directly access the address you want to write (at this time, if the low-order bit is not set to "1" the data may not be displayed very well).
Q9 I'd like to store Z-axis data in its own buffer, transfer those data to the Z buffer before rendering the main model, etc., and perform quasi-Z-axis movement criteria, but since the data in RAM are directly transferred by the CPU to the Z buffer, how should I access them?
A9 I'll address this as a 2D question. (An incredible amount of calculation would be necessary if this were used in 3D.) I think this can be done by directly reading/writing the Z-buffer in DRAM in the same way as with the frame buffer. However, determination of the Z value might be something of a problem in this case.
Q10 What is the exact relationship between the screen effects of osViSetSpecialFeatures(OS_VI_DITHER_FILTER_ON) and gsDPSetColorDither()?
A10 As the result of testing, the best method in which noise and the Mach band were not apparent is as follows. Otherwise, we were able to reproduce results in which the symptoms were not really improved.
gsDPSetColorDither(G_CD_DISABLE);
osViSetSpecialFeatures(OS_VI_DITHER_FILTER_ON);
We were able only to confirm the symptoms, but it seems that there was no improvement with the combination of these two.
Furthermore, addressing only the relationship between these two, we were unable to improve the symptoms even with the following settings.
gsDPSetColorDither(G_CD_BAYER);
osViSetSpecialFeatures(OS_VI_DITHER_FILTER_OFF);
The manual says that these settings are possible, but they appeared only slightly to improve the symptoms.
The conclusion derived from the above is that
and it is probably not desirable to use these two functions together.
Q11 For the quality in the FZEROX setting screen, other than the environment map, are you also moving the light?
A11 The light is stationary and reflected. The method of having both the texture of the machine and the texture of the reflection coexist in the setting screen is, first to draw the machine, and then overwrite a translucent version of the same model with the reflection added as a decal. Incidentally, there is a black edge around the machine in the setting screen, but this serves to make the scale of the model slightly larger, and the black was rendered with the Z OFF. In other words, 3 overlaid models are rendered.
The model data are all identical with those in the game menu winning run. (Since LOD is not used in the game screen, a simplified version of the model at a distance is used...)
Q12 I've been trying to use a macro key to create transparent objects, but how do I set one up?
A12 We are not able to check macro keys. It is unclear whether or not a macro key function really exists. Please consider that macro keys cannot be used.
Q13 I am testing methods for moving images which have been rendered in the frame buffer to the work memory and then reusing the images. This seems to work pretty well for me, but there clearly appear to be more jagged edges [in the graphic] than when it was initially loaded. It seems to be because the 9th bit of memory can't be read using anti-aliasing, but is there a way to read the 9th bit?
A13 The 9th bit of RDRAM cannot be accessed from the CPU. If the jagged edges are noticeable, fix the edge with bilinear compensation, or something similar.
Q14 I want to use the triple-frame buffer in hi-res mode, but is there an effective way to use memory? How much of a FIFO buffer will I need?
A14 If by "effective" you mean you want it to be fast, dividing the frame buffer and assigning one for each RDRAM bank will slightly increase rendering speed (it depends on the conditions, but there should be an increase of several percent. In a simple trial, we saw an increase in speed of approximately 3%). The RDRAM is constructed of four (4) 1MB banks, with an active page register for each bank. Consequently, if the VI puts the frame buffer during display and the frame buffer which accesses the RCP in different banks, RDRAM access becomes somewhat faster. For the same reason, it is faster to put the Z buffers in different banks. (Since there is a line buffer in the RDP, the various rendering methods have little influence on RDRAM access speed.)
However, 2.5MB are required for a hi-res triple-frame buffer. This divides up the memory as it is allotted to the various banks, making memory allotment difficult, thus a great deal of care and skill is required in allotting memory.
The suitable FIFO buffer size then differs depending on the screen, but for the majority of cases 100KB to 150KB should be enough. You could probably adjust this by using osDpGetCounters() to discover whether or not the RDP is waiting for a command from the RSP.
Q15 Which calculation method is used when displaying the contents of a 16-bit CFB RGBA5551 with a 24-bit RGB888 or a 32-bit RGB8888? To put it simply, how are the various CFB 16-bit pixels allotted to the RGBA values?
A15 For conversion of RGB:888 and RGB:555 there are not specifically any set rules, and you should be able to freely reduce or dilute them as they are, or adjust the color. gbi.h has been supplemented with macros such as GPACK_RGBA5551.
osViSetSpecialFeatures() > gsDPSetColorDither()