system

What exactly is going on inside slInitSystem?

Q)

Please tell me what specifically the slInitSystem function does.
I would appreciate it if you could also tell me the values and modes to be set.

A)

In addition to the contents specified by the arguments, the slInitSystem function also makes the following settings inside the function. If you want to make settings other than these, you must specify them using each setting function.

slInitSystem also secures and initializes the work area used by other SGL functions.
If you use SGL functions, be sure to execute this function first. If you execute other SGL functions before executing slInitSystem, the operation cannot be guaranteed.

(0) Initialization of system variables

If a value other than 0 is entered, the following data will be entered.

(1) Window size and vanishing point position for sprites and polygons

Left	: 0
Top	: 0
Right	: ScreenXSize - 1
Bottom	: ScreenYSize - 1
Zlimit	: 0x7fff
CenterX	: ScreenXSize / 2
CenterY	: ScreenYSize / 2
PersAngle	: 90゜
ZdspLevel	: 1

* The contents of ScreenXSize and ScreenYSize change depending on the setting of the first argument.

(2) Initial settings related to scrolling

Displayed scroll surface  : NBG0, NBG1, RBG0
Scroll priority           : NBG0 NBG1 NBG2 NBG3 RBG0
                          :  7    3    2    1    4
Sprite 0                  : SPR0
(Polygon) Priority        : 6
Other sprites             : SPR1~SPR7
                          :          5
Number of scroll colors   : 256 color mode on each side
Color RAM mode            : 1 (2048 out of 32768 colors)
VRAM division             : Both banks A and B are divided
Character data            : NBG0, NBG1 from 25E60000
                          : RBG0 from 25E00000
Character size            : 8x8 dots on each side
Pattern name data         : NBG0 From 25E76000
                          : NBG1 From 257E7800
                          : RBG0 PA From 25E40000
                          : RBG0 PB From 25E50000
Pattern name size         : NBG0 10-bit pattern name with inversion per word cell
                          : NBG1 and RBG0 12-bit pattern name with no inversion per word cell
Plain size                : 64x64 cells on each side
Back screen color         : Black on 25E3FFFE (R=0,G=0,B=0)
Rotation parameters       : From 25E3FF00
Sprite data               : Mixing palette and RGB format
Special effect function   : Do not use mosaic, color offset, etc.
Sprite type               : scnSPR3
ASCII character set       : 0x25e00000(For RBG), 0x25e60000(For NBG)

I want to dynamically change the number of processed frames.

Q)

How to dynamically change the number of processed frames with slDynamicFrame?

A)

The system variable SynchConst, which is set when using slDynamicFrame with SGL, always contains a positive integer.
The processing for the negative part of the third argument of slInitSystem is as follows:

slDynamicFrame

will be in charge.

Also, if the base interval number does not change, such as from 1 to -1, there is no need to reset SynchConst.

(Example 1)

Fixed interval → Indeterminate interval

/* Switch from 1 int fixed to 2 int base undefined mode */
extern Uint8 SynchConst; /* unsigned int instead of signed int */
                         /* ^^^^^^                  ^^^^^^^^ */
slInitSystem( TV_320x224, NULL, 1 );
        :
        :
/* Set indefinite interval mode-2 */
slDynamicFrame( ON );
SynchConst = 2; /* not -2 */
slSynch();

(Example 2)

Indeterminate interval → Fixed interval

/* Change from 1 int indefinite interval to 1 int fixed interval */
slInitSystem( TV_320x224, NULL, -1 );
         :
         :
/* Set fixed interval mode 1 */
slDynamicFrame( OFF );
/* No need to change SynchConst */
slSynch();

Please tell me the difference between slInitSynch and slSynch.

Q)

Regarding slInitSynch() and slSynch(), what exactly is the difference between slInitSynch() and slSynch()?

A)

slInitSynch always waits for the next drawing. In other words, if a processing delay occurs, the process will wait until that processing completes, but with slSynch, if a processing delay occurs, it immediately ends and proceeds to the next process. In other words, slSynch may drop frames.

How can I find out about processing delays using slSynch?

Q)

When using slSynch(), frames will be dropped if the previous process exceeds the drawing processing unit.
How should I perform this check?

A)

First, set the third argument of slInitSystem to a negative number to set it to dynamic frame mode.

Then, just before running slSynch, look at the system variable SynchCount. If SynchCount is a negative number, you can tell that processing is slow.

When a program is placed in L-RAM, it runs out of control when the third argument of slInitSystem is negative.

Q)

I would like to switch frames after waiting for the writing to the frame buffer of VDP1 to be completed, but the function

slInitSystem(Uint16 TVMode, TEXTURE *txtbl, Sint8 Count)

When I changed the parameter "Count" (frame switching count) to a negative number, it went out of control.
This phenomenon occurs when the executable file is placed in LowRam.

A)

Do not place executable programs in LowRAM.

SGL does not consider placing programs in LowRAM because the transfer speed of LowRAM is slow and the SCU is outside of LowRAM's control.

About processing during Z sort.

Q)

Among the functions related to polygon and sprite registration in SGL, what kind of process is used in SGL's Z sort processing?

A)

In SGL, when displaying polygons and sprites, a FIXED type Z value is usually used as an argument, but only the upper 16 bits, or integer part, are used for actual sorting.

When entering a sprite or polygon into the buffer, the clipping due to the Z limit and near limit is compared using the upper 16 bits of the Z value, and then primary sorting is performed using the upper 8 bits of the integer part.
Furthermore, for polygons and sprites of the same degree, secondary sorting is performed using the lower 8 bits of the integer part.
Therefore, it is never used for decimal parts.

I would like to freely switch frame buffers.

Q)

If there is a way to switch frame buffers on my own in SGL, please let me know.

A)

Unfortunately, SGL does not allow the user to switch frame buffers arbitrarily.

I don't know how to specify the palette.

Q)

I don't know how to specify the scroll function slPageNbg0 to 3 (Rbg0) and the palette to use in the macro SPR_ATTRIBUTE.

A)

slPageNbg? The offset value given to gives the offset address from color RAM (0x25f00000).

Also, the SPR_ATTRIBUTE argument contains information about the number of colors from the beginning of the color RAM, so the boundaries per color will differ between 24-bit color and 15-bit color. Therefore, it is different from address offset.
For example, in 24-bit mode, the 256th color is an offset of 400h, but in 15-bit mode, it is 200h. For slPageNbg, the values given are 0x400 and 0x200, respectively, but for SPR_ATTRIBUTE, both are 256 (0x100).

I want to perform processing that waits for drawing.

Q)

In SGL, I think that sprites that cannot be drawn in time are normally interrupted in the middle of drawing, but is it possible to control things like waiting for drawing to finish before switching frames?

A)

There is a function in SGL called slInitSystem, and the third argument of this function specifies the number of frames. This is usually a positive number, but if you enter a negative number "-n", it will normally operate on a frame basis of "n" and will wait for drawing only when it cannot keep up with the drawing. can.

How do I perform processing that waits for the CPU to process?

Q)

In SGL, I want to perform processing that is waiting for CPU processing.

A)

Here is an example of how to perform processing that is waiting for CPU processing in SGL.

1. Set the maximum number of possible processes in the third argument of slInitSystem.
   However, since it only supports indeterminate mode, it is necessary to set it as a negative number.

2. When CPU processing is finished (just before calling slSynch and slInitSynch), set the system variable SynchCount to the number of frames previously set in slInitSystem.
   In this case, please note the following checks when changing this value.

   1. Disable interrupts.

   2. Check that it is not during the VBlank period. To check, check the V counter register at bit 3 of the VDP2 screen status (address 25F80004).
      If it is not the VBlank period, perform the above change process. If it is during the VBlank period, after performing the process c.), perform the processes a.) to c.) again.

   3. Cancel interrupt.

SGL's slSynch and slInitSynch check the system variables SynchConst and SynchCount and when they match, process the next frame. And SynchCount is the current number of INTs and SynchConst is the number of INTs specified by the user.
In other words, this process tricks the SGL system.

Is it better to transfer texture data using DMA or for loop?

Q)

Is it better to transfer sprites in SGL using a for loop or using DMA?

A)

Basically, it is better to transfer using DMA because it puts less load on the main program.
However, since CPU DMA requires several clocks of wait time at startup, if processing speed is a concern, memory copying using a For loop may be faster depending on the amount of data.