CSG_TAG_SCREENCOUNT - This tag argument defines how many screens are created for the new screen group. Typically, you create two screens in order to create double-buffered displays. Although you may want a screen group with only a single screen to show a static display. You may want to create a stereoscope display with three or four screens in the group. If you don't specify a screen count, the default number is one.
CSG_TAG_SCREENHEIGHT - This tag argument specifies the actual height of your screen's framebuffer. This may be different from the display height of the screen, which is the height of the visible portion of your screen. The default width is reported by calling QueryGraphics() with the tag QUERYGRAF_TAG_DEFAULTHEIGHT.
CSG_TAG_DISPLAYHEIGHT - This tag argument to specifies the display height of your screen. The display height is the visible portion of the screen. You can create a screen that's taller than the display height. The display height must always be equal to or less than the screen height. The default is reported by calling QueryGraphics() with the tag QUERYGRAF_TAG_DEFAULTHEIGHT.
CSG_TAG_BITMAPCOUNT - This tag argument specifies how many bitmaps each screen will have. Each screen within a screen group has to have the same number and configuration of bitmaps. The count specified by this tag argument is the bitmap count per screen, not the total bitmap count. The default bitmap count per screen is one.
CSG_TAG_BITMAPWIDTH_ARRAY - In a screen with multiple bitmaps, each bitmap can have its own width. To specify a unique width per bitmap, or to have a width that's other than the system's default width, use this tag argument to supply the pointer to a table of widths. The elements of the array are interpreted as int32 values. There must be one entry for each bitmap of a single screen. If you don't specify a bitmap width array, then all bitmaps are of the width reported by calling QueryGraphics() with the tag QUERYGRAF_TAG_DEFAULTWIDTH.
CSG_TAG_BITMAPHEIGHT_ARRAY - In a screen with multiple bitmaps, each bitmap can have its own height. If you want to specify a unique height per bitmap, use this tag argument to supply the pointer to a table of heights. The elements of the array are interpreted as int32 values. There must be one entry for each bitmap of a single screen. If you have only one bitmap per screen, you don't need to specify a height for that bitmap; the default is to use the height reported by calling QueryGraphics() with the tag QUERYGRAF_TAG_DEFAULTHEIGHT. If you have more than one bitmap per screen, you must specify a bitmap width array.
CSG_TAG_BITMAPBUF_ARRAY - Normally, the system will allocate your frame buffers for you. However, you can have specific preallocated frame buffers associated with the screens of your display. Designate your own buffers using this tag argument. Paired with this tag argument is the pointer to an array of buffer pointers.The elements in the array are interpreted as pointers to the starting addresses of your frame buffers. There must be an entry for every bitmap in every screen. For example, if you have two screens and each screen has three bitmaps, then the bitmap buffer array must have six entries. If you don't specify a bitmap buffer array, the default is the system allocates the appropriate frame buffers for you. Even if you choose to have the system allocate buffers for you, use the CSG_TAG_SPORTBITS tag argument to specify SPORT access details.
CSG_TAG_SPORTBITS - This tag argument takes SPORT transfers into consideration when setting up the bitmap frame buffers. SPORT transfers have certain memory requirements and restrictions, all of which are handled by using the correct flag bits when allocating frame buffer memory; for example, a call to GetBankBits() is usually required to make sure that SPORT memory transfers occur in the same bank of memory. You specify the flag bits that are used when allocating frame buffer buffers with this tag argument. Not only does this tag argument allow you to control memory allocations, but its presence implies that all normal SPORT care (page alignment, page size adjustment) should be done when making the allocation. If this tag argument is used but the associated value is null, this designates that any buffers allocated by the system must be in the same bank of memory, although any bank will do. If this tag argument is absent, the default is to presume that SPORT transfers don't have to be considered when allocating framebuffers.
CSG_TAG_VDLTYPE - Every screen needs a VDL. The Graphics folio supports several types of VDLs. You can supply your own VDL, or you can choose to have the system construct one for you. If you supply your own, you have to specify the type of VDL you are supplying. If you choose to have the system construct a VDL for you, you may wish to specify the type of VDL to be built (rather than just accepting the default). The types of VDLs supported by the system include:
VDLTYPE_SIMPLE - The simple VDL has one entry, which points to the frame buffer and has CLUT and display control words. This type of VDL is the default.
VDLTYPE_FULL - This VDL has an entry for every line of the display, which entry includes a buffer address and a full CLUT.
VDLTYPE_COLOR - With this VDL, there is an entry for every line of the display, which entry has the space for a full CLUT. The color VDL does not allow line-by-line modifications of the buffer address. This type of VDL is not yet supported.
VDLTYPE_ADDRESS - This VDL provides an entry for every line of the display, which entry has a buffer address. This allows line-by-line control over the data that is displayed on any given line. The address VDL does not allow line-by-line CLUT modifications. This type of VDL is not yet supported.
VDLTYPE_DYNAMIC - The dynamic VDL can be modified with wild abandon. It can grow and shrink dynamically. This type of VDL gives you maximum flexibility, but it requires a great amount of processing overhead and so it's the least attractive type of VDL in that regard.