Please declare extern and use SGL system variables, not just PauseFlag.
there is.
This is described in SL_DEF.H. You can use this function or these macros to set the sprite's color calculation percentage.
Is there a way to use slPutSprite to arbitrarily assign priority when displaying at the same coordinates?
By default, the sorting setting for SOFTIMAGE Export is SORT_CEN, but if you set this to SORT_MAX, it will be the farthest point from the Z sorting reference point, so the missing polygons will be a little closer.
slZdspLevel contains values from 0 to 7. The higher the value, the closer the image will be displayed.
Inside SGL, clipping is applied to the Z-axis of the polygon coordinates, but no clipping processing is performed for the XY components, which causes overflow or underflow in the frame buffer space and Noise may occur. This process is to avoid this.
Specifically, it means dividing the polygon that came to the front.
Of course, if textures are pasted, the textures will also be divided, so the application needs to prepare multiple model patterns and textures for one model.
In other words,
slDispSprite(...); slSynch(); OtherProc(); ←It should be displayed at this point, but slSynch(); OtherProc(); ←It actually looks like it's displayed here
This phenomenon occurs. Why?
This is because VDP1 has a double frame buffer, and what the user writes to the command buffer is written to the back frame buffer in the next frame.
Therefore, the contents of the back buffer will be displayed in the next frame after writing to the command buffer.
In other words,
slDispSprite(...); slSynch(); ←At this time, the contents of the command are reflected in the underlying frame buffer. OtherProc(); slSynch(); ←At this point, overlap the contents of the back frame buffer with the VDP2 video. OtherProc(); ←Displayed here.
This is how it goes.
In other words, in normal usage, the contents of FormTbl cannot be changed within one unit of processing.
There are two possible ways to avoid this:
ComRdPtr, ComWrPtr
Refer to the contents of the two system variables.
These two system variables are data that is referenced when the slave is performing processing such as slPutPolygon, and when they match, the slave is not performing SGL processing .
However, since the slave CPU always looks at the cache area, the address to be compared must also be in the cache. That is, the system variable
ComWrPtr, ComRdPtr
rather than looking at it as it is
ComWrPtr+0x20000000
ComRdPtr+0x20000000
Must see.
These registers point to the addresses where the slave is reading and writing commands, and if these values are the same, the slave can be considered to be in a standby state, so first, check these two registers. Compare the values and wait until they are the same.
Next, run slCashePurge from the slave side to purge the cache. For this, use slSlaveFunction.
for example,
slInitStstem( TV_320x224, TEXTURE_TBL, 1 )
If you specify FormTbl, as in
TEXTURE_TBL[ i ].Hsize = ....
TEXTURE_TBL[ i ].Vsize = ....
TEXTURE_TBL[ i ].CGadr = ....
TEXTURE_TBL[ i ].HVsize = ....
This is how to change it. If you use this method, you won't need to know the state of the slave, but you will need to prepare enough space for the TEXTURE structure array (that is, the MAX for display sprites) at the first stage of passing it to slInitSystem. there is.
*Please note that depending on the timing of character data transfer, the displayed characters may be garbled. This seems to be because when VDP1 transfers character data to the frame buffer, the VRAM data is rewritten by the character data transfer (even though it is still in use).
To avoid such things, please transfer character data, lookup table data, and Gouraud data within the function specified by slIntFunction, or wait for VDP1 to finish drawing before transferring.
You can determine when VDP1 has finished drawing by looking at the VDP1 transfer end status register (see 4.6 Transfer End Status Register in the VDP1 User's Manual).
In addition to sprite and scroll priorities, you can also set shadows and color calculations between the two.
This type of sprite is called a sprite type in VDP2.
Sprite types can be assigned to each sprite when setting up VDP1. In SGL, this setting can be made when setting the color palette.
Let's see an example below.
First, select the sprite type you want to use.
By default, it is sprite type 3. To change it, call the slSpriteType() function with the sprite type as an argument.
next
#define PrioNo0 (0<< 12) #define PrioNo1 (1<< 12) #define PrioNo2 (2<< 12) #define PrioNo3 (3<< 12) #define PrioNo4 (4<< 12) #define PrioNo5 (5<< 12) #define PrioNo6 (6<< 12) #define PrioNo7 (7<< 12)
Suppose that is defined.
・For polygons
ATTRIBUTE( Single_Plane, SORT_CEN, tex1, PrioNo4|0x0010 , No_Gouraud,..Here, the priority number of the polygon is set to 4. In other words, priority numbers 0 to 7 can be set by ORing the pallet number.
・For slPutSprite, slDispSprite*
SPR_ATTRIBUTE( 0, SprType6|0x0000 , No_Gouraud, CL256Bnk, sprNofilp );
This also specifies the use of sprite type 6 when specifying the palette.
In any of the above cases, specify it in the colno member of the ATTR and SPR_ATTR structures.
・For slSetSprite
SPRITE spr; spr.CTRL = FUNC_Sprite; spr.PMOD = MSBOn | WindowIn | MESHoff | ECenb; spr.COLR = PrioNo2 | 0x0020; : :Specify the priority number (2 in this case) together with the palette (also using OR) in the color control word of the VDP1 command table, as shown in the following example.
Also, the priority settings for each sprite type can be set using slPriority or slPrioritySpr? Use functions. (slPrioritySpr? is a macro.)
As an example,
slPriority( scnSPR6, 5 );
Or,
slPrioritySpr6( 5 );
will do.
Is the scroll side slPriorityNBG? Use functions such as or slPriorityRBG0.
There is nothing that can be done about this as it is a Sega Saturn specification, but to avoid the dots shifting, you can either change the display position according to the rotation in the program, or change the dots by changing the dots due to the rotation when designing the sprite design. Please take this into account by drawing a shape that takes this into account.
This is because the hardware displays one dot larger than the specified display size, so if you want to avoid this, specify 0.99999 for the scale. This value is defined in SL_DEF.H by a macro called ORIGINAL.