| QA1 | Is sorting required for proper display of translucent polygons? |
| QA2 | Realizing fog in 1 cycle mode |
| QA3 | Anti-aliasing does not work on transparent primitives |
| QA4 | Color and translucent processing with the blender and G_RM_ADD |
| QA5 | How to prevent overflow of results from calculations in ADD rendering mode |
| QA6 | When 3D data is displayed, you can faintly see the picture behind it |
| QA7 | When using OPA_SURF can you make excess areas transparent? |
| QA8 | I set the Z value with gDPSetPrimDepth when I used "rectangle" but the Z-Buffer was not enabled |
| QA9 | About the PCL mode of gDPSetRenderMode |
| QA10 | When various RenderMode's are mixed together |
Q1 When several translucent polygons are layered, can they be accurately written if they are not rendered once they have been sorted in the Z direction?
A1 When rendering 3 or more translucent polygons layered on one another, strictly speaking, accurate color information cannot be obtained if they are not rendered after being Z-sorted. The colors will shift a little at a time. However, you could verify the extent to which the color has shifted in the areas where the multiple translucent polygons were overlapped, and use them without sorting as long as the color shift is not a problem. Try this with a variety of games.
Q2 I thought that I had applied fog in 1 cycle mode as was described in the Programming Manual, but when I use the Z buffer, the fog is not applied. What should I do?
A2 As you pointed out, fog will normally not be applied when you do it as outlined in the manual. When you do it according to the manual, the Z buffer processing is performed on the second cycle of the render mode. We tried creating a new render mode as follows, so that both fog processing and Z buffer processing are performed in the first cycle.
#define G_RM_ZB_1C_FOG_SHADE_A \
Z_CMP | Z_UPD | CVG_DST_FULL | ALPHA_CVG_SEL | ZMODE_OPA | \
GBL_c1(G_BL_CLR_FOG, G_BL_A_SHADE, G_BL_CLR_IN, G_BL_1MA)
#define G_RM_ZB_1C_FOG_SHADE_A2 \
CVG_DST_FULL | FORCE_BL | ZMODE_OPA | \
GBL_c2(G_BL_CLR_FOG, G_BL_A_SHADE, G_BL_CLR_IN, G_BL_1MA)
gDPSetRenderMode(G_RM_ZB_1C_FOG_SHADE_A,G_RM_ZB_1C_FOG_SHADE_A2);
I think this should probably display fog nicely. Give it a try.
Q3 When I display translucent texture rectangles as a covering over anti-aliased 3D polygons, if the texture rectangles are rendered without anti-aliasing, then the initially drawn polygons also lose their anti-aliasing. What should I do?
A3 You are probably using G_RM_ZB_XLU_SURF as the primitive render mode for texture rectangle rendering. Either use G_RM_ZB_CLD_SURF or stick with G_RM_ZB_XLU_SURF but attach the CVG_DST_WRAP flag. Drawing of texture rectangles with that render mode should work fine.
Q4 The colors don't appear as I thought they would when I do translucent processing using the blender with G_RM_ADD.
A4 This may be because the color addition result is over 255 and caused an overflow. When the RCP overflows due to a calculation result, that result is not guaranteed. It is impossible to predict what kind of result you will get. In other words, when an overflow occurs because rendering is not set up to clamp calculation results whose values are over 255, you will get unexpected results in the control of those colors.
Q5 How exactly do I "make it so that the addition operation results will not overflow" in the ADD rendering mode?
A5 When using primitive colors, etc., it should be possible to pre-adjust the colors of the pixels which will be added to the colors in memory. Theoretically, it is possible to "prevent an overflow" in addition between textures using similar pre-addition adjustment.
Q6 When 3D data is displayed, you can faintly see the picture behind it. Can you think of any reason for this happening?
A6 Maybe Render mode is not set.
Another possibility has to do with the color combiner settings. For the TEXO * PRIM calculation, if both are "255" the result of the calculation can still be "254" and there will be a little transparence. To get around this problem, add "1" to the result.
Q7 When using OPA_SURF can you make excess areas transparent?
A7 Yes, that is possible. However, you cannot apply anti-aliasing. Use the method shown below. (For details, see the Online Manual.) Of course, this assumes the "excess areas" have an alpha = 0
gsDPSetAlphaCompare(G_AC_THRESHOLD) gsDPSetBlendColor(0,0,0,alpha)
Q8 Z value was set by gDPSetPrimDepth when rectangle is used, but Z-Buffer didn't become effective.
A8 One of the following functions may be missing. Please confirm.
gsDPSetDepthSource(G_ZS_PRIM) gsDPSetCycleType(G_CYC_1CYCLE) gsDPSetRenderMode(G_RM_ZB....)
Q9 When PCL is used with gsDPSetRenderMode, particles appear in any objects which are subsequently rendered in the _OPA or _XLU mode. How can I avoid this?
A9 Particles can be set with gsDPSetRenderMode, but they cannot be reset. Execute
gsDPSetAlphaCompare(G_AC_NONE)
to reset particles.
Q10 Are there any precautions when mixing opaque, translucent, and missing objects, etc.?
A10 The database during rendering is divided in 3, "opaque (OPA)", "translucent (XLU)", and "missing (TEX_EDGE)." In other words, when creating data at the designer level, more efficient operation is possible by grouping objects taking these attributes into consideration. The priority order of the actual render modes is as follows: