Japanese
FAQSGL programming related
■ | Go forward
FAQ/SGL programming related

sprite/polygon



I want to temporarily suspend sprite drawing.

Q)
I want to temporarily interrupt sprite drawing.

A)
There is a system variable in SGL called PauseFlag. When this is turned ON, the transfer from the sprite buffer to VDP1, which is performed by the SGL system within V-Blank, will not be performed. This allows for the effect of not displaying the sprite during a pose, for example.

Please declare extern and use SGL system variables, not just PauseFlag.


I want to change the ratio of sprite color calculations.

Q)
How do I set the color calculation ratio (for example, semi-transparent) on the sprite screen?

A)
slColRate() is provided as a function. Also, a macro using this function

slColRate*

(example)
slColRateNBG0

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.


I want to prioritize sprite display.

Q)
When displaying 2D sprites with slPutSprite, I would like to give priority to two sprites at the same coordinates, but if I change the coordinates in the direction of the camera position, the display positions will be different when converted to transparent coordinates. .

Is there a way to use slPutSprite to arbitrarily assign priority when displaying at the same coordinates?

A)
In SGL, if you try to display at the same Z coordinate, the item (sprite or polygon) registered later in the Z buffer will have a higher priority (that is, it will be closer).
For polygons, this can be avoided to some extent by selecting a representative value for Z, but sprites have no concept of depth, so the only way to change it is through the order of function execution.
If you have enough processing time and have decided on the priority you want to assign, I think the most effective method is to calculate the position and display scale on the user side, and have the user adjust the Z position using slDispSprite().


I want to change the display position to another location using the sprite drawing function.

Q)
slPutSprite and slDispSprite treat the center point of the data as the reference point, but is it possible to change this to the top left or bottom of the center?

A)
With the slPutSprite or slDispSprite functions, basically you cannot set the drawing reference point to anything other than the center.
If you want to do something like this, specify it using slSetSprite or slDispSprite4P.


Polygons disappear or line-like noise appears on the screen.

Q)
When polygons get close to the front in SGL, they may disappear due to clipping, or line-like noise may appear on the screen.

A)

  1. Change the second argument (sorting settings) of the ATTR structure when setting polygons.

  2. 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.

  3. Increase the argument given to slZdspLevel.

  4. slZdspLevel contains values from 0 to 7. The higher the value, the closer the image will be displayed.

  5. Reduce the coordinate values that make up the polygon.

  6. 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.

  7. Change the number of polygons of the model in the front and back.

  8. 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.

supplement
Utilize the near clipping function of SGL Ver 3.0 or later.
However, in this case, you can still use the techniques in steps 1. to 4. above.


It seems like the display of sprites and polygons is delayed by one tempo.

Q)
When displaying sprites on SGL, I thought that the sprites that executed display functions in that frame (slDispSprite, slPutPolygon, etc.) would be displayed in the next frame, but it doesn't seem to work properly.

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?

A)
VDP1 is delayed by one processing frame compared to VDP2, so as you pointed out, it will not be displayed unless you run slSynch twice.

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.


I want to define a new texture by changing the system variable FormTbl.

Q)
I would like to load model data and texture data into the game at any time as the game progresses.I would like to rewrite the table of the TEXTURE structure, but I do not know the specific method.

A)
About the system variable FormTbl and drawing polygons and sprites> When using polygon or sprite drawing request functions, FormTbl is referenced within the function, and these functions issue commands by checking the contents of the cache.

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:

Method 1: Change the address itself shown in FormTbl
[Step 1] Purge the cache on the slave side.
Before reconfiguring FormTbl, purge the cache from the slave side and reflect the updated results to enable the above program to operate. Specifically, first confirm that slave processing has finished. To know the slave activity status,

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.

[Step 2] Purge the cache on the slave side.

Method 2: Change FormTbl.
Change the contents of the structure indicated by FormTbl.
This method is to change the original data without changing FormTbl at all.

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).


What is the Z position given to the sprite drawing function?

Q)
Q8) What is the Z position used in the sprite drawing function?

A)
A8 ) The Z position is only used to determine the priority between sprites. There is no change in scale when changing the Z position.

I want to save the contents of the framebuffer.

Q)
Q9) I would like to use SGL to leave the previous content in the VDP1 frame buffer and overwrite the sprite on top of it (without erasing it).What settings should I make?

A)
A9 ) There is a function called slGetFrameData, although the processing may be slightly different from what you want. This function allows you to save the frame buffer data and use it in the next frame. However, there is a limit to memory, and the contents of VDP2 are not reflected, so when using it, you should consider that it is almost impossible to use it to fill the entire screen.

Can I use the UseLight option for palettes and color lookups?

Q)
Q10) In SGL, if I specify light source calculation processing for a polygon with a specified texture (simply called a texture in the manual), will the result be reflected correctly when it is actually drawn?

A)
A10 ) Basically, the USE_LIGHT option works with SGL polygons only if the texture is written in RGB mode. This is a VDP1 specification, so it is not limited to SGL. However, even in the palette format, there are ways to achieve this by directly manipulating the palette.

Please tell me how to use the slSetSprite function.

Q)
Q11 ) I don't really understand how to use the slSetSprite function.

A)
A11 ) slSetSprite is a function for directly manipulating data in the VDP1 command table, and its details match the VDP1 commands. If you would like to know how it is used, and if you are using Cinepak, please refer to the Cinepak sample program. Please also take a look at the included sample program.

I want to give priority to scrolling for each sprite.

Q)
I don't know how to give priority to sprites in an SGL environment.
When I do something like slPriority(scnSPR0,7), where (and how) do I set for each sprite that this is SPR0 and this is SPR1?
Is it possible to display sprites across the BG screen using SGL?

A)
--- Regarding sprite types and priorities --- When sprite data is sent to VDP2, it is recognized as 8 types of data, each of high resolution and low resolution, depending on the type. VDP2 sets scrolling and sprite priorities according to each type. Sprites and scrolls can be displayed in order by setting the relationship between the 8 types of scrolls and their priorities.

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.

reference
VDP1 User's Manual 6.4 CMDCOLR Color Bank
VDP2 User's Manual 9.1 Sprite Data

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.


When I rotate the sprite, it shifts by 1 dot.

Q)
When I rotate a sprite using a sprite drawing function such as slPutSprite, slDispSpirte, or slSetSprite, the sprite appears shifted by one dot. How can I fix this?

A)
When rotating a sprite, the center of rotation is the center.
On the Sega Saturn, the number of dots in the horizontal direction of a sprite is based on a multiple of 8, so if you look at it in units of dots, there is no exact center dot. Therefore, when rotating the sprite, it inevitably shifts by one dot.

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.


When a sprite is displayed, it looks 1 dot larger.

Q)
When displaying a sprite with slDispSprite, the picture was displayed one dot larger than the specified size. What is the cause.

A)
If you specify 1.00 for the scale with the slDispSprite function, the image will be displayed 1 dot larger than the original image.

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.


■ | Go forward
FAQSGL programming related
Copyright SEGA ENTERPRISES, LTD. 1997