background image
General Notice
When using this document, keep the following in mind:
1. This document is confidential. By accepting this document you acknowledge that you are bound
by the terms set forth in the non-disclosure and confidentiality agreement signed separately and /in
the possession of SEGA. If you have not signed such a non-disclosure agreement, please contact
SEGA immediately and return this document to SEGA.
2. This document may include technical inaccuracies or typographical errors. Changes are periodi-
cally made to the information herein; these changes will be incorporated in new versions of the
document. SEGA may make improvements and/or changes in the product(s) and/or the
program(s) described in this document at any time.
3. No one is permitted to reproduce or duplicate, in any form, the whole or part of this document
without SEGA's written permission. Request for copies of this document and for technical
information about SEGA products must be made to your authorized SEGA Technical Services
representative.
4. No license is granted by implication or otherwise under any patents, copyrights, trademarks, or
other intellectual property rights of SEGA Enterprises, Ltd., SEGA of America, Inc., or any third
party.
5. Software, circuitry, and other examples described herein are meant merely to indicate the character-
istics and performance of SEGA's products. SEGA assumes no responsibility for any intellectual
property claims or other problems that may result from applications based on the examples
describe herein.
6. It is possible that this document may contain reference to, or information about, SEGA products
(development hardware/software) or services that are not provided in countries other than Japan.
Such references/information must not be construed to mean that SEGA intends to provide such
SEGA products or services in countries other than Japan. Any reference of a SEGA licensed prod-
uct/program in this document is not intended to state or simply that you can use only SEGA's
licensed products/programs. Any functionally equivalent hardware/software can be used instead.
7. SEGA will not be held responsible for any damage to the user that may result from accidents or any
other reasons during operation of the user's equipment, or programs according to this document.
(11/2/94- 002)
This is a preliminary document
and is subject to change without notice. This document could include
technical inaccuracies or typographical errors. Changes are periodically made to the information
herein; these changes will be incorporated in official versions of the publication.
NOTE: A reader's comment/correction form is provided with this
document. Please address comments to :
SEGA of America, Inc., Technical Translation and Publications Group
(att. Document Administrator)
150 Shoreline Drive, Redwood City, CA 94065

SEGA may use or distribute whatever information you supply in any way
it believes appropriate without incurring any obligation to you.
background image
SGL Developer's Manual
Tutorial
Development Environment
Programmer's Tutorial
Designer's Tutorial
Sound Tutorial
Transfer of Data
background image

Development
Environment
This manual describes the hardware and software
development environment required for SEGA Sat-
urn software development. The recommended envi-
ronments for programmers, designers, sound design-
ers, and the network are each described individually.
Read each section and procure the materials and
tools needed in order to create each environment.
background image

1
Contents
SEGA's Recommended Development Environment .... 1
Development Environment for Programmers .............. 2
Development Environment for Designers .................... 4
Development Environment for Sound Designers ........ 6
Network Environment .................................................... 8
NFSH server/client network environment (for 3 to 6 people) ... 8
Dedicated server network (for 7 or more people) .................... 9
PC-AT and Macintosh network environment ......................... 10
Connection methods ............................................................. 10
Appendix: Hardware Costs ..................................................... 11
background image

List of Figures and Tables
Figures
Fig 1
SEGA's Recommended Development Environment .......................... 1
Fig 2
SEGA's Recommended Hardware Environment for Programmers .... 3
Fig 3
SEGA's Recommended Hardware Environment for Designers .......... 5
Fig 4
SEGA's Recommended Hardware Environment for Sound
Designers ........................................................................................... 6
Fig 5
NFSH Server/Client Network Environment (for 3 to 6 people) ........... 8
Fig 6
Dedicated Server Network (for 7 or More People) ............................. 9
Fig 7
PC-AT and Macintosh Network Environment ................................... 10
Fig 8
Connection Using One Hub (8 to 16 Machines) ............................... 10
Fig 9
Connection Using Two or More Hubs (for More Than 16 Machines) .. 11
Tables
Table 1 Hardware Configuration ..................................................................... 2
Table 2 List of Language Tools for Development Work ................................... 2
Table 3 List of Representative Tools for Designers ......................................... 4
Table 4 List of SEGA's Recommended Hardware for Designers .................... 4
Table 5 List of Hardware for Sound Designers ............................................... 6
Table 6 List of Software for Sound Designers ................................................. 7
background image

Development Environment
1
SEGA's Recommended Development Environment
Fig 1 SEGA's Recommended Development Environment
SEGA recommends a development environment similar to the one shown in the figure.
In this integrated environment linked together by a network, a Sun or Hewlett-Packard worksta-
tion serves as the development host, while a Silicon Graphics, Macintosh, or other system is
used by the designers, with an additional Macintosh for the sound design work.
background image


2
Development Environment
Development Environment for Programmers
The following tables give suggestions and recommendations for the hardware and software
systems needed for development work.
Table 1 Hardware Configuration
Tool
Model
Remarks
Development host
6
Sun Sparc
32MB or more of RAM, 500MB or more of hard disk
storage, SUN-OS 4.1.1 or later, X11R4 OPEN
Window
HP9000/700
32MB or more of RAM, 500MB or more of hard disk
storage, HP-UX 8.0.5 or later, OSF Motif
IBM-PC compatible
486 CPU (66 MHz), 8MB or more of RAM, 300MB or
more of hard disk storage, MS-DOS 5.0 or later,
MS-Windows 3.1
Debugger
6
E7000 + LAN board
Ethernet type
Development target
6
Target Box
Connect TV monitor to target in order to check video.
6
: Product recommended by SEGA
Table 2 List of Language Tools for Development Work
Tool
6
Hitachi Revised C
Remarks
Compiler
SH-2C compiler
Used by the SEGA Graphics Library
Assembler
SH-2 cross assembler
Linker
Linkage editor
Used by the SEGA Graphics Library
Debugger
GUI debugger
Used by the SEGA Graphics Library
DSP tool
Assembler, simulator
Provides a DSP library for matrix operation DMA
transfers
6
: Product recommended by SEGA
background image

Development Environment
3
Based on the products marked with stars in the previous charts, SEGA's recommended develop-
ment environment is as follows.
Hitachi's Revised C compiler is used for the development language. A Sun, Hewlett-Packard,
or equivalent UNIX workstation serves as the development host in the network environment,
and is connected via an ICE to a target box with TV monitor. A configuration diagram follows.
Fig 2 SEGA's Recommended Hardware Environment for Programmers
The explanations provided subsequently in this manual will assume that the above configuration
is being used.
background image


4
Development Environment
Development Environment for Designers
There are a number of conceivable hardware configurations for designers to do development
work. However, for design work, the specific software used is much more important than the
hardware. Therefore, the following table indicates representative products for each of the
different essential tools, and also indicates the type of system on which that software can run.
Table 3 List of Representative Tools for Designers
Tool
Compatible System
Product Name
Remarks
SGI
Mac
3D tool
6
Softimage Creative env.
Product recommended by SEGA
2D tool
6
Adobe Photoshop
Product recommended by SEGA
Adobe Illustrator
Pixel Paint Professional
6
Degitaizer
Tool provided by SEGA
Data filter
6
DeBebelizer
Product recommended by SEGA
Adobe Photoshop
6
: Product recommended by SEGA
In addition to the above, SEGA also provides SMAP, which is software that adds texture to 3D
models.
SEGA recommends the following development environment.
In terms of hardware, a Silicon Graphics machine, such as INDY or INDIGO2, could be used
for the 3D tool, and a Macintosh could be used for the 2D tool, all running under one network.
The hardware configuration diagram and specifications are shown below for reference purposes.
Table 4 List of SEGA's Recommended Hardware for Designers
Tool
Model
Remarks
Development host
6
INDY, INDIGO2
R4400SC CPU recommended, 64MB or more of
RAM, 1GB or more of hard disk storage, 24-bit full
color (and equipped with a geometry engine, if
possible)
6
Macintosh
68040 CPU recommended, 16MB or more of RAM,
100MB or more of hard disk storage, 24-bit full-color
video card (not needed if host provides a full-color
environment)
6
: Product recommended by SEGA
background image

Development Environment
5
Fig 3 SEGA's Recommended Hardware Environment for Designers
For software, the products marked with a star in the previous chart are recommended by SEGA.
The explanations provided subsequently in this manual will assume that the above configuration
is being used.
background image

6
Development Environment
Development Environment for Sound Designers
Although names of typical software products that are representative of basic minimum of
required tools are listed later, because there are a countless number of models for the different
hardware devices needed for sound design work, the following table lists categories of devices
and the essential functions required in each category.
Table 5 List of Hardware for Sound Designers
Category
Remarks
Macintosh
Centris 650 or higher, 16MB of RAM or more, and 500MB or more of hard
disk storage recommended
MIDI instrument
Music keyboard, etc., with a MIDI-OUT jack
MIDI sound source
A device that can be connected to a Macintosh in order to listen to music
created with sequencer software (a device that can not be connected to a
Macintosh but which can connect to a MIDI interface is also possible)
Sampling source
A CD player or DAT is required. (If using SEGA's Wave editor, a unit with
an optical output is required.)
Development target
An amp and headphones, etc., so that it is possible to listen to the sounds.
(It is also probably necessary to hook up a TV so that the sound of the
game through the TV speaker can also be checked.)
The target box connects to the Macintosh system, MIDI sound source, amp, etc., as well as to
the DAT deck or CD player to be used for voice and music sampling. (If the Audio Media 2
board is to be connected, it connects to the Macintosh.)
Fig 4 SEGA's Recommended Hardware Environment for Sound Designers
Macintosh
Target Box
Amp, etc.
DAT
MIDI instrument
MIDI sound source
RS-422
MIDI-THRU
MIDI-IN
background image

Development Environment
7
Table 6 List of Software for Sound Designers
Tool
Product
Remarks
Waveform editor
6
SOUND DESIGNER 2 Also handles sounds sampled from an Audio Media
2 board in a Macintosh
Alchemy
Wave Editor
Tool provided by SEGA (can output sound directly
from the target)
Tone editor
Tone Editor
Tool provided by SEGA
Sequencer
6
Vision
Cubase
Performer
Effector
Linker
Tool provided by SEGA
Simulator
SATURN SndSim
Tool provided by SEGA
6
: Product recommended by SEGA
background image


8
Development Environment
Network Environment
Once the development systems described up to this point for the programmers, designers, and
sound designers are linked by a network, software development can begin. The network envi-
ronment depends on the number of people working on the project (i.e., the number of machines
on the network). The details of the network configuration (server and clients) and the costs of
constructing the network are described below separately for each case, according to the number
of people involved.
NFSH server/client network environment (for 3 to 6 people)
In the following environment, an Indy system functions as both a server and a client.
Fig 5 NFSH Server/Client Network Environment (for 3 to 6 people)
Basic network
NFS server
and client
Client
INDY
HD
Ethernet
Client
Client
LocalTalk
EtherPrint, etc.
Macintosh-
compatible printer
NFS server
Cliant
Printer
Software
Hardware
Indy
PC-AT
Macintosh
SoftWare
HardWare
HardWare
SoftWare
HD (hard disk) 3 to 4GB for one project
Ex:Virtual Fighter
1.5GB for program
1.0GB for design
1.0GB for sound
3.5GB total
Network File System 5.2 (Silicon Graphics)
Required in order to connect Indy to a network
KA-Share
Connects the Macintoshes to the Unix system
and exchanges data
K-Spool
Permits output from the Unix system to the
Macintosh-compatible printer
pc-nfsd (freeware)
Enables NFS from a PC-AT
Network File System 5.2 (Silicon Graphics)
Required in order to connect Indy to a network
Network board
Macintosh-compatible printer
EtherPrint II
For conversion between LocalTalk and
EtherTalk
Transceiver box
NSF software
background image


Development Environment
9
Dedicated server network (for 7 or more people)
In this network, a SparcStation 5 or similar workstation functions as a dedicated server, and the
performance of the server is enhanced by using an Ether/SCSI board.
Fig 6 Dedicated Server Network (for 7 or More People)
Basic network
NFS server
Client
INDY
PC-AT
Client
Client
Client
Macintosh-compatible
printer
LocalTalk
EtherPrint, etc.
Client
SS5
HD
NFS server (SparcStation 5, etc.)
Client
Hardware
Hardware
Indy
PC-AT
Macintosh
Software
Hardware
Hardware
Software
Memory
64MB or more
PrestoServ (NFS board)
Uses hard disk cache to improve NFS performance
SCSI/Ether board (*)
Extends capabilities of Ethernet and SCSI bus
Ethernet: Improves Ethernet performance through
segment partitioning
SCSI: Improves hard disk performance through
connection to multiple SCSI buses
HD (hard disk)
3 to 4GB for one project
Ex: Virtual Fighter
1.5GB for program
1.0GB for design
1.0GB for sound
3.5GB total
KA-Share
Connects the Macintoshes to the Unix system and
exchanges data
K-Spool
Permits output from the Unix system to the
Macintosh-compatible printer
(*) Not really needed if network is configured for only
7 to 15 people.
Network File System 5.2 (Silicon Graphics)
Required in order to connect Indy to a network
Network board
Transceiver box
NSF software
Software
Ethernet
background image


10
Development Environment
PC-AT and Macintosh network environment
An efficient network environment can be constructed using a NetWare server.
*NetWare is well-suited to both the Mac and to the PC-AT (Windows, etc.).
Fig 7 PC-AT and Macintosh Network Environment
NetWare server
Client
Hardware
Software
PC-AT
Macintosh
Hardware
Hardware
Software
Memory
64MB or more
HD (hard disk) 3 to 4GB for one project
Ex: Virtual Fighter
1.5GB for program
1.0GB for design
1.0GB for sound
3.5GB total
NetWare 3.12J
Network board
Transceiver box
NSF software
Basic network
NETWARE server
Client
Macintosh-compatible
printer
LocalTalk
EtherPrint, etc.
Client
PC
HD
Ethernet
Connection methods
The network connection methods differ as shown below, depending on the number of machines
in the network.
Fig 8 Connection Using One Hub (8 to 16 Machines)
HUB
Indy
Indy
Mac
MacPrinter
There are a variety of different types available from
different manufacturers (8 ports, 16 ports, etc.).
A system costing 60,000 to 90,000 should be sufficient.
Currently the most widely used type of Ethernet cable.
Can be used with most workstations.
Indy: Standard
SS5: Standard
PC-AT: Requires 10BASE-T Ethernet board
Macintosh: Requires 10BASE-T transceiver box
Ethernet hub
10BASE-T (twisted-pair cable)
background image

Development Environment
11
Fig 9 Connection Using Two or More Hubs (for More Than 16 Machines)
HUB
HUB
HUB
Workstations, Macintoshes, PC-ATs, printers
Appendix: Hardware Costs
Hardware Costs
[Servers]
Indy (IRIX5.2)
Software
KA-Share (dit Co.)
233,000 (2 users) ~
K-Spool (dit Co.)
220,000
pc-nfsd (freeware)
0
SparcStation 5 (Solaris 2.3), etc.
Hardware
Main unit (memory: 64MB)
2,012,000
PrestoServe
630,000
SCSI/Ether board
230,000
Software
KA-Share (dit Co.)
233,000 (2 users) ~
K-Spool (dit Co.)
220,000
NetWare server
Hardware
Main unit
300,000
Software
NetWare 3.12J (Novell)
190,000 (5 users)
390,000 (10 users)
630,000 (25 users)
950,000 (50 users)
[Clients]
Macintosh
Hardware
Transceiver box
?
background image

12
Development Environment
PC-AT
Hardware
Network board
NE2000 (Novell)
4
Software
NFS software
PC/TCP2.3 (Allied Telesys)
5
[Hubs]
8 ports to 16 ports
6~
[Printers]
Hardware
Main unit
MICROLINE-803PSII
648,000
EtherPrint
EtherPrintII
128,000
NFSH server/client network environment (for 3 to 6 people)
Indy (IRIX5.2)
Software
KA-Share (dit Co.)
233,000 (2 users) ~
pc-nfsd (freeware)
0
Total:
233,000 ~
Printer
Software (required if the server is a UNIX server)
K-Spool (dit Co.)
220,000
Hardware
Main unit
MICROLINE-803PSII
648,000
EtherPrint
EtherPrintII
128,000
Total:
986,000
PC-AT and Macintosh network environment
NetWare server
Hardware
Main unit (486DX4-99MHz)
500,000
Software
NetWare 3.12J (Novell)
190,000 (5 users)
390,000 (10 users)
630,000 (25 users)
950,000 (50 users)
Total:
690,000 (5 users)
background image
Development Environment
13
Printer
Software (required if the server is a UNIX server)
K-Spool (dit Co.)
220,000
Hardware
Main unit
MICROLINE-803PSII
648,000
EtherPrint
EtherPrintII
128,000
Total:
986,000
background image

Programmer's Tutorial
The SEGA Saturn Programmer's Tutorial is de-
signed to teach programmer's all that they need to
know in order to develop 3D software for the SEGA
Saturn system.
This manual assumes that the SEGA Graphics Li-
brary (SGL) will be used for programming, and
explains the necessary steps involved in 3D software
development by using sample programs. This manual
also provides a basic overview of 3D software, and is
designed to be understood even by programmers
with no experience in programming 3D software.
Although this manual is written with 3D software
programming in mind, much of the information
contained within can also be applied to conventional
2D games.
background image

1
Table of Contents
SEGA 3D Game Library .............................................. 1-1
Flow of Programming Work ................................................................... 1-2
Host machine settings ....................................................................... 1-3
ICE settings ....................................................................................... 1-3
Setting up and executing the Make file .............................................. 1-4
Debugger startup and initial settings ................................................. 1-5
Loading and executing a program ..................................................... 1-6
Debugging ......................................................................................... 1-6
Notes on Using the Library .................................................................... 1-8
Values used in the library .................................................................. 1-8
Coordinate system ............................................................................. 1-9
Graphics....................................................................... 2-1
Polygons ............................................................................................... 2-2
Polygons in SGL ................................................................................... 2-3
Polygon drawing subroutine .............................................................. 2-4
Parameters required for drawing a polygon ....................................... 2-6
Combining Multiple Polygons ................................................................ 2-9
Creating cubes................................................................................... 2-9
The Polygon Distortion Problem ......................................................... 2-11
Supplement. SGL Library Functions Covered in this Chapter ............ 2-12
Light Sources .............................................................. 3-1
Light Sources ........................................................................................ 3-2
Setting up a Light Source ...................................................................... 3-3
Supplement. SGL Library Functions Covered in this Chapter ............... 3-6
Coordinate Transformation ........................................ 4-1
Coordinate System................................................................................ 4-2
Projection Transformation ..................................................................... 4-3
Projection with perspective ................................................................ 4-3
Viewing volume.................................................................................. 4-4
Modeling Transformation ...................................................................... 4-8
Object rotation ................................................................................... 4-9
Object shift ....................................................................................... 4-12
Object enlargement/reduction.......................................................... 4-14
Special Modeling Transformations .................................................. 4-16
Differences that depend on the transformation sequence ............... 4-17
background image

2
Clipping ............................................................................................... 4-18
2D clipping ....................................................................................... 4-18
3D clipping ....................................................................................... 4-19
Windows ............................................................................................. 4-21
Window concept .............................................................................. 4-21
Setting up a window in SGL............................................................. 4-21
Resetting the default window ........................................................... 4-23
Sample program .............................................................................. 4-24
Extent of effects of windows ............................................................ 4-27
Supllement. SGL Library Functions Covered in this Chapter ............. 4-28
[Demonstration Program A: Bouncing Cube]
demo_A .................................................................... D-A-1
Matrices........................................................................ 5-1
Matrices ................................................................................................ 5-2
Object Representation Using Hierarchical Structures ........................... 5-3
Stack .................................................................................................. 5-3
Overview of hierarchical structures .................................................... 5-4
Definition of hierarchical structures in the SEGA Saturn system ....... 5-5
Matrix Functions .................................................................................... 5-8
Supplement. SGL Library Functions Covered in this Chapter ........... 5-9
[Demonstration Program B: Matrix Animation]
demo_B .................................................................... D-B-1
The Camera.................................................................. 6-1
Camera Definition and Setup ................................................................ 6-2
Camera Setup Using "slLookAt" ............................................................ 6-3
Actual Camera Operation...................................................................... 6-4
Supplement. SGL Library Functions Covered in this Chapter .............. 6-6
Polygon Face Attributes ............................................. 7-1
Attributes ............................................................................................... 7-2
Plane ..................................................................................................... 7-3
Sort ....................................................................................................... 7-5
Texture .................................................................................................. 7-7
Color ................................................................................................... 7-13
background image

3
Gouraud .............................................................................................. 7-14
Mode ................................................................................................... 7-17
Dir ....................................................................................................... 7-18
Option ................................................................................................. 7-19
Supplement. SGL Library Functions Covered in this Chapter ............ 7-19
Scrolls .......................................................................... 8-1
Scrolls in SGL ....................................................................................... 8-2
Scroll Configuration Units...................................................................... 8-3
Screen Modes ....................................................................................... 8-4
Scroll Screens ....................................................................................... 8-6
Storing Scroll Data in Memory .............................................................. 8-7
Scroll data types ................................................................................ 8-7
Storing scroll data in VRAM ............................................................... 8-8
Notes on storing data in VRAM (1) .................................................... 8-9
Notes on storing data in VRAM (2) .................................................. 8-10
Color RAM ....................................................................................... 8-11
Storing data in color RAM ................................................................ 8-12
Scroll Function Settings ...................................................................... 8-13
Character patterns ........................................................................... 8-14
Scroll limitations due to the number of character colors .................. 8-15
Pattern name data ........................................................................... 8-16
Pattern name data types .................................................................. 8-17
Pages .............................................................................................. 8-18
Planes .............................................................................................. 8-20
Maps ................................................................................................ 8-21
Reduction setting ............................................................................. 8-22
Function settings unique to the rotating scroll screen (1) ................ 8-23
Function settings unique to the rotating scroll screen (1) ................ 8-25
Scroll setting flow chart ................................................................... 8-26
Scroll Drawing ..................................................................................... 8-27
Background screen setup ................................................................ 8-27
Display position setting .................................................................... 8-28
Scroll registration ............................................................................. 8-29
Notes on scroll registration .............................................................. 8-30
Drawing start ................................................................................... 8-31
Flow of operations up to scroll drawing ........................................... 8-32
Normal Scroll Screens ........................................................................ 8-33
Normal scroll screen movement ...................................................... 8-33
Normal scroll screen enlargement/reduction ................................... 8-38
background image

4
Rotating Scroll Screen ........................................................................ 8-41
Rotating scroll shift .......................................................................... 8-41
Rotating scroll screen enlargement/reduction.................................. 8-41
Rotating scroll screen rotation ......................................................... 8-42
Special Scroll Functions ...................................................................... 8-50
ASCII scrolls .................................................................................... 8-50
Transparent color bits ...................................................................... 8-53
Color calculations ............................................................................ 8-56
Line color screen ............................................................................. 8-58
Color offset ...................................................................................... 8-60
Priority ................................................................................................. 8-61
Displaying Text and Numeric Values .................................................. 8-64
Supplement SGL Library Functions Covered in this Chapter ............. 8-68
Controller Input ........................................................... 9-1
Input System Used by the SEGA Saturn .............................................. 9-2
Actual Operation ................................................................................... 9-3
Bits used by the input system ............................................................ 9-3
Bit operations resulting from input ..................................................... 9-4
Handling of Device Information in SGL .............................................. 9-5
Input data discrimination .................................................................... 9-6
Sample Program ................................................................................... 9-8
Library Functions Used in the Sample Program.................................. 9-11
Sprite functions ................................................................................ 9-11
Other functions ................................................................................ 9-12
Supplement. SGL Library Functions Covered in this Chapter ............ 9-12
Event Control............................................................. 10-1
Structure of Events.............................................................................. 10-2
Event processing ............................................................................. 10-2
Event structures ............................................................................... 10-3
Event lists ........................................................................................ 10-4
Event Processing Using SGL Functions ............................................. 10-5
Event initialization ............................................................................ 10-5
Creating an Event List ..................................................................... 10-5
Event format .................................................................................... 10-6
Event execution ............................................................................... 10-7
Changing the Event List ...................................................................... 10-8
Adding events .................................................................................. 10-8
Event insertion ................................................................................. 10-8
background image

5
Event deletion .................................................................................. 10-9
Changing the event list during event execution ............................... 10-9
Extending the User Area ................................................................... 10-11
Extending a user area with a work area ........................................ 10-11
Extending the user area with event areas ..................................... 10-13
Cautions Concerning Event Processing ............................................ 10-14
Flow of Event Processing.................................................................. 10-15
Example of Event Usage ................................................................... 10-16
Supplement. SGL Library Functions Covered in this Chapter .......... 10-20
Mathematical Operation Functions ..........................11-1
General Mathematical Operation Functions ........................................ 11-2
Trigonometric Functions ...................................................................... 11-3
Special Operation Functions ............................................................... 11-4
Supplement. SGL Library Functions Covered in this Chapter ............ 11-5
[Demonstration Program C: Walking Akira]
demo_C .................................................................... D-C-1
CD-ROM Library ........................................................ 12-1
The CD-ROM Library .......................................................................... 12-2
Accessing CD-ROM ............................................................................ 12-3
Logical Structure of CD-ROM .......................................................... 12-3
Loading files .................................................................................... 12-4
Partitioned file loading ..................................................................... 12-8
Read-ahead function ..................................................................... 12-11
CDDA file playback ........................................................................ 12-16
General Information ....................................................................... 12-20
CD Library Functions ........................................................................ 12-21
CDHN File handle .......................................................................... 12-21
CDKEY Key used to classify sector data ....................................... 12-21
CDBUF Loading area information .................................................. 12-22
Sint32 clCdInit (Sint32 nfile, void *work) Initialization .................... 12-22
Sint32 clCdChgDir (Sint8 *pathname) Change directory ............... 12-23
CDHN clCdOpen (Sint8 *pathname, CDKEY key[])) Open file ...... 12-23
Sint32 slCdLoadFile (CDHN cdhn, CDBUF buf[]) Load file ........... 12-23
Sint32 slCdTrans (CDHN cdhn, CDBUF buf[],
Sint32 ndata[]) Stream transfer .................................................. 12-23
Bool slCdResetBuf (CDHN cdhn, CDKEY *key)
Reset transfer area .................................................................... 12-23
background image

6
Sint32 slCdAbort (CDHN cdhn) Interrupt loading .......................... 12-24
Sint32 slCdPause (CDHN cdhn) Pause loading ............................ 12-24
Sint32 slCdGetStatus (CDHN cdhn, Sint32 ndata[]) Get status .... 12-24
Error Codes ................................................................................... 12-25
Backup Library .......................................................... 13-1
Features of the Backup Library ........................................................... 13-2
Devices ............................................................................................ 13-2
Files ................................................................................................. 13-3
Library expansion ............................................................................ 13-3
Basic Flow of Processing .................................................................... 13-4
Sample Program ................................................................................. 13-5
Supplement. Backup Library functions ................................................ 13-8
Sound Library ............................................................ 14-1
Sound Control Overview ..................................................................... 14-2
Sound Driver Setup ............................................................................. 14-3
Sound driver setup and MC68000 startup ....................................... 14-3
Sound data setup............................................................................. 14-4
Background music playback ............................................................ 14-4
Sound effect output.......................................................................... 14-5
Outputting sound effects using the PCM sound source ................... 14-5
Functions that affect sound output as a whole................................. 14-6
Memory Map ....................................................................................... 14-7
Sample Program ................................................................................. 14-8
Sample program for playback test of PCM sound source .............. 14-14
Supplement. Sound Library Functions Appearing in This Chapter ... 14-17
background image

7
Table of Figures and Tables
Figures
Fig 1-1
Flow of Programming Work ................................................ 1-2
Fig 1-2
Environment Variable Settings ........................................... 1-3
Fig 1-3
Trace from the Source Program ......................................... 1-7
Fig 1-4
Angles as Represented in ANGLE Format ......................... 1-8
Fig 1-5
Arrangement of Matrix Values in Memory........................... 1-9
Fig 1-6
Coordinate System Used in the SEGA Saturn System ...... 1-9
Fig 2-1
Examples of General Polygons .......................................... 2-2
Fig 2-2
Examples of Polygons in the SEGA Saturn System ........... 2-3
Fig 2-3
Drawing Model Based on "polygon.c" ................................. 2-6
Fig 2-4
Parameter Data String Creation Procedure ........................ 2-7
Fig 2-5
"PDATA PD_<label name>" Parameters ............................ 2-8
Fig 2-6
Drawing Model Based on Parameters in List 2-3 ............. 2-10
Fig 3-1
Light Source Models ........................................................... 3-2
Fig 3-2
Shadow Modeling ............................................................... 3-2
Fig 4-1
Coordinate System Used in the SEGA Saturn System ...... 4-2
Fig 4-2
Screen Coordinate System................................................. 4-2
Fig 4-3
Projection Concepts ........................................................... 4-3
Fig 4-4
Projection Surface in SGL .................................................. 4-3
Fig 4-5
Perspective Angle Concept ................................................ 4-4
Fig 4-6
Differences in the Image Caused by Perspective Angle ..... 4-4
Fig 4-7
Display Level ...................................................................... 4-5
Fig 4-8
Effects of Various Transformation Operations on
an Object ............................................................................ 4-8
Fig 4-9
Differences Resulting from Sequence of
Transformations ................................................................ 4-17
Fig 4-10
2D Clipping Examples ...................................................... 4-18
Fig 4-11
Definition of Display Region by 3D Clipping ..................... 4-19
Fig 4-12
Example of 3D Clipping .................................................... 4-20
Fig 4-13
The Window Concept ....................................................... 4-21
Fig 4-14
Meanings of the slWindow Parameters ............................ 4-22
Fig 4-15
Differences in an Image Caused by CENTER_X and
CENTER_Y ...................................................................... 4-23
Fig 4-16
Resetting the Default Window .......................................... 4-23
Fig 4-17
Example of Object Display Using Windows ...................... 4-24
Fig 4-18
Extent of Effects of Window Settings ................................ 4-27
Fig A-1
Depiction of Movement of Cube in Demo Program A .... D-A-1
Fig 5-1
The General Matrix Concept and Example of a Matrix
Operation ............................................................................ 5-2
Fig 5-2
Stack Conceptual Model..................................................... 5-3
Fig 5-3
Conceptual Model of Hierarchical Structures ..................... 5-4
Fig 5-4
Example of Shifting Objects without a Hierarchical
Structure ............................................................................. 5-4
background image
8
Fig 5-5
Example of Shifting Objects with a Hierarchical Structure.... 5-5
Fig B-1
Representation of Joints Using a Hierarchical Structure . D-B-1
Fig B-2
Conceptual Model of Demo Program B .......................... D-B-1
Fig 6-1
Conceptual Model of the Camera ....................................... 6-3
Fig 6-2
Differences in an Image Due to the Angle Parameter ........ 6-3
Fig 7-1
Z Sort Representative Points.............................................. 7-5
Fig 7-2
Differences in Interrelationships Due to the
Representative Points ........................................................ 7-5
Fig 7-3
Actual Screen Image .......................................................... 7-6
Fig 7-4
Texture Mapping ................................................................. 7-7
Fig 7-5
Special Texture Characteristic 1 ......................................... 7-8
Fig 7-7
Texture Distortion ............................................................... 7-9
Fig 7-8
Gouraud Shading ............................................................. 7-14
Fig 8-1
Example of Using a Scroll .................................................. 8-1
Fig 8-2
Screen Configuration Example ........................................... 8-2
Fig 8-3
Scroll Screen Configuration Units ....................................... 8-3
Fig 8-4
Example of Using the Function "slInitSystem" .................... 8-5
Fig 8-5
VRAM Address Map ........................................................... 8-8
Fig 8-6
Restriction on Storage of Pattern Name Data in
VRAM Banks ...................................................................... 8-9
Fig 8-7
ASCII Scroll Data Storage Area ........................................ 8-10
Fig 8-8
Color RAM Address Map .................................................. 8-11
Fig 8-9
Character Patterns ........................................................... 8-14
Fig 8-10
Pattern Name Data Concept ............................................ 8-16
Fig 8-11
Page Image ...................................................................... 8-18
Fig 8-12
"slPageNbg0 to 3", "slPageRbg0" Parameter
Setting Example ............................................................... 8-19
Fig 8-13
Plane Image ..................................................................... 8-20
Fig 8-14
Map Image ....................................................................... 8-21
Fig 8-15
RGB Color Mode Sample (RGB_Flag) ............................. 8-27
Fig 8-16
Relationship between the Display Position and the
Center of Rotation ............................................................ 8-28
Fig 8-17
Multiple Scroll Screen Registration................................... 8-29
Fig 8-18
Scroll Display Position Concept ........................................ 8-33
Fig 8-19
Scroll Wraparound Processing ......................................... 8-33
Fig 8-20
Scroll Enlargement and Reduction ................................... 8-38
Fig 8-21
Rotating Scroll Movement ................................................ 8-41
Fig 8-22
Scroll Rotation Concept .................................................... 8-42
Fig 8-23
Actual Operation of Scroll Rotation .................................. 8-42
Fig 8-24
slKtableRA, RB Parameter Substitution Values (mode) ... 8-47
Fig 8-25
ASCII Scrolls .................................................................... 8-50
Fig 8-26
Conceptual Model of Transparency Setting ...................... 8-53
Fig 8-27
slColorCalc Substitution Values (flag) .............................. 8-56
background image
9
Fig 8-28
Priority .............................................................................. 8-61
Fig 8-29
Relative Priority When the Same Priority Numbers
Are Assigned .................................................................... 8-61
Fig 8-30
Displaying Text and Numeric Values ................................ 8-64
Fig 9-1
Example Input Device (Saturn Pad) ................................... 9-2
Fig 9-2
Input Status Bit String for the Saturn Pad (shown as 16 bits) ... 9-4
Fig 9-3
Changes in the Input Status Bit String (Saturn Pad) .......... 9-4
Fig 9-4
PerDgtInfo Structure Definition ........................................... 9-5
Fig 9-5
Assignment Data #define Values (Saturn Pad) .................. 9-6
Fig 9-6
Pad Assignments (for PER_DGT_A) .................................. 9-6
Fig 9-7
Checking the Input Status by Using the Assignment Data ... 9-7
Fig 9-8
"slDMAXCopy" Parameter Substitution Values (mode) .... 9-12
Fig 10-1
The Event Concept ........................................................... 10-2
Fig 10-2
EVENT Structure .............................................................. 10-3
Fig 10-3
Event List Structure .......................................................... 10-4
Fig 10-4
Creating an Event List ...................................................... 10-5
Fig 10-5
Event Format .................................................................... 10-6
Fig 10-6
Structure of an Event ........................................................ 10-6
Fig 10-7
Event Execution ............................................................... 10-7
Fig 10-8
Adding Events .................................................................. 10-8
Fig 10-9
Event Insertion ................................................................. 10-8
Fig 10-10
Event Deletion .................................................................. 10-9
Fig 10-11
Changing the Event List During Execution ....................... 10-9
Fig 10-12
WORK Structure ............................................................. 10-11
Fig 10-13
Work Area Chaining........................................................ 10-12
Fig 10-14
Using the Event RAM Area to Extend a User Area ......... 10-13
Fig 10-15
Incorrect Event Operations ............................................. 10-14
Fig 11-1
Model of Trigonometric Functions .................................... 11-3
Fig 11-2
Model of "slAtan" .............................................................. 11-3
Fig C-1
Akira's Hierarchical Structure ........................................... 12-1
Fig 12-1
CD-ROM Access Flow Chart ............................................ 12-3
Fig 12-2
Sector Structure ............................................................... 12-4
Fig 12-3
CD Buffer ........................................................................ 12-11
Fig 12-4
Internal Structure of CD-ROM Library ............................ 12-20
Fig 13-1
Device Configuration ........................................................ 13-2
Fig 14-1
Sound Driver System Configuration ................................. 14-2
Fig 14-2
Sound Control Procedure ................................................. 14-3
Fig 14-3
Sound Data Setup Example ............................................. 14-4
Fig 14-4
PCM-type Structure Data ................................................. 14-6
Fig 14-5
Sound CPU Memory Map ................................................. 14-7
Fig 14-6
Sample Program Data File ............................................... 14-8
background image

10
Tables
Table 1-1
Examples of Numeric Type Conversion Macros ................. 1-9
Table 2-1
SGL Library Functions Covered in this Chapter ............... 2-12
Table 3-1
SGL Library Functions Covered in this Chapter ................. 3-6
Table 4-1
Display Level Substitution Values (level) ............................ 4-5
Table 4-2
Effect of Scaling Parameter on Object ............................. 4-14
Table 4-3
SGL Library Functions Covered in this Chapter ............... 4-28
Table 5-1
SGL Library Functions Covered in this Chapter ................. 5-9
Table 6-1
SGL Library Functions Covered in this Chapter ................. 6-6
Table 7-1
Plane (Front-Back Attribute) ............................................... 7-3
Table 7-2
Z Sort Specification ............................................................ 7-5
Table 7-3
Differences between Texture Mapping in the SEGA
Saturn System and Texture Mapping in General
Computer Graphics ............................................................ 7-7
Table 7-4
Modes ............................................................................... 7-17
Table 7-5
Dir ..................................................................................... 7-18
Table 7-6
Options ............................................................................. 7-19
Table 7-7
SGL Library Functions Covered in this Chapter ............... 7-19
Table 8-1
Screen Modes .................................................................... 8-4
Table 8-2
"slInitSystem" Parameter Substitution Example
(TV_MODE) ........................................................................ 8-5
Table 8-3
Scroll Screens .................................................................... 8-6
Table 8-4
Color RAM Mode .............................................................. 8-11
Table 8-5
slColRAMMode Parameter Substitution Values ............... 8-12
Table 8-6
Scroll Functions List ......................................................... 8-13
Table 8-7
Number of Character Colors............................................. 8-14
Table 8-8
Parameter Substitution Values for slCharNbg0 to 3
and slCharRbg0 ............................................................... 8-15
Table 8-9
Scroll Screen Restrictions Due to Number of
Character Colors .............................................................. 8-15
Table 8-10 Pattern Name Data Sizes ................................................. 8-17
Table 8-11 slPageNbg0 to 3, Rbg0 Parameter Substitution
Values (data_type) ............................................................ 8-18
Table 8-12 "slPlaneNbg0 to 3" and "slPlaneRA,RB" Parameter
Substitution Values (plane_size) ...................................... 8-20
Table 8-13 Scroll Screen Enlargement/Reduction Ranges ................ 8-22
Table 8-14 slZoomModeNbg0,1 Substitution Values (zoom_mode) ... 8-22
Table 8-15 slRparaMode Parameter Substitution Values ................... 8-23
Table 8-16 slCurRpara Substitution Values ........................................ 8-24
Table 8-17 Screen Overflow Processing Parameter Substitution
Values (over_mode) ......................................................... 8-25
Table 8-18 Scroll Registration Parameter Substitution Values
(disp_bit) ........................................................................... 8-29
background image

11
Table 8-19 "slScrDisp" Parameter Substitution Value List (mode) ..... 8-31
Table 8-20 Enlargement/reduction range depending on the
reduction setting ............................................................... 8-38
Table 8-21 "slScrTransparent" Parameter Substitution Values
(trns_flag) ......................................................................... 8-53
Table 8-22 slColorCalcOn Parameter Substitution Values (flag) ........ 8-56
Table 8-23 slLineColDisp Parameter Substitution Values (flag) ......... 8-58
Table 8-24 "slColOffsetOn", "slColOffsetBUse" Parameter
Substitution Values (flag) ..................................................... 60
Table 8-25 Priority of Each Screen in the Default State ..................... 8-61
Table 8-26 Difference Between "slPrintHex" and "slDispHex" ............ 8-65
Table 8-27 SGL Library Functions Covered in this Chapter (1) .......... 8-68
Table 8-28 SGL Library Functions Covered in this Chapter (2) .......... 8-69
Table 8-29 SGL Library Functions Covered in this Chapter (3) .......... 8-70
Table 8-30 User-Defined Functions Covered in this Chapter ............. 8-70
Table 9-1
List of Input Devices ........................................................... 9-2
Table 9-2
Peripheral Data Format of the Saturn Pad ......................... 9-3
Table 9-3
SGL Library Functions Covered in this Chapter ............... 9-12
Table 10-1 SGL Library Functions Covered in this Chapter ............. 10-20
Table 11-1 Examples of value notation using each notation method . 11-4
Table 11-2 SGL Library Functions Covered in this Chapter ............... 11-5
Table 12-1 Error Codes .................................................................... 12-25
Table 13-1 Device List ........................................................................ 13-2
Table 13-2 Backup Library Functions ................................................. 13-8
Table 14-1 Sound Driver Functions Appearing in This Chapter ........ 14-17
Lists
List 2-1
for sample_2_2: Polygon Drawing Subroutine ................... 2-4
List 2-2
for polygon.c: Polygon Parameters .................................... 2-6
List 2-3
for polygon.c: Cubic Polygon Parameters .......................... 2-9
List 3-1
sample_3_2: Changes in Object Faces due to
Movement of Light Source.................................................. 3-4
List 4-1
sample_4_2: Changes in Image Caused by
Perspective Angle ............................................................... 4-6
List 4-2
sample_4_3_1: Single-Axis Rotation Routine for a Cube... 4-9
List 4-3
sample_4_3_2: Two-Axis Rotation Routine for a Cube .... 4-11
List 4-4
sample_4_3_3: Parallel Shift Routine for a Cube ............. 4-12
List 4-5
sample_4_3_4: Enlargement/Reduction Routine
for a Cube ......................................................................... 4-14
List 4-6
sample_4_5: Example of Object Display Using Windows .. 4-25
List 4-7
polygon_c: Polygon Attributes Concerning
Window Display ................................................................ 4-27
background image

12
List A-1
demo_A: Demonstration Program A ...............................D-A-2
List 5-1
sample_5_2: Hierarchical Matrix Definition ........................ 5-6
List B-1
demo_B: Animation Using Hierarchical Structures ........ D-B-2
List 6-1
sample_6_3: Camera Movement ....................................... 6-4
List 7-1
Attribute Data ..................................................................... 7-2
List 7-2
sample_7_2: main.c ........................................................... 7-3
List 7-3
sample_7_2: Polygon.c ...................................................... 7-4
List 7-4
sample_7_4: main.c ......................................................... 7-10
List 7-5
sample_7_4: texture.c ...................................................... 7-11
List 7-6
sample_7_4: polygon.c..................................................... 7-12
List 7-7
sample_7_6: main.c ......................................................... 7-15
List 7-8
sample_7_6: polygon.c ..................................................... 7-16
List 8-1
#define Values for the Page Setting Parameters .............. 8-19
List 8-2
sample_8_8_1: Horizontal Scroll Movement .................... 8-34
List 8-3
sample_8_8_2: Horizontal and Vertical Scroll
MovementL ....................................................................... 8-36
List 8-4
sample_8_8_3: Scroll Enlargement/Reduction ................ 8-39
List 8-5
sample_8_9_1: Scroll 2D Rotation ................................... 8-43
List 8-6
sample_8_9_2: 3D Rotation ............................................. 8-48
List 8-7
sample_8_10_1: ASCII Scrolls ......................................... 8-51
List 8-8
sample_8_10_2: Transparent Code Control ..................... 8-54
List 8-9
for sample_8_11: Scroll Display Priority ........................... 8-62
List 8-10
sample_8_12: Text and Numeric Value Display .............. 8-66
List 9-1
sample_9_1: Input Test (main.c) ........................................ 9-8
List 10-1
sample_10: Event Processing (main.c) .......................... 10-16
List 10-2
sample_10: Event Processing (sample.c) ...................... 10-17
List 12-1
Sample Program 1 (File loading sample_cd1/main.c) ...... 12-7
List 12-2
Sample Program 2 (Partitioned file loading
sample_cd2/main.c) ....................................................... 12-10
List 12-3
Sample Program 3 (Read-ahead sample_cd3/main.c)... 12-14
List 12-4
Sample Program 4 (CDDA file playback
sample_cd4/main.c) ....................................................... 12-18
List 13-1
Sample Program .............................................................. 13-6
List 14-1
sampsnd1: Background Music and Sound Effect
Playback Test ................................................................... 14-8
List 14-2
sampsnd2: PCM Sound Source Playback Test .............. 14-14
Flow Charts
Flow Chart 2-1
sample_2_2: Polygon Drawing Flow Chart ................ 2-5
Flow Chart 3-1
sample_3_2: Flow Chart for Light Source Movement .. 3-5
Flow Chart 4-1
sample_4_2: Flow Chart for Changes in Image
Caused by Perspective Angle .................................... 4-7
background image
13
Flow Chart 4-2
sample_4_3_1: Flow Chart for Single-Axis Rotation
Routine for a Cube ................................................... 4-10
Flow Chart 4-3
sample_4_3_3: Flow Chart for Parallel Shift for
a Cube ..................................................................... 4-13
Flow Chart 4-4
sample_4_3_4: Flow Chart for
Enlargement/Reduction for a Cube .......................... 4-15
Flow Chart 4-5
sample_4_5: Flow Chart for Window Display .......... 4-26
Flow Chart A-1
sample_1_6: Flow Chart for Demonstration
Program A .............................................................. D-A-3
Flow Chart 5-1
sample_5_2: Flow Chart for Hierarchical Matrix
Definition .................................................................... 5-7
Flow Chart B-1 demo_B: Flow Chart for Hierarchical Structures ... D-B-3
Flow Chart 6-1
sample_6_3: Flow Chart for Camera Movement ....... 6-5
Flow Chart 8-1
Flow of Scroll Function Settings ............................... 8-26
Flow Chart 8-2
Flow of Operations up to Scroll Drawing .................. 8-32
Flow Chart 8-3
sample_8_8_1: Horizontal Scroll Movement ............ 8-35
Flow Chart 8-4
sample_8_8_2: Horizontal and Vertical
Scroll Movement ...................................................... 8-37
Flow Chart 8-5
sample_8_8_3: Scroll Enlargement/Reduction ........ 8-40
Flow Chart 8-6
sample_8_9_1: Scroll 2D Rotation........................... 8-44
Flow Chart 8-7
3D Rotation Operation Procedure Using the
current Matrix ........................................................... 8-46
Flow Chart 8-8
sample_8_9_2: 3D Rotation .................................... 8-49
Flow Chart 8-9
sample_8_10_1: ASCII Scrolls................................. 8-52
Flow Chart 8-10 sample_8_10_2: Transparent Code Control ............ 8-55
Flow Chart 8-11 Flow of Color Calculation Processing ...................... 8-57
Flow Chart 8-12 Flow of Line Color Screen Processing ..................... 8-59
Flow Chart 8-13 sample_8_11: Scroll Display Priority ........................ 8-63
Flow Chart 8-14 sample_8_12: Text and Numeric Value Display ....... 8-67
Flow Chart 9-1
sample_9_1: Input Test Flow Chart .......................... 9-10
Flow Chart 10-1 Flow of Event Processing ...................................... 10-15
Flow Chart 10-2 sample_10: Main Loop........................................... 10-16
Flow Chart 10-3 sample_10_1: Event Execution Contents .............. 10-19
Flow Chart C-1 Main Process ........................................................... 12-2
Flow Chart C-2 Main Processing ...................................................... 12-3
Flow Chart 12-1 Sample Program 1 (File loading sample_cd1/main.c) .12-6
Flow Chart 12-2 Sample Program 2 (Partitioned file loading
sample_cd2/main.c) ................................................. 12-9
Flow Chart 12-3 Sample Program 3 (Read-ahead
sample_cd3/main.c) ............................................... 12-13
Flow Chart 12-4 Sample Program 4 (CDDA file playback
sample_cd4/main.c) ............................................... 12-17
Flow Chart 13-1 Backup Library Sample Program ............................. 13-5
background image
Flow Chart 14-1 sampsnd1: Background Music and Sound Effect
Playback Test ......................................................... 14-13
Flow Chart 14-2 sampsnd2: PCM Sound Source Playback Test ...... 14-16
background image

Programmer's Tutorial
1
SEGA 3D Game Library
The SEGA 3D Game Library (SGL) is a function library capable
of 3D graphics control that is provided for developers of software
for the SEGA Saturn system. Each function in the library
(especially the functions in the operation library), makes fast
processing possible, since they are based on algorithms de-
signed by programmers who are experts in the processing
capabilities of the Saturn system.
This chapter explains the procedure for software development
using the SEGA 3D Game Library, and also describes points
that need to be observed when using the SGL.
background image

1-2
Programmer's Tutorial / SEGA 3D Game Library
Flow of Programming Work
The following diagram illustrates the flow of programming work in SEGA Saturn software
development using the SGL.
Fig 1-1 Flow of Programming Work
Host machine
ICB
Target Box
Programming
(source listing creation)
Make
(execution file creation)
Loading execution program into
ICE (debugging)
Execution on target box
Host machine
The host machine is used for the programming work, compiling, debugging, etc.
Make
This step entails the creation of the execution format file, including the compiling work.
ICE
This device emulates the SH2, the main CPU in the SEGA Saturn system. The operation of the
program that was created can be checked by loading the execution program into the ICE.
Debugging
The debugger can be used during program loading, during execution, and at the source level.
Target box
This device can be connected to the ICE, and is functionally equivalent to the SEGA Saturn
system.
* For details on the use of the ICE or the debugger, refer to their respective manuals:
HITACHI E7000 SH7604 Emulator
SEGA SH7604 E7000 Graphical User Interface Software
background image


Programmer's Tutorial / SEGA 3D Game Library
1-3
Host machine settings
The following two points are essential for the host machine environment settings. These set-
tings either must be made in the ".cshrc" or ".tcshrc" scripts, or must be made in scripts of your
own creation.
1) Add a path for the debugger in the path environment variables.
Example:
set path=($path /usr/local/lib/sh2/GUI)
2) Set three environment variables for the SHC library path, the debugger help path, and the
ICE address.
Fig. 1-2 Environment Variable Settings
q Environment variables q
setenv
SHC_LIB
<library path>
setenv
SH76GIHOST
<IP address>
setenv
HELPPATH
<help path>
ICE settings
A number of initial settings are required in order to connect the ICE and the host machine, such
as the network ID and registering the host machine. This process is described below.
1) Connecting the ICE with a terminal
Eject the ICE floppy disk.
Set DIP switch S8 on the rear of the unit to "OFF." (Facing the rear of the unit, flipping the
switch to the left turns it off.)
Connect a notebook computer, etc., to the ICE via the RS-232C interface. (A CRT must be
connected to the E7000 side.)
Start up the terminal software on the personal computer.
* When using Wterm:
After making the various settings, press the [Control] + [GRAPH] + [S] keys simulta-
neously to complete the connection process. If the various settings have not been made,
it is necessary to coordinate the ICE and Wterm settings. For details on the ICE
settings, refer to page 29 of the ICE Emulator User's Manual.
2) Setting the IP address (network ID)
Once connection is successfully completed, the following message is displayed:
START ICE
S: START ICE
R: RELOAD & START ICE
B: BACK UP FD
F: FORMAT FD
L: SET LAN PARAMETER
T: START DIAGNOSTIC TEST
(S/R/B/F/L/T)?
After the message is displayed, inputting "L" causes the following message to appear:
IP ADDRESS = X.X.X.X
Input the address to be set. for example:
IP ADDRESS = X.X.X.X .123.456.78.987
background image


1-4
Programmer's Tutorial / SEGA 3D Game Library
After input is complete, turn off the power. The address setting process is now complete.
3) Registering the host machine
Connect the network.
Set DIP switch S8 on the rear of the unit to "ON." (Facing the rear of the unit, flipping the
switch to the right turns it on.)
Turn on the power for the ICE.
Execute the "telnet" command on the workstation. For example:
telnet 157.109.50.120
or,
telnet [host name|IP address]
When the message "(file name/return)?" is displayed, press [Return].
Input the following at the ":" prompt. A list of registered workstations will appear.
LAN_HOST;S
(It is also possible to input just "lh;s"; this will appear on the screen as "llhh;;ss".)
When "PLEASE SELECT NO?" is displayed, select the number (01 to 09) that you either
want to register a new host under or that you want to make a change to."
Input the host name (the name of the workstation that will control the ICE).
Ex.:
01 HOST NAME SUN214 ?SUNXXX
Host name of host machine to be used
Input the IP address of the host.
Ex.:
01 IP ADDRESS 157.109.50.14 ? 157.109.50.47
Host IP address
After all input is complete the following message appears:
PLEASE SELECT NO? . [RET]
Press the [ctrl] + []] (right square bracket) keys to terminate the "telnet" command.
When the "telnet>" prompt appears, input "quit".
Turn off the ICE power.
Insert the floppy disk in the ICE and restart the ICE.
The ICE setting process is now complete.
Setting up and executing the Make file
Make generates a series of commands to be executed by the Unix shell according to a file
(called a "Make file") that describes a series of procedures and rules. Because the Make com-
mand permits effective control of the relationships among related files, it eliminates, for ex-
ample, the need to recompile all of the source files if a change is made in just one of several
source files.
SGL uses its own special Make file. When the Make command is executed, the source program
groups specified in this file are compiled, so that the execution file is generated automatically.
* These Make files must be located in the same level of the directory hierarchy as the
source files.
background image


Programmer's Tutorial / SEGA 3D Game Library
1-5
When a user creates a new application, it is necessary to modify the Make file accordingly. For
details on the Make function and its format, consult one of the references available from other
sources.
Reference: make (Keigaku Shuppan; Andrew Olam and Steve Talbot)
Debugger startup and initial settings
The Hitachi E7000 ICE is controlled by software with a special graphical user interface (GUI).
This software is called "the debugger" in this manual. This section explains the procedure for
starting up the debugger and making the initial settings.
1) Turn on the power, first for the ICE, and then for the target box. (Reverse this sequence
when turning off the power.)
2) Creating the files needed for automation
Create the two files "gish" and "PRESET" in the current directory.
gish
gish76 PRESET
PRESET
HOST <machine host name> <log-in name> <password>
RS
G
Setting up these files makes it possible to automate the following tasks:
Setting the HOST NAME, USER NAME, and PASSWORD in the HOST dialog box.
Resetting the target
Because "gish" is executed as a shell script, first use the "chmed tx gish" to set the execution
authority.
3) Debugger startup
Input "gish" on the host machine and press [Return] to start up the debugger. During the
startup process, when the following message appears and the system waits for input, click
inside the window to enable key input and then press the [Return] key.
(file name/return)?
Once the target is reset and the initial screen is displayed, click on "STOP".
4) Loading the initial program
Type in "g400"; when the screen disappears, click "STOP".
5) Settings for development work (disabling interrupts)
From the VIEW menu, select REGISTER; the Register dialog box appears.
Input "000000f0" in the Status Register (SR), and click "ENTER".
* This setting is for development purposes, and is required only in order to use the
ICE; it is not required in the software to be actually released.
background image


1-6
Programmer's Tutorial / SEGA 3D Game Library
Loading and executing a program
This section describes how to load an execution program into the ICE by using the debugger
and then how to execute the program.
* If an initialization file like "PRESET" as described in the preceding section is not to
be used, select "HOST" from the FILE menu and enter the HOST NAME, USER
NAME, and PASSWORD in the HOST dialog box. It is also necessary to input "rs
[Return] g [Return]" in the debugger command area in order to reset the target box.
1) Select "PROGRAM FILE" from the LOAD submenu under the FILE menu, and input the
file path for the file name.
2) Click "LOAD".
The execution program is now loaded.
* If "tcsh" is used in the user log-in shell but "tcsh" is not registered in the "/etc/shells"
file in the host machine, FTP will not operate and the execution program will not be
loaded. For details, refer to a reference on FTP.
3) Select "GO" from the EXECUTION menu.
4) Clock in the START ADDRESS input field in the GO dialog box, input "6004000", select
"order" from the pull-down menu for the START MODE button, and then click "Done".
The execution program now begins executing.
Debugging
Displaying the source program
1) When "SOURCE DISPLAY" is selected from the VIEW menu, the SOURCE DISPLAY
dialog box appears.
2) Click on the name of the program that you wish to display; the program name is then high-
lighted.
* Each time the mouse button is clicked, the highlighted display area becomes larger;
continue until the desired lines, including the path name, are highlighted.
3) Click "DISPLAY". (Doing so while the source program is loading or executing will gener-
ate an error. Either wait until the program finishes loading or stop the execution of the
program so that the ICE is waiting for command input before clicking "DISPLAY".)
* To close the dialog box, click "CANCEL".
Trace
The trace function can be used to trace the execution of the source program one step at a time.
1) After program execution, either after having clicked "STOP" or with the source program
displayed as described above, double-clicking on the portion of the listing enclosed in the
border in the diagram below causes the first part of those lines to be highlighted.
background image

Programmer's Tutorial / SEGA 3D Game Library
1-7
Fig 1-3 Trace from the Source Program
Program
counter
Break
point
2) Clicking "SET" here creates a break point [P].
* A break point cannot be established on a line that does not have a "B" at the head of
the line.
3) When "GO" is selected from the EXECUTION menu, the program counter [PC>] advances
to the break point [P] and stops.
At this point, there are two methods for tracing execution of the program one step at a time.
STEP: When execution jumps to a subroutine, execution of each step of the subroutine is
also traced one step at a time.
STEP_OVER: When execution jumps to a subroutine, execution of the entire subroutine is
traced as a single step.
background image

1-8
Programmer's Tutorial / SEGA 3D Game Library
Notes on Using the Library
Values used in the library
Floating-point decimals are not supported in the SGL.
There are three variable types, each based on fixed-point decimals.
* Because conversion from floating-point decimals to fixed-point decimals in the form
of macro definition is supported, separate conversion by each individual is not re-
quired. (Refer to Table 1-1, "Examples of Numeric Type Conversion Macros.")
Fixed-point decimals: Used for values for coordinate positions and trigonometric functions
Type name: FIXED
The high-order 16 bits are the integer portion, and low-order 16 bits are the decimal portion, for
a total of 32 bits (signed)
Example: 16.5 is expressed as follows:
16.5 = 0x0010 8000
Decimal portion
Integer portion
Note: The "0x" at the head of the FIXED format indicates hexadecimal notation.
Angles: Used in all angular expressions, such as angle of rotation.
Type name: ANGLE
360
are represented by 16 bits.
Fig 1-4 Angles as Represented in ANGLE Format
270.00 : 0xC000
0.00 : 0x0000
22.50 : 0x1000
45.00 : 0x2000
90.00 : 0x4000
background image

Programmer's Tutorial / SEGA 3D Game Library
1-9
Matrices: Used for all matrix variables, such as conversion matrixes.
Type name: MATRIX
A 4-row x 3-column matrix in which the values are given in FIXED format (Refer to the fol-
lowing diagram for allocation in memory.)
Fig 1-5 Arrangement of Matrix Values in Memory
1 , 0 , 0
0 , 1 , 0
0 , 0 , 1
0 , 0 , 0
M00 , M01 , M02
M10 , M11 , M12
M20 , M21 , M22
M30 , M31 , M32
0x0001_0000 , 0x0000_0000 , 0x0000_0000
0x0000_0000 , 0x0001_0000 , 0x0000_0000
0x0000_0000 , 0x0000_0000 , 0x0001_0000
0x0000_0000 , 0x0000_0000 , 0x0000_0000
=
=
Store
a) Original matrix
c) Arrangement of matrix
values in memory
b) Matrix when converted to FIXED format
The table below lists the value conversion macros supported by SGL. SGL also supports a
number of additional macros for specific purposes. The macros supported by SGL are defined
in the header files "sgl.h" and "sl_def.h". (For details, refer to the "Structure Reference" in the
Reference Manual.)
Table 1-1 Examples of Numeric Type Conversion Macros
Variable type
Macro name
Macro contents
Usage
FIXED
toFIXED(p)
((FIXED)((p) * 65536.0))
Converts values to FIXED format
ANGLE
DEGtoANG(d)
((ANGLE)(8d) * 65536.0 / 360.0))
Converts DEG-type angular values to
ANGLE format
FIXED
POStoFIXED(X,Y,Z)
{toFIXED(x) , toFIXED(y) , toFIXED(z) }
Converts XYZ coordinates to FIXED
format
Note: The macros are defined in the include files "sgl.h" and "sl_def.h".
Note: The appropriate macros are used without notice in the sample programs in-
cluded in these manuals.
Coordinate system
The "right-hand" coordinate system is used in the SEGA Saturn system.
In addition, angles in the positive direction when a rotation matrix is used rotate to the right
from the axis.
Fig 1-6 Coordinate System Used in the SEGA Saturn System
Z
X
X
0
0
Y
Y
Positive
direction
When the positive direction on the Z axis
points into the screen, the positive direction
on the Y axis points to the obttom of the
screen, and the positive direction on the X
axis points to the right side of the screen.
The positive direction of rotation around
an axis is to the right.
a) Coordinate system used in the
Sega Saturn system
b) Positive direction of rotation
versus the Z axis
background image

Programmer's Tutorial
2
Graphics
This chapter describes the approach to polygons, a fundamental
concept in 3D graphics, and the method for setting up polygons
in SGL.
background image

2-2
Programmer's Tutorial / Graphics
Polygons
A polygon is defined by three or more vertices ("v1, v2, v3, v4, ... vn") on a single plane. The
polygon is the enclosed region that is obtained when v1 is connected to v2, v2 is connected to
v3, v3 is connected to v4, and so on, until at the end vn is connected to v1. In general, the
straight lines connecting the vertices are called "edges."
Fig 2-1 Examples of General Polygons
a) Polygon with three vertices
a) Polygon with four vertices
c) Polygon with 8 vertices
v1
v1
v1
v2
v2
v2
v3
v3
v3
v4
v4
v5
v6
v7
v8
Note: The " " are vertices, and the straight lines connecting them are edges.
Although any shape with three or more vertices is a polygon, in general, polygons with three or
four vertices are considered optimal. (SGL supports only polygons with four vertices.)
background image

Programmer's Tutorial / Graphics
2-3
Polygons in SGL
SGL supports only polygons with four vertices. As a result, it is not possible to express poly-
gons with three vertices or with five or more vertices. However, with SGL it is possible to draw
a polygon that appears to only have three vertices by defining a polygon in which two of the
four vertices have the same coordinates.
Edges are always drawn in the clockwise direction, without regard to the numbering of the
vertices.
Fig 2-2 Examples of Polygons in the SEGA Saturn System
v1
v1
v2
v2
v3
v3 = v4
v4
v1
v1
v4
v3 = v4
v3
v2
v2
Direction that edges are drawn in
a) When the four vertices are different
b) When two vertices have
the same coordinates
c) Sequence in which the edges
are drawn (four vertices)
d) Sequence in which the edges
are drawn (three vertices)
Note: The " " are vertices, and the straight lines connecting them are edges.
In the SEGA Saturn system, polygons are drawn as painted regions on the screen. The proce-
dure for drawing polygons is as follows:
1) Create list of coordinates for vertices.
2) Create list of faces of polygon.
3) Determine surface attributes for each polygon face.
4) Draw polygon on screen.
Using an actual drawing subroutine as a reference, the related functions and function parameters
are explained next.
background image

2-4
Programmer's Tutorial / Graphics
Polygon drawing subroutine
The library function "slPutPolygon" is used to actually draw a polygon with SGL. Although
the function draws the polygon using the specified parameters, the display position and various
transformation operations (rotation, parallel shift, and enlargement/reduction) conform with the
current matrix.
[void slPutPolygon(PDATA*pat);]
This function draws the polygon defined by the data.
For the parameters, insert the start address of the region where the polygon data table (con-
taining the polygon vertex data list, the number of vertices, the face list, the number of faces,
and the face attribute data) is stored.
For details on the parameters, refer to "Parameters required for drawing a polygon" in the
next section.
The following explanation is based on the sample program below.
In this sample program, after completing the preparations for drawing the polygon (initializa-
tion, setting of the coordinates and display angle, etc.), the hierarchical matrix concept (refer to
chapter 5, "Matrices") is used to determine the polygon's display position, display angle, en-
largement/reduction ratio (not used here), and other attributes; the polygon is then actually
drawn on the basis of that data.
The library function "slPutPolygon(&PD_DATA);" is used to draw the polygon. The
"&PD_DATA" within the parentheses is a variable that groups together all of the parameters
required in order to display the polygon, and is defined within the data file "polygon.c" (refer to
List 2-2, "polygon.c: Polygon Parameters").
List 2-1 for sample_2_2: Polygon Drawing Subroutine
/*-----------------------------------------------------*/
/*
Draw1Polygon
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA PD_PLANE1;
void main()
{
static ANGLE ang[XYZ];
static FIXED pos[XYZ];
slInitSystem(TV_320x224,NULL, 1);
ang[X]=ang[Y]=ang[Z]=DEGtoANG(0,0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(220.0);
slPrint("Sample program2.2",slLocate(9.2));
while(-1){
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
slPutPolygon(&PD_PLATE1);
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* system initialization */
/* initial angle substitution */
/* initial position substitution */
/* title display */
/* initial position setting */
/* initial angle setting */
/* polygon drawing function */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


Programmer's Tutorial / Graphics
2-5
Flow Chart 2-1 sample_2_2: Polygon Drawing Flow Chart
START
Initialize system
Set initial
object angle
Draw object
Place object
Set initial
object position
Call operation
matrix
Synchronize
with screen
Set object
display angle
Temporary storage of
environment matrix
LOOP
background image

2-6
Programmer's Tutorial / Graphics
Parameters required for drawing a polygon
The following listing is the parameter group used for drawing the polygon that is read by the
program as "polygon.c". By changing the data here, it is possible to change the shape of the
polygon, its size, the number of faces, its surface attributes, etc.
List 2-2 for polygon.c: Polygon Parameters
#include
"sgl.h"
POINT point_PLANE1[]={
POStoFIXED(-10.0,-10.0,0.0),
POStoFIXED( 10.0,-10.0,0.0),
POStoFIXED( 10.0, 10.0,0.0),
POStoFIXED(-10.0, 10.0,0.0),
};
POLYGON polygon_PLANE1[]={
NORMAL(0.0,1.0,0.0),VERTICES(0,1,2,3),
};
ATTRattribute_PLANE1[]={
ATTRIBUTE(Dual_Plane,SORT_CEN,No_Texture,C_RGB(31,31,31),NO_Gouraud,MESHoff,sprPolygon,No_Option),
};
PDATAPD_PLANE1={
point_PLANE1,sizeof(point_PLANE1)/sizeof(POINT),
polygon_PLANE1,sizeof(polygon_PLANE1)/sizeof(POLYGON),
attribute_PLANE1
};
/* include file containing various settings */
/* creation of vertex list */
/* vertex coordinates (XYZ array) */
/* creation of face list */
/* vertex number list selected for one face */
/* creation of face attributes list */
/* creation of data string for drawing function */
/* vertex list, number of vertices */
/* face list, number of faces */
/* face attribute list */
/* setting of normal vector (determines orientation of face */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Fig 2-3 Drawing Model Based on "polygon.c"
Y
X
v1
v0
v2
v3
Note: Because the right-handed coordinate system is used,
the positive direction of the Z axis points into the screen.
background image

Programmer's Tutorial / Graphics
2-7
Fig 2-4 Parameter Data String Creation Procedure
START
Create vertex list
Create face
attributes list
Create face list
Create parameter
data string
Pass data to the
drawing function
Vertex ID numbers, "0, 1, 2, 3, 4,...n", are
automatically assigned to the vertices in the
sequence in the vertex list, starting from the top.
For each face of the polygon, four points are
selected by their vertex numbers from the vertex
list and are then used to create the polygon face
list. In addition, when using light sources, etc.,
the normal vector for each face is also set.
The attributes for each polygon face are
determined in the order of the face list, starting
from the top. The attributes include not only the
polygon color, but also other settings such as
the surface processing method.
The number of vertices is calculated on the
basis of the vertex list, and the number of faces
is calculated on the basis of the face list, and
the results are added to a new list. This list is
passed to the drawing function as the polygon
parameters.
The polygon data creation procedure is explained below, based on the data string that is created.
[Vertex list creation: POINT point_<label name>[]]
This is the list of initial coordinates for the polygon vertices. An ID number, "0, 1, 2, 3,
4,...n", is automatically assigned to each vertex in the order they appear in the list, starting
from the top.
Variable name: POStoFIXED(vertex_x,vertex_y,vertex_z),
This variable shows the coordinates of each vertex. Floating-point decimals can be substi-
tuted for the coordinates by using the macro "POStoFIXED". ("POStoFIXED" is an SGL-
supported macro.)
[Face list creation: POLYGON polygon_<label name>[]]
This creates a list of the polygon faces and normal vectors on the basis of the vertex list.
Variable name: NORMAL (vector_x,vector_y,vector_z),
This variable defines the normal vector for each face. The normal vectors are used to indi-
cate the orientation of the polygon face, and consists of a unit vector that is perpendicular to
the polygon face.
The parameters consist of the XYZ values that express the orientation of the respective
normal vector, and the normal vector must always be specified as a unit vector.
Variable name: VERTICES (v1,v2,v3)
This is a list of which vertices in the polygon list are to be used to form the polygon face.
The number of selected vertices is always four. However, a three-sided polygon (a triangle)
can be displayed, but only if the third and fourth vertex numbers are the same.
background image

2-8
Programmer's Tutorial / Graphics
The vertex numbers have no relation to the sequence in which the vertices are connected by
the edges. The edges are always connected in the clockwise direction, starting from the first
vertex in the list.
[Face attribute list creation: ATTR attribute_<label name>[]]
This sets the polygon face attributes for each face in the sequence of the face list. For details
on the contents of the settings, refer to Chapter 7, "Polygon Face Attributes."
Variable name: ATTRIBUTE (plane, sort, texture, color, gouraud, mode, dir, option),
This variable sets the polygon face attributes. There are eight parameters: front/back deter-
mination, Z sorting, texture, color, gouraud processing, drawing mode, sprite reversal
processing, and options. (For details, refer to Chapter 7, "Polygon Face Attributes.")
[Drawing function data string parameter creation: PDATA PD_<label name>]
This creates the data structure used to pass the polygon data settings as parameters to the
library function "slPutPolygon".
Variable names: vertex list, number of vertices, face list, number of faces, and face
attribute list
These create the data string that is actually passed to "slPutPolygon".
Here, the number of vertices and the number of polygon faces are newly calculated on the
basis of information such as the vertex list, and are added to the parameter data string.
Fig 2-5 "PDATA PD_<label name>" Parameters
/* Vertex list */
/* Number of vertices */
/* Face list */
/* Number of faces */
/* Face attribute list */
PDATA PD_PLANE1 = {
point_PLANE1,
sizeof(point_PLANE1)/sizeof(POINT),
polygon_PLANE1,
sizeof(polygon_PLANE1)/sizeof(POLYGON),
attribute_PLANE1
};
Polygon Data Structure
background image

Programmer's Tutorial / Graphics
2-9
Combining Multiple Polygons
It is impossible to use just one polygon to express most shapes. This section explains the
method for creating data for objects consisting of multiple polygons.
Creating cubes: Sample _3_2
To create a cube, it is necessary to set up an object with eight vertices and six polygon faces as
the parameter values.
This can be expressed in SGL by changing the contents of the parameter setting data file
"polygon.c" (described earlier) in the manner shown below.
In the listing, first a list of the eight vertices of the cube is created, and then a list of the six
faces defined by these vertices is created. After determining the face attributes of each surface,
all of the data is stored in the parameter data string "PD_PLANE". When this data string is
passed to the drawing function "slPutPolygon" as the polygon parameters, a cube is drawn on
the screen.
List 2-3 shows an example of creating data from a cubic polygon.
List 2-3 for polygon.c: Cubic Polygon Parameters
#include "sgl.h"
POINT point_plane[]={
POStoFIXED(-15.0,-15.0,-15.0),
POStoFIXED( 15.0,-15.0,-15.0),
POStoFIXED( 15.0, 15.0,-15.0),
POStoFIXED(-15.0, 15.0,-15.0),
POStoFIXED(-15.0,-15.0, 15.0),
POStoFIXED(-15.0, 15.0, 15.0),
POStoFIXED( 15.0, 15.0, 15.0),
};
POLYGONpolygon_plane[]={
NORMAL(0.0,0.0,-1.0),
VERTICES(0,1,2,3),
NORMAL(1.0, 0.0, 0.0)
VERTICES(1, 4, 7, 2),
NORMAL(0.0, 0.0, 1.0),
VERTICES(4,5,6,7),
NORMAL(-1.0, 0.0, 0.0),
VERTICES(5,0,3,6),
NORMAL(0.0, -1.0, 0.0),
VERTICES(4,1,0,5),
NORMAL(0.0,1.0,0.0),
VERTICES(2,7,6,3),
};
ATTR attribute_plane[]={
ATTRIBUTE(Dual_Plane,SORT_MAX,No_Texture,C_RGB(31,31,31),No_Gouraud,MESHoff,sprPolygon,No_Option),
ATTRIBUTE(Dual_Plane,SORT_MAX,No_Texture,C_RGB(31,00,00),No_Gouraud,MESHoff,sprPolygon,No_Option),
ATTRIBUTE(Dual_Plane,SORT_MAX,No_Texture,C_RGB(00,31,00),No_Gouraud,MESHoff,sprPolygon,No_Option),
ATTRIBUTE(Dual_Plane,SORT_MAX,No_Texture,C_RGB(00,00,31),No_Gouraud,MESHoff,sprPolygon,No_Option),
ATTRIBUTE(Dual_Plane,SORT_MAX,No_Texture,C_RGB(31,31,00),No_Gouraud,MESHoff,sprPolygon,No_Option),
ATTRIBUTE(Dual_Plane,SORT_MAX,No_Texture,C_RGB(00,31,31),No_Gouraud,MESHoff,sprPolygon,No_Option),
};
PDATACUBE={
point_plane,
sizeof(point_plane)/sizeof(POINT),
polygon_plane,
sizeof(polygon_plane)/sizeof(POLYGON),
attribute_plane
};
/* creation of vertex list */
/* vertex coordinates (XYZ array) */
/* creation of face list */
/* setting of normal vector (determines orientation of face */
/* vertex number list selected for one face */
/* creation of face attributes list */
/* creation of data string for drawing function */
/* calculation of number of vertices */
/* calculation of number of polygon faces */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
background image


2-10
Programmer's Tutorial / Graphics
Fig 2-6 Drawing Model Based on Parameters in List 2-3
X
Y
v5
v6
v4
v7
v0
v3
v1
v2
Note: Because the right-handed coordinate system is used,
the positive direction of the Z axis points into the screen.
background image

Programmer's Tutorial / Graphics
2-11
The Polygon Distortion Problem
Sometimes a polygon may appear to be distorted. The distortion is frequently caused by calcu-
lation errors.
The fact that the polygon is originally specified as a three-dimensional object and is then sub-
jected to transformation operations and projected on a two-dimensional screen is also some-
times a factor.
One type of distortion in which a true polygon (a polygon in which all of the vertices are in the
same plane) can no longer be recognized occurs when a polygon is viewed "edge on," in which
case the polygon appears as a straight line.
background image

2-12
Programmer's Tutorial / Graphics
Supplement. SGL Library Functions Covered in this Chapter
The functions listed in the following table were explained in this chapter.
Table 2-1 SGL Library Functions Covered in this Chapter
Function type
Function name
Parameters
Function
void
slPutPolygon
PDATA*pat
Drawing polygons (according to parameter settings)
background image

Programmer's Tutorial
3
Light Sources
This chapter describes the method for setting up light sources in
SGL. Light sources can be used to create shadows for object
groups displayed with 3D graphics, making it possible to in-
crease the realism of images.
background image

3-2
Programmer's Tutorial / Light Sources
Light Sources
A description of a light source generally includes the following information:
1) Position of the light source
2) Intensity of the light
3) Color of the light
However, calculating all of this light source information and then using it accurately in drawing
an object requires a tremendous amount of time. Therefore, in SGL, out of all of the light
source information, only the effect of the direction of the light source is reflected in the drawing
of images.
Furthermore, the direction of the light is normally defined as being radiated from a single point,
but implementing this would also consume too much computing time. Therefore, in SGL, the
position of the light source is assumed to be infinitely far away, so that the light is treated as
always shining on an object from the same direction, regardless of the coordinates of the object.
Fig 3-1 Light Source Models
Light
source
Direction of light rays: radiant
Object
Object
Direction of light rays: fixed
b) Light source modeling in SEGA Saturn
Note: The intensity of the color of the polygon faces exhibits the ef fect of shadows
a) Normal light source modeling
Changes in object surfaces due to light sources are determined by the direction of the light rays
and the orientation of the normal vectors of each polygon surface. This modeling concept is
illustrated below.
Fig 3-2 Shadow Modeling
The color of the polygon faces changes according
to the angle of incidence of the light.
Colors are brighter the closer the angle of incidence
is to perpendicular, and are darker the closer the
angle of incidence is to horizontal.
The color is darkest when the angle of incidence is
negative and perpendicular
Brightest surface
Direction of light rays
Bright surface
Darkest surface
Shadowing on polygon faces due to light source
background image


Programmer's Tutorial / Light Sources
3-3
Setting up a Light Source
Use "slLight" to set up a light source with the SGL. The light source function only includes the
direction vector (light source vector) that indicates the direction of the light rays, and does not
include light intensity or color information.
[void slLight (VECTOR light);]
This function sets up the light source for the SGL.
For the parameters, substitute the VECTOR-type variable (light source vector) that indicates
the direction of the light rays. Light source intensity and color information is not included in
the parameters. In the SGL, light rays are defined as always coming from the direction
specified by the direction vector. In addition, if light source calculations are not turned on in
the object surface attributes, the shadows from the light source are not reflected in the image
even if a light source is set up. (For details, refer to Chapter 7, "Polygon Face Attributes.")
The color of polygon faces is determined by the angle of incidence of the light shining on the
surface. Colors are brighter the closer the angle of incidence is to perpendicular, and are darker
the closer the angle of incidence is to horizontal. The color is darkest when the angle of inci-
dence is negative and perpendicular.
Note: Cautions concerning the establishment of light sources
When a polygon has been subjected to several transformation operations, such as
scaling to the current matrix, the light source calculations may not be performed
properly.
This happens because the user uses matrix operations for calculating the light source
vector specified by the function "slLight". Therefore, when setting up the light source,
it is necessary to first initialize the current matrix.
Use either the "slPushUnitMatrix" function or the "slUnitMatrix" function to initialize
the current matrix.
[Bool slPushUnitMatrix (void)]
Allocates space for a user matrix in the stack and makes it the current matrix. The previous
current matrix is temporarily stored at the top of the stack.
[Bool slUnitMatrix (MATRIX mtptr)]
Makes the matrix specified by the parameter a unit matrix. Substitute the MATRIX-type
variable to be specified for the parameter.
If "CURRENT" is specified for the parameter, the matrix that is the target of conversion
becomes the current matrix, making it possible to initialize the current matrix.
For details on the current matrix and the matrix functions, refer to Chapter 5, "Matrices."
background image

3-4
Programmer's Tutorial / Light Sources
The following program "sample_3_2" demonstrates the changes in shadowing on the surfaces
of a cube suspended in space when the light source direction vector is changed.
List 3-1 sample_3_2: Changes in Object Faces due to Movement of Light Source
/*-----------------------------------------------------*/
/*
Cube & A Light Source
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATAPD_PLANE1;
void main()
{
static ANGLE ang[XYZ];
static FIXED pos[XYZ];
static FIXED light[XYZ];
static ANGLE tmp=DEGtoANG(0.0);
slInitSystem(TV_320x224,NULL,1);
ang[X]=DEGtoANG(30.0);
ang[Y]=DEGtoANG(45.0);
ang[Z]=DEGtoANG(0.0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(190.0);
light[X]=toFIXED(-1.0);
light[Y]=toFIXED(0.0);
light[Z]=toFIXED(0.0);
slPrint("Sample program3.2",slLocate(9.2);
while(-1){
slPushUnitMatrix();
{
slRotY(tmp);
slRotX(DEGtoANG(15.0));
slRotZ(DEGtoANG(15.0));
slCalcPoint(toFIXED(0.0),toFIXED(0.0),toFIXED(1.0),light);
}
slPopMatrix();
slLight(light);
tmp+=DEGtoANG(1.0);
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
slPutPolygon(&PD_PLATE);
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* screen mode and other settings */
/* initial setting of object angle */
/* initial setting of object position */
/* light source parameter setting */
/* title display */
/* light source parameter substitution */
/* Calculation of light source vector in terms of angles to each axis */
/* light source parameter substitution */
/* light source setup */
/* changing light source setting variables */
/* polygon drawing function */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


Programmer's Tutorial / Light Sources
3-5
Flow Chart 3-1 sample_3_2: Flow Chart for Light Source Movement
START
Initialize system
Set initial
object angle
Place object
Set initial
object position
Set object
display angle
Call operation
matrix
Draw object
Synchronize
with screen
Temporary allocation
of operation matrix
Set light source
Change light
source settings
background image

3-6
Programmer's Tutorial / Light Sources
Supplement. SGL Library Functions Covered in this Chapter
The functions listed in the following table were explained in this chapter.
Table 3-1 SGL Library Functions Covered in this Chapter
Function type
Function name
Parameters
Function
void
slLight
VECTOR light
Light source vector setting
Bool
slPushUnitMatrix
void
Store unit matrix in stack
void
slUnitMatrix
MATRIX mtptr
Convert specified matrix to unit matrix
background image

Programmer's Tutorial
4
Coordinate Transformation
This chapter explains the basic concepts of 3D graphics and the subroutines
used to implement those concepts. In addition, this chapter will primarily
cover the mathematical tool called "coordinate transformation." Although
the material in this chapter may be complex, since it will make frequent use
of unusual tools such as matrix operations, it is important to study and
understand this material thoroughly, since it covers the foundation of 3D
graphics.
Objects displayed through 3D graphics are generally defined by the follow-
ing four items:
Coordinate system:
Determines the positioning and orientation of
the object and the viewpoint.
Projection transformation:
Defines how an image will appear when
projected onto a surface.
Modeling transformation:
Defines movement, rotation, and enlargement/
reduction within the coordinate system.
Viewing transformation:
Defines the viewpoint and its movement. (For
details, refer to Chapter 6, "The Camera.")
In combination, these four elements make it possible to display an image in
3D on the monitor. In this chapter, the first three elements (but not viewing
transformation) will be explained in sequence, followed by a more detailed
explanation.
background image

4-2
Programmer's Tutorial / Coordinate Transformation
Coordinate System
In the SEGA Saturn system, a 3D coordinate system generally called the "right-handed coordi-
nate system" is used. In this system, the positive direction on the Z axis points into the screen,
the positive direction on the Y axis points to the bottom of the screen, and the positive direction
on the X axis points to the right side of the screen. The positive direction of rotation is clock-
wise around an axis.
Fig 4-1 Coordinate System Used in the SEGA Saturn System
0
0
Z
X
X
Y
Y
When the positive direction on the
Z axis points into the screen, the
positive direction on the Y axis
points to the bottom of the screen,
and the positive direction on the
X axis points to the right side of
the screen
The positive direction of rotation
around an axis is to the right.
Into screen
Positive direction
a) Coordinate system used
in the SEGA Saturn system
(right-hand system)
b) Positive direction of
rotation versus the Z axis
In addition, SGL also has a 2D coordinate system called the "screen coordinate system" that
corresponds with the resolution of the TV monitor and screen mode. Although this is primarily
used for scrolling and for handling 2D graphics, such as sprites, it is also used to set up win-
dows, as described "Windows."
Fig 4-2 Screen Coordinate System
Y
X
(0, 0)
(319, 223)
Monitor
Note: Although there are other resolutions this
coordinate system is usually used in 320
224
(horizontal
vertical) mode
background image

Programmer's Tutorial / Coordinate Transformation
4-3
Projection Transformation
This section explains how the coordinates are expressed on the screen and also explains the
projection setting method.
Projection with perspective
This section explains projection with perspective. After first establishing the viewpoint, the
illustrations below depict the results of projection when there is a cube placed perpendicular to
the line of sight on a line extending from that viewpoint.
Fig 4-3 Projection Concepts
Direction of line of sight
Object
Clipping plane: top
Clipping plane: bottom
Projection
surface
Projection surface
Object
: Points nearer to the viewpoint
: Points farther from the viewpoint
a) Projection with perspective (side view)
b) Projection with perspective (front view)
In projection with perspective, the image is defined as the image mapped onto a flat surface
called the "projection surface." The projection surface can be thought of as being similar to a
movie screen.
The points where the line segments connecting the viewpoint with the points of the object
intersect with the projection surface are where the points of the object are drawn. By perform-
ing this operation for all of the points of an object in a space, the space is drawn on the projec-
tion surface.
Fig 4-4 Projection Surface in SGL
Y
X
(0, 0)
(0, 223)
(319, 223)
(319, 0)
TV monitor
Projection surface
The monitor is represented as a collection of
dots extending 320 pixels in the horizontal
direction by 224 pixels in the vertical direction.
Images are represented by changing the
colors of these dots.
Aside from its virtual 3D space coordinate
system, SGL also has a 2D coordinate system
that corresponds with the monitor screen.
Note: In the diagram, 320
224 screen mode is depicted
The projection surface in the SGL is the TV monitor screen. After an object group located in a
virtual 3D space is projected with perspective, the image is mapped onto the screen coordinate
system and is then drawn on the TV monitor.
background image

4-4
Programmer's Tutorial / Coordinate Transformation
Viewing volume
The range of space projected onto the projection surface is called the "viewing volume."
In the case of the SGL, the parameters used to control the viewing volume are the perspective
angle and the display level.
These two parameters are described below.
1) Perspective angle
The perspective angle is the parameter that describes the spread in the horizontal direction of
the image to be projected on the projection surface.
If this volume is large, the density of the object projected on the projection surface becomes
high, and the image appears as if viewed through a fish-eye lens.
Note that the spread of the image in the vertical direction is determined not only by the perspec-
tive angle but also by the resolution as defined by the screen mode.
Fig 4-5 Perspective Angle Concept
Clipping boundary
Viewpoint
Display level
Projection
surface
Rear boundary
surface
Perspective angle: 60
Viewing volume
In the SGL, use the function "slPerspective" to change the projection with perspective settings.
[void slPerspective (ANGLE perspective_angle);]
By changing the function parameter, it is possible to control the volume of space that is
projected on the projection surface. Substitute the angle that determines the volume of space
to be projected (20 < angle < 160). If a value outside of the permitted range is inserted, an
overflow error will occur.
Fig 4-6 Differences in the Image Caused by Perspective Angle
a) When perspective angle is small
Viewpoint
Projection
surface
Clipping boundary
Direction of
line of sight
Object
Clipping boundary
Projection surface
Viewpoint
Projection
surface
Clipping boundary
Direction of
line of sight
Object
Clipping boundary
Projection surface
b) When perspective angle is large
Vertices that are closer to the
viewpoint.
Vertices that are farther from the
viewpoint.
background image

Programmer's Tutorial / Coordinate Transformation
4-5
2) Display level
The display level parameter determines the level to which the area behind the projection
surface is to be projected onto the projection surface.
Objects with the projection surface behind them are projected on the projection surface by
the same means as images far behind the projection surface.
The display level is set by using the function "slZdspLevel".
The display level is determined by the position of the dividing point between the viewpoint to
the projection surface beyond which objects are to be projected.
[void slZdspLevel (Uint16 level);]
Determines the display level of the viewing volume.
Substitute in the parameter the appropriate value from the following chart according to the
display level.
Table 4-1 Display Level Substitution Values (level)
Display level
1/2
1/4
1/8
Substitution value
1
2
3
The following diagram illustrates the display level concept.
Fig 4-7 Display Level
ScreenDist: Specifies the forward position of
the area in which projection is
actually performed. Value specifies
the number of divisions between the
projection surface and the viewpoint.
Rear
boundary
Projection area
(when ScreenDist = 1/2)
Projection surface
Viewpoint
Zlimit: Distance between ScreenDist
and the rear boundary
1/2
1/4
1/8
background image

4-6
Programmer's Tutorial / Coordinate Transformation
List 4-1 places a cube in the middle of the screen and demonstrates how changing the perspec-
tive angle over a range from 20 to 170 affects the appearance of the cube.
List 4-1 sample_4_2: Changes in Image Caused by Perspective Angle
/*-----------------------------------------------------*/
/*
Perspective Control
*/
/*-----------------------------------------------------*/
#include"sgl.h"
exterm PDATA PD_CUBE;
void main(){
static ANGLE ang[XYZ];
static ANGLE angper[XYZ];
static FIXED pos[XYZ];
static ANGLE tmp=DEGtoANG(90.0);
static ANGLE adang=DEGtoANG(0.5);
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program 4.2",slLocate(6,2));
ang[X]=DEGtoANG(30.0);
ang[Y]=DEGtoANG(45.0);
ang[Z]=DEGtoANG(0.0);
pos[X]=toFIXED(50.0);
pos[Y]=toFIXED(40.0);
pos[Z]=toFIXED(20.0);
slPrint("Perspective:",slLocate(4,5));
while(-1){
slPerspective(tmp)
slPrintHex(slAng2DEC(tmp),slLocate(18,5));
tmp+=adang;
if(tmp>DEGtoANG(160.0))
adang=DEGtoANG(-0.5)
if(tmp>DEGtoANG(20.0))
adang=DEGtoANG(0.5);
slPushMatrix();
{
FIXEDdz;
dz=slDivFX(slTan(tmp>>1),toFIXED(170.0));
slTranslate(pos[X],pos[Y],pos[Z]+dz);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
slPutPolygon(&PD_CUBE);
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* perspective transformation table setting */
/* draws polygon */
/* perspective transformation control variable modification*/
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


Programmer's Tutorial / Coordinate Transformation
4-7
Flow Chart 4-1 sample_4_2: Flow Chart for Changes in Image Caused by Per-
spective Angle
START
Initialize system
Set initial
object angle
Place object
Temporary allocation
of operation matrix
Set initial
object position
Set object
display angle
Call operation
matrix
Draw object
Synchronize
with screen
Perspective
transformation table
(20 - 170 )
Perspective transformation
table setting
Set light source
Light source
settings
background image

4-8
Programmer's Tutorial / Coordinate Transformation
Modeling Transformation
This section explains the placement and transformation of an object in a space. There are three
types of transformations that can be performed on an object: shift, rotation, and enlargement/
reduction.
By using these transformation operations, the object can be freely placed anywhere.
These manipulation operations are explained below, along with a sample program.
Fig 4-8 Effects of Various Transformation Operations on an Object
e) Enlargement: slScale (3.0, 1.0, 1.0)
Note: For the sake of convenience, the angles and variables are
shown in degrees and floating-point form.
Shift
Rotation
Mirror
image
Enlargement
a) Original object
c) Rotation: slRotZ (45.0)
b) Shift: slTranslate (1.0, 1.0, 0.0)
d) Mirror image: slScale (-1.0, 1.0, 1.0)
background image

Programmer's Tutorial / Coordinate Transformation
4-9
Object rotation
The library functions "slRotX", "slRotY", and "slRotZ" are used to rotate an object in a space.
Each function controls rotation around the axis corresponding to the last letter in the respective
function name.
Object rotation is implemented by cross multiplying the transformation matrix called the "rota-
tion matrix" with the coordinates of each vertex of the object.
[void slRotX (ANGLE angx);]
Rotates the object around the X axis. Substitute the rotation angle for the parameter.
[void slRotY (ANGLE angx);]
Rotates the object around the Y axis. Substitute the rotation angle for the parameter.
[void slRotZ (ANGLE angx);]
Rotates the object around the Z axis. Substitute the rotation angle for the parameter.
In list 4-2, the rectangular polygon drawn in list 2-1 in Chapter 2 is rotated around the Y axis
using the library function "slRotY".
Ry =
cos
0.0
sin
0.0
-sin
0.0
cos
0.0
0.0
1.0
0.0
0.0
List 4-2 sample_4_3_1: Single-Axis Rotation Routine for a Cube
/*-----------------------------------------------------*/
/*
Rotation of 1 Polygon[Y axis]
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA PD_PLANE1;
void main()
{
static ANGLE ang[XYZ];
static FIXED pos[XYZ];
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program 4.3.1",slLocate(9,2));
ang[X]=ang[Y]=ang[Z]=DEGtoANG(0,0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(220.0);
while(-1){
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
ang[Y]+=DEGtoANG(5.0);
slPutPolygon(&PD_PLANE1);
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* initial angle substitution */
/* initial position substitution */
/* display position setting */
/* display angle setting */
/* changing Y axis rotation */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image

4-10
Programmer's Tutorial / Coordinate Transformation
Flow Chart 4-2 sample_4_3_1: Flow Chart for Single-Axis Rotation Routine for a
Cube
START
Initialize system
Set initial
object angle
Draw object
Place object
Set initial
object position
Call operation
matrix
Synchronize
with screen
Set object
display angle
Temporary allocation
of operation matrix
Change display angle
on a single axis
List 4-3 rotates the rectangular polygon around 2 axes, X and Y.
Whether rotating around one axis, two axes, or three axes, the operation that is actually per-
formed is identical. By manipulating the angle in the rotation operation function corresponding
to each axis, the object is drawn with rotation added.
background image


Programmer's Tutorial / Coordinate Transformation
4-11
List 4-3 sample_4_3_2: Two-Axis Rotation Routine for a Cube
/*-----------------------------------------------------*/
/*
Rotation of 1 Polygon[X & Y axis]
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA PD_PLANE1;
void main()
{
static ANGLE ang[XYZ];
static FIXED pos[XYZ];
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program 4.3.2",slLocate(9,2));
ang[X]=ang[Y]=ang[Z]=DEGtoANG(0,0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(220.0);
while(-1){
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
ang[X]+=DEGtoANG(4.0);
ang[Y]+=DEGtoANG(2.0);
slPutPolygon(&PD_PLANE1);
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* initial angle substitution */
/* initial position substitution */
/* display position setting */
/* display angle setting */
/* changing X and Y axis rotation */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image

4-12
Programmer's Tutorial / Coordinate Transformation
Object shift
The library function "slTranslate" is used to shift an object with the SGL.
By substituting the amount of the shift in the X, Y, and Z axes versus the current position as the
parameters, it is possible to move an object to any coordinates within the 3D space.
[void slTranslate (FIXED tx, ty, tz);]
Shifts an object to the specified coordinates.
Substitute the defined coordinates or the amount of shift in the X, Y, and Z axes versus the
current position as the parameters.
List 4-4 uses the library function "slTranslate" to shift an object parallel to the X axis. The
value of sine is used to control the shift parameter. The change in the angle value "tmp" con-
trols the change in the value of the X coordinate.
Txyz =
1.0
0.0
0.0
tx
0.0
0.0
1.0
tz
0.0
1.0
0.0
ty
List 4-4 sample_4_3_3: Parallel Shift Routine for a Cube
/*-----------------------------------------------------*/
/*
Parallel Translation of 1 Polygon[X axis]
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
#define POS_Z
50.0
exterm PDATA PD_PLANE1;
void main()
{
static ANGLE ang[XYZ];
static FIXED pos[XYZ];
static ANGLE tmp=DEGtoANG(0.0);
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program 4.3.3",slLocate(9,2));
ang[X]=ang[Y]=ang[Z]=DEGtoANG(0,0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(220.0);
while(-1){
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
tmp+=DEGtoANG(5.0);
pos[X]=slMulFX(toFIXED(POS_Z),slSin(tmp));
slPutPolygon(&PD_PLANE1);
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* POS_Z macro definition */
/* screen mode setting */
/* program title display */
/* initial angle substitution */
/* initial position substitution */
/* display position setting */
/* display angle setting */
/* overwriting X coordinate */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


Programmer's Tutorial / Coordinate Transformation
4-13
Flow Chart 4-3 sample_4_3_3: Flow Chart for Parallel Shift for a Cube
START
Initialize system
Set initial
object angle
Draw object
Change parameter
value for parallel shift
Place object
Set initial
object position
Call operation
matrix
Change
coordinate value
Synchronize
with screen
Set object
display angle
Temporary allocation
of operation matrix
background image

4-14
Programmer's Tutorial / Coordinate Transformation
Object enlargement/reduction
The library function "slScale" is used to enlarge/reduce objects in a space in the SGL. The
scaling ratios along each axis are passed to the function as parameters.
[void slScale (FIXED sx, sy, sz);]
This function scales the object along each axis and then displays it.
Substitute a scaling value (any desired ratio) for each axis (X, Y, and Z) for the parameters.
The object changes according to the scaling ratio as shown in the following table.
Table 4-2 Effect of Scaling Parameter on Object
Parameter range
scale < 0.0
scale = 0.0
0.0 < scale < 1.0
scale = 1.0
1.0 < scale
Transformation result
Mirror image
Disappears
Reduced
Unchanged
Enlarged
Note: "Scale" refers to the scaling parameter.
Note: Changes in an object caused by the scaling parameter:
When the scaling value is "0.0," the object is drawn with zero thickness in the direction
of the axis for which that scaling value was specified.
If a negative scaling value is specified, the object is drawn as a mirror image in the
direction of the axis for which that scaling value was specified.
List 4-5 is an enlargement/reduction program that changes the scale ratio of the rectangular
polygon in the direction of the X and Y axes.
List 4-5 sample_4_3_4: Enlargement/Reduction Routine for a Cube
/*-----------------------------------------------------*/
/*
Expansion & Reduction of 1 Polygon[X&Y axis]
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA PD_PLANE1;
void main()
{
static ANGLE
ang[XYZ];
static FIXED
pos[XYZ];
static FIXED
sclx,scly,sclz,tmp=toFIXED(0.0);
static Sint16
flag=1;
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program 4.3.4",slLocate(9,2));
ang[X]=ang[Y]=ang[Z]=DEGtoANG(0,0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(220.0);
sclx=scly=sclz=toFIXED(1.0);
while(-1){
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
if(flag==1)tmp+=toFIXED(0.1);
else tmp-=toFIXED(0.1);
if(tmp>toFIXED(1.0))flag=0;
if(tmp<toFIXED(-1.0))FLAG=1;
slScale(sclx+tmp,scly-tmp,sclz);
slPutPolygon(&PD_PLANE1);
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* initial angle substitution */
/* initial position substitution */
/* initial scaling value substitution */
/* display position setting */
/* display angle setting */
/* routine that changes the scaling values */
/* scale setting */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


Programmer's Tutorial / Coordinate Transformation
4-15
Flow Chart 4-4 sample_4_3_4: Flow Chart for Enlargement/Reduction for a Cube
START
Initialize system
Set initial
object angle
Draw object
Enlarge/reduce
object
Reduce ratio
by 0.1
Increase ratio
by 0.1
flag = 0
flag = 1
Place object
Set initial
object position
Call operation
matrix
Synchronize
with screen
Set object
display angle
Temporary allocation
of operation matrix
No
No
No
Yes
Yes
Yes
flag = 1
Does ratio
= 2.0?
Does ratio
= 0.0?
background image

4-16
Programmer's Tutorial / Coordinate Transformation
Special Modeling Transformations
This section will introduce several somewhat special modeling transformation operations.
While the functions introduced here all add rotation to the object data, the parameter settings
differ from the rotation operation library function that was described earlier.
[void slRotXSC (FIXED sin, FIXED cos);]
This function adds rotation around the X axis by substituting sine and cosine values.
Substitute FIXED-type sine and cosine values for the respective parameters.
[void slRotYSC (FIXED sin, FIXED cos);]
This function adds rotation around the Y axis by substituting sine and cosine values.
Substitute FIXED-type sine and cosine values for the respective parameters.
[void slRotZSC (FIXED sin, FIXED cos);]
This function adds rotation around the Z axis by substituting sine and cosine values.
Substitute FIXED-type sine and cosine values for the respective parameters.
[void slRotAX (VECTOR vx, vy, vz, ANGLE anga);]
This function adds rotation around any axis that passes through the origin. (Specify the axis
with unit vector values.)
Substitute unit vector values (X, Y, and Z) that define the axis of rotation and also substitute
the angle of rotation.
The vector values that define the axis of rotation must define a unit vector. A unit vector is a
vector with a size of "1".
background image

Programmer's Tutorial / Coordinate Transformation
4-17
Differences that depend on the transformation sequence
In 3D graphics, the transformations represented by modeling transformations are performed by
using a transformation matrix. Therefore, if the transformation operations are not performed
with an awareness of the transformation sequence, the object may be drawn on the screen in an
unanticipated manner. In the following two series of diagrams, rotation and shift transformation
operations are performed on the object, but in different sequences. As a result, there is a great
difference in the final positioning of the object.
Fig 4-9 Differences Resulting from Sequence of Transformations
Note: For the sake of convenience, the angles and variables
are shown in degrees and floating-point form.
a) When the transformations are performed in the sequence rotation, shift
b) When the transformations are performed in the sequence shift, rotation
Rotate
slRotZ (45.0)
slTrans (4.0, 0.0, 0.0)
slTrans (4.0, 0.0, 0.0)
slRotZ (45.0)
Rotate
Shift
Shift
background image

4-18
Programmer's Tutorial / Coordinate Transformation
Clipping
Trimming off the portion of an object that extends beyond the display area (the area actually
projected on the projection surface) and not displaying that portion is called "clipping." In the
SGL, this concept is used to make it possible to set up windows on the projection surface.
This section will first explain the concept of clipping, and then will discuss how windows are
actually set up in the SGL.
2D clipping
We will first use 2D graphics examples to introduce the concept of clipping. In the case of 2D
graphics, an object switches between being displayed and not being displayed according to
whether it is inside or outside of a defined rectangular region. The examples below show how
an object is displayed, depending on its placement in or out of the rectangular display area.
Fig 4-10 2D Clipping Examples
Note: When projection surface bounded completely by the clipping boundary is the display area
Clipping boundary
Clipping boundary
Clipping boundary
Clipping boundary
Projection
surface
Projection
surface
Projection
surface
Projection
surface
Displayed
portion
Displayed portion
Displayed portion
Non-displayed portion
Non-displayed
portion
Non-displayed portion
a) When object is completely displayed
b) When object is extending over one boundary
c) When object is extending over more than
one boundary
d) When object is completely not displayed
As shown in the above diagrams, the object that is subject to clipping is either displayed or not
displayed, depending on whether it is inside or outside of the clipping area. In the above ex-
amples, when the object lies across a clipping boundary, the part of the object that is in the
display area is displayed, while the part that is outside the display area is not displayed.
Note: In certain cases, due to computing speed and drawing speed problems, whether
the object is displayed or not is determined by the percentage of the object that is in the
clipping area.
background image

Programmer's Tutorial / Coordinate Transformation
4-19
3D clipping
Normally, in 3D graphics, a "field of view" pyramid is determined by the perspective transfor-
mation matrix, with the region inside the pyramid defined as the display region and the region
outside the pyramid defined as the non-display region. Objects within the display region are
projected on the projection surface and are displayed on the monitor.
The "field of view" pyramid is an enclosed region of space (the viewing volume) bounded by
the following six planes:
Left side of field of view:
Clipping plane (determined by perspective angle)
Right side of field of view: Clipping plane (determined by perspective angle)
Top of field of view:
Clipping plane (determined by perspective angle and screen mode)
Bottom of field of view:
Clipping plane (determined by perspective angle and screen mode)
Front of field of view:
Front boundary surface (determined by the function "slZdspLevel")
Rear of field of view:
Rear boundary surface (determined by the parameter "Zlimit" in the
function "slWindow")
In addition, in the case of the SGL, it is also possible to add clipping planes. (For details, refer
to "Windows.")
Fig 4-11 definition of Display Region by 3D Clipping
c) Visible region (X-Y plane)
Viewing volume
Rear boundary surface of field of view
Projection surface
Display level
Viewpoint
Clipping boundary
The space enclosed by the projection surface,
the rear boundary surface, and the top, bottom,
left, and right clipping boundaries is the viewing
volume (display area).
Objects in the viewing volume undergo projection
transformation and are then projected on the
projection surface.
Viewing volume
Clipping plane
Rear boundary
surface of field
of view
Display level
Viewpoint
Viewing volume
Projection
surface
Clipping boundary
Projection surface
Viewpoint
a) Visible region
(three-dimensional
expression)
b) Visible region (Y-Z plane)
background image


4-20
Programmer's Tutorial / Coordinate Transformation
Fig 4-12 Example of 3D Clipping
d) Projected object after clipping
Clipping boundary
Projection
surface
Viewpoint
Viewing volume
Clipping boundary
Viewpoint
Projection surface
: Points nearer to projection sur face
: Points farther from projection sur face
Clipping boundary
Projection
surface
Center
Displayed region
Non-displayed region
a) Clipping (Y-Z plane)
b) Clipping (X-Y plane)
c) Actual object
background image

Programmer's Tutorial / Coordinate Transformation
4-21
Windows
In the SGL, the clipping concept is used to set up rectangular regions that limit display, called
"windows," on the projection surface. The display of objects can be switched on or off, de-
pending on whether they are inside or outside the window.
A maximum of two windows can be set up on one screen. Of these, one window is defined
from the start as the default window. This window is the same size as the projection surface
(the TV monitor), and can be set up again in the middle of the program.
Window concept
In the SGL, windows are defined as follows:
Fig 4-13 The Window Concept
Viewing volume
Window region
Viewpoint
Projection
surface
Window region
Rear boundary
surface of region
Viewing volume
Rear boundary surface
Window boundary
Clipping boundary
Window
Projection
surface
In the SGL, a window is defined as a rectangular region on the projection surface. In 3D terms,
a window is a region in the viewing volume that is projected onto a rectangular region on the
projection surface. (This corresponds to the darkly shaded portions of the diagrams above.) By
specifying a window, it is possible to determine whether or not an object is displayed according
to whether it lies within the window or outside the window.
The maximum window size is the same size as the projection surface.
Setting up a window in SGL
The library function "slWindow" is used to actually set up a window in the SGL. In addition, in
the SGL, a default window the same size as the projection surface and which can be reset is
already set up in the initial state (before slWindow has even been used).
[void slWindow (left, top, right, bottom, Zlimit, CENTER_X, CENTER_Y);]
The library function "slWindow" sets up a window region on the projection surface. Each
parameter sets the top-left and bottom-right screen coordinates of the window, the rear
boundary coordinates, and the screen coordinates that determine the direction of the line of
sight, respectively. The meaning of each parameter is explained in the following diagram.
background image

4-22
Programmer's Tutorial / Coordinate Transformation
Fig 4-14 Meanings of the slWindow Parameters
Note: "left", "top", "right", "bottom", "CENTER_X", and "CENTER_Y"
indicate X-Y coordinate values on the monitor.
Viewpoint
Projection
surface
(left, top, right, bottom)
Zlimimt
(CENTER_X, CENTER_Y)
(CENTER_X, CENTER_Y)
(319, 223)
Window boundary
Line of sight
Window
Projection
surface
(0, 0)
left
right
top
bottom
The parameters of the library function "slWindow" are defined below.
[Sint16 left, top, right, bottom]
These parameters specify the top-left and bottom-right screen coordinates of the window on
the projection surface (monitor). The range of permitted values depends on the screen mode.
(The maximum values are full-size resolution for the screen mode.) In the default window,
the window size is initially set so that it is identical to the monitor size (maximum values).
[Zlimit]
This parameter specifies the projection limit value for the window.
The projection limit parameter determines how deep of a space from the forward boundary
surface specified in the function "slZdspLevel" will be actually projected on the projection
surface. (Rear boundary surface specification) If "Zlimit = -1" is specified, the Zlimit value
for the window that was set last is used. If no other window has been set yet, the value for
the default window (7FFF) is used.
[CENTER_X, CENTER_Y]
These parameters determine the direction of the line of site as a pair of screen coordinate
values. It is possible to determine the point of convergence for a distant object group by
changing these values.
In 3D graphics, this point is called the "vanishing point."
In the default window, the vanishing point is set at the center of the screen.
Note: Screen coordinates
The term "screen coordinates" refers to the 2D graphics system that corresponds to the
TV monitor, which is the projection surface.
The upper left corner is the origin, while the positive direction on the X axis points to
the right and the positive direction on the Y axis points to the bottom of the screen.
Although the range of values depends on the screen mode, screen coordinates are
normally expressed in a 320 (horizontal)
224 (vertical) grid.
background image

Programmer's Tutorial / Coordinate Transformation
4-23
Fig 4-15 Differences in an Image Caused by CENTER_X and CENTER_Y
Note: The object, viewpoint, and all other conditions are the same in diagrams "a)" and "b)".
(0, 0)
(0, 0)
(319, 223)
(319, 223)
Object
Object
Projection surface
Projection surface
Vanishing point
Vanishing point: (160,112)
Vanishing point: (160,28)
a) Image when vanishing point is at the
center of the screen
b) Image when the vanishing point is
not at the center of the screen
Resetting the default window
When setting the default window again after having overwritten it for any reason, input the
values shown below in the library function "slWindow".
Note that the example below assumes that the screen size is 320 (horizontal) x 224 (vertical).
Fig 4-16 Resetting the Default Window
When the screen mode is 320
224
slWindow(0,0,319,223,0x7FFF,160,112);
Vanishing point coordinates:
center of screen
Window range specification coordinates
Zlimit
The default window is a window that is the same size as the monitor screen. In addition to the
window size being the same size as the monitor (the values vary according to the screen mode),
the rear boundary coordinate is "0x7FFF" and the vanishing point is set at the center of the
screen.
background image

4-24
Programmer's Tutorial / Coordinate Transformation
Sample program
The diagrams below illustrate how two objects are displayed using windows in the sample
program "sample_4_5".
Object 1 is a rectangular flat polygon, and object 2 is a cube. The two objects are placed so that
they intersect at a certain Z coordinate.
Diagram "d)" shows how the display would appear when a window has been set using the
library function "slWindow".
The settings are such that the portion of object 1 outside the window is displayed, and the
portion of object 2 inside the window is displayed. (These settings are explained later.)
Fig 4-17 Example of Object Display Using Windows
Note 1: Object 1 is displayed outside of the window.
Note 2: Object 2 is displayed inside of the window.
Viewpoint
Projection
surface
Window region
Projection
surface
Projection
surface
a) Object placement (side view)
b) Object placement (front view)
c) Normal display of objects
d) Display of objects when a window is set
background image


Programmer's Tutorial / Coordinate Transformation
4-25
List 4-6 sample_4_5: Example of Object Display Using Windows
/*-----------------------------------------------------*/
/*
Window & Clipping
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
#defineZlimit
150
#defineCENTER_X 160
#defineCENTER_X 112
exterm PDATAPD_PLANE,PD_CUBE;
void main()
{
static ANGLE
ang1[XYZ];ang2[XYZ];
static FIXED
pos1[XYZ];pos2[XYZ];
static Sint16
left=130,top=30,right=190,bottom=80;
static Sint16
v_move=1,h_move=1;
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program4.5",slLocate(9,2));
ang1[X]=ang1[Y]=ang1[Z]=DEGtoANG(0.0);
ang2[X]= DEGtoANG(30.0);
ang2[Y]=ang2[Z]=DEGtoANG(0.0);
pos1[X]=pos2[X]=toFIXED( 0.0);
pos1[Y]=pos2[X]=toFIXED( 0.0);
pos1[Z]=pos2[Z]=toFIXED(190.0);
while(-1){
left+=v_move;
top+=h_move;
light+=v_move;
bottom+=h_move;
if(left==0)v_move=1;
if(top==0)h_move=1;
if(right==319)v_move=-1;
if(bottom=223)h_move=-1;
slWindow(left,top,right,bottom,Zlimit,CENTER_X,CENTER_Y);
slPushMatrix();
{
slTranslate(pos1[X],pos1[Y],pos1[Z]);
slRotX(ang1[X]);
slRotY(ang1[Y]);
slRotZ(ang1[Z]);
slPutPolygon(&PD_PLATE);
}
slPopMatrix();
slPushMatrix();
slTranslate(pos2[X],pos2[Y],pos2[Z]);
slRotX(ang2[X]);
slRotY(ang2[Y]);
slRotZ(ang2[Z]);
slPutPolygon(&PD_CUBE);
slPopMatrix();
ang2[Y]+=DEGtoANG(1.0);
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* overwriting window position variables */
/* overwrite window position overwrite flag */
/* set window */
/* draw object 1 */
/* draw object 2 */
/* change object 2 display angle */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


4-26
Programmer's Tutorial / Coordinate Transformation
Flow Chart 4-5 sample_4_5: Flow Chart for Window Display
START
Initialize system
Set initial
object angle
Set object 1
display angle
Set object 2
display angle
Place object 1
Place object 2
Set up window
Set initial
object position
Draw object 1
Draw object 2
Call operation
matrix
Call operation
matrix
Synchronize
with screen
Set window
coordinates
Temporary allocation
of operation matrix
Temporary allocation
of operation matrix
background image

Programmer's Tutorial / Coordinate Transformation
4-27
In the SGL, an object can be set so that it switches between being displayed or not displayed
when inside or outside of a window. This switching setting can be made for individual polygon
faces as part of the polygon attributes. Although details are provided Chapter 7, "Polygon Face
Attributes," here we will briefly introduce the portion of the data file "polygon.c" that is used in
this sample program that is relevant to polygon face attributes.
List 4-7 polygon_c: Polygon Attributes Concerning Window Display
/*--------------------------------------------------------------------------*/
ATTRattribute_PLANE[]={
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(16,16,16),No_Gouraud,MESHoff:Window_Out,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(00,31,31),No_Gouraud,MESHoff:Window_Out,sprPolygon,No_Option),
};
ATTRattribute_CUBE[]={
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(31,31,31),No_Gouraud,MESHoff:Window_In,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(31,00,00),No_Gouraud,MESHoff:Window_In,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(00,31,00),No_Gouraud,MESHoff:Window_In,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(00,00,31),No_Gouraud,MESHoff:Window_In,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(31,31,00),No_Gouraud,MESHoff:Window_In,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN,No_Texture,C_RGB(00,31,31),No_Gouraud,MESHoff:Window_In,sprPolygon,No_Option),
};
/*---------------------------------------------------------------------------*/
/* omitted */
/* object 1 face attributes */
/* display outside of window */
/* object 2 face attributes */
/* omitted */
/* display inside of window */
Extent of effects of windows
The function "slWindow" can only be used twice within a single frame.
If a function like "slPutPolygon" or "slPutSprite" is called, doing so uses the first window;
subsequently, "slWindow" can only be called once. (When the above functions are called, the
default window settings change.)
Only one window can be set at a time.
In addition, if the function "slWindow" is called, the priority of previous polygons (sprites) and
of subsequent ones is disconnected; in this case, subsequent ones always have priority.
Fig 4-18 Extent of Effects of Window Settings
...
slPutPolygon(object1);
...
slPutPolygon(object2);
...
slWindow(...);
...
slPutPolygon(object3);
...
slWindow(...);
...
slPutPolygon(object4);
...
slPutPolygon(object5);
...
/* window 1 (default) */
/* window 2 */
/* still window 2 */
Example
Object 1 and 2 are displayed in the default window first,
and then afterwards window 2 is set.
With the default window being window 1, the newly set
window, window 2, appears on the projection surface.
When object 3 is subsequently drawn, it is affected by
new windows.
Objects 4 and 5 are drawn on the projection surface, under
the influence of the window 2.
If "slWindow" is executed again, an error results because
two windows are already in use; new window settings can
not be implemented.
background image

4-28
Programmer's Tutorial / Coordinate Transformation
Supllement. SGL Library Functions Covered in this Chapter
The functions listed in the following table were explained in this chapter.
Table 4-3 SGL Library Functions Covered in this Chapter
Function type
Function name
Parameters
Function
void
slPerspective
ANGLE angp
Perspective transformation table settings
void
slRotX
ANGLE angx
Rotation of polygon data around X axis
void
slRotY
ANGLE angy
Rotation of polygon data around Y axis
void
slRotZ
ANGLE angz
Rotation of polygon data around Z axis
void
slRotXSC
FIXED sn, FIXED cs
Rotation around X axis by specifying sine and cosine
values
void
slRotYSC
FIXED sn, FIXED cs
Rotation around Y axis by specifying sine and cosine
values
void
slRotZSC
FIXED sn, FIXED cs
Rotation around Z axis by specifying sine and cosine
values
void
slRotAX
FIXED vx, vy, cz,
Rotation around any desired axis that passes through
ANGLE a
the origin (axis unit: vector)
void
slTranslate
FIXED sx, sy, sz
Shift polygon data
void
slScale
FIXED sx, sy, sz
Enlargement/reduction of polygon data
void
slWindow
lft, top, rgt, btm,
Window setup
Zlimit, CNTX, CNTY
background image

Programmer's Tutorial / Demonstration Program A: Bouncing Cube
D-A-1
[Demonstration Program A: Bouncing Cube
demo_A
In order to demonstrate all of the functions that have been explained up to this point, this
section explains a slightly complex program that displays a polygon.
The following topics have been covered up to this point:
Drawing:
polygon definition (Chapter 2)
Light source:
Setting up a light source and how a light source changes the faces
of a polygon (Chapter 3)
Coordinate systems:
Coordinate systems used in SEGA Saturn (Chapter 4)
Modeling transformations: Object rotation, shift, enlargement/reduction, etc. (Chapter 4)
Drawing regions:
Windows and clipping (Chapter 4)
These topics are all comparatively common concepts in 3D graphics, regardless of the hard-
ware. (Of course, the functions that are used differ.)
Make sure that you have a good understanding of these concepts before proceeding with the
chapters that follow.
The chapters that follow will primarily explain concepts and special functions that are unique to
the SEGA Saturn system.
The demo program "demo_A" uses the SGL library functions that have appeared up to this
point, from drawing to coordinate conversion.
In the demo, a small cube bounces around inside a room represented by a cube in which all of
the sides face inwards. (In this case, when a side is viewed from the outside, it is not drawn.)
Collision detection between the small cube and the walls of the room is handled by a simple
conditional branch (based on the XYZ coordinate values).
Fig A-1 Depiction of Movement of Cube in Demo Program A
: Collision point
Object 2
Projection
surface
Path
Object 1
A small cube (object 1) bounces around
the inside of a larger cube (object 2) with
the front side removed.
background image


D-A-2
Programmer's Tutorial / Demonstration Program A: Bouncing Cube
List A-1 demo_A: Demonstration Program A
/*-----------------------------------------------------*/
/*
Cube Action
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
#define
REFLECT_EXTENT
toFIXED(85.0)
#define
XSPD
toFIXED(1.5)
#define
YSPD
toFIXED(2.0)
#define
ZSPD
toFIXED(3.0)
exterm PDATA PD_PLANE1,PD_PLANE2;
void main()
{
static ANGLE
ang1[XYZ];ang2[XYZ];
static FIXED
pos1[XYZ];pos2[XYZ],delta[XYZ],light[XYZ];
slInitSystem(TV_320x224,NULL,1);
slPrint("demoA",slLocate(9,2));
ang1[X]=ang1[Y]=ang1[Z]=DEGtoANG(0.0);
ang2[X]=ang2[Y]=ang2[Z]=DEGtoANG(0.0);
pos1[X]=pos2[X]=toFIXED( 0.0);
pos1[Y]=pos2[Y]=toFIXED( 0.0);
pos1[Z]=pos2[Z]=toFIXED(100.0);
delta[X]=XSPD,delta[Y]=YSPD,delta[Z]=ZSPD;
light[X]=slSin(DEGtoANG(30.0));
light[Y]=slCos(DEGtoANG(30.0));
light[Z]=slSin(DEGtoANG(-30.0));
while(-1){
slLight(light);
slPushMatrix();
{
slTranslate(pos1[X],pos1[Y],pos1[Z]+toFIXED(270.0));
pos1[X]+=delta[X];
pos1[Y]+=delta[Y];
pos1[Z]+=delta[Z];
if(pos1[X]>REFLECT_EXTENT){
delta[X]=-XSPD,pos1[X]-=XSPD;
} else if(pos1[X]<-REFLECT_EXTENT){
delta[X]=XSPD,pos1[X]+=XSPD;
}
if(pos1[Y]>REFLECT_EXTENT){
delta[Y]=-YSPD,pos1[Y]-=YSPD;
} else if(pos1[Y]<-REFLECT_EXTENT){
delta[Y]=YSPD,pos1[Y]+=YSPD;
}
if(pos1[Z]>REFLECT_EXTENT){
delta[Z]=-ZSPD,pos1[Z]-=ZSPD;
} else if(pos1[Z]<-REFLECT_EXTENT){
delta[Z]=ZSPD,pos1[Z]+=ZSPD;
}
slRotX(ang1[X]);
slRotY(ang1[Y]);
slRotZ(ang1[Z]);
ang1[X]+=DEGtoANG(3.0);
ang1[Y]+=DEGtoANG(5.0);
ang1[Z]+=DEGtoANG(3.0);
slPutPolygon(&PD_PLANE1);
}
slPopMatrix();
slPushMatrix();
{
slTranslate(pos2[X],pos2[Y],pos2[Z]);+toFIXED(170.0));
slRotY(ang2[Y]);
slRotX(ang2[X]);
slRotZ(ang2[Z]);
slPutPolygon(&PD_PLANE2);
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* initial substitution for various variables*/
/* object 1 position setting */
/* object 1 position variable overwrite */
/* object 1 position change variable overwrite */
/* object 1 display angle setting */
/* object 1 angle value overwrite */
/* object 1 drawing */
/* object 2 drawing */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image

Programmer's Tutorial / Demonstration Program A: Bouncing Cube
D-A-3
Flow Chart A-1 sample_1_6: Flow Chart for Demonstration Program A
START
Initialize system
Set initial
object angle
Reset position
of object 1
Was there
a collision with any of
the surfaces?
Set object 2
display angle
Place object 1
Place object 2
Set initial
object position
Set object 1
display angle
Draw object 1
Change direction
of shift
Draw object 2
Reset object 1
display angle
Call operation
matrix
Call operation
matrix
Synchronize
with screen
Temporary allocation
of operation matrix
Temporary allocation
of operation matrix
Yes
No
The next chapter will begin discussing hierarchical matrices and other increasingly difficult
topics. Because hierarchical structures that utilize the stack in particular are extremely impor-
tant in 3D graphics, study this material very thoroughly, and if necessary, consult outside
references as well.
background image

Programmer's Tutorial
5
Matrices
This chapter explains matrices, which are a fundamental tool for
constructing 3D graphics.
Matrix operations and concepts are explained in the first part of
the chapter, followed by an explanation of how to construct
objects with hierarchical structures using a stack matrix.
Read this chapter carefully, as matrix hierarchical structures in
particular are an important element in the expression of 3D
graphics in the SEGA Saturn system.
background image

5-2
Programmer's Tutorial / Matrices
Matrices
Matrices are tools for performing operations on groups of numbers as a single unit, rather than
as individual numbers.
Matrices are organized as n rows x m columns. Arithmetic operations can be performed on
matrices, although they differ from operations performed on normal numbers. (For details,
consult an outside reference.)
The illustration below shows a multiplication operation involving two 2 x 2 matrices.
In the SGL, 4 x 3 matrices are used as matrix variables in order to accurately represent three-
dimensional space (in order to implement the XYZ coordinate values and the various transfor-
mation operations).
Fig 5-1 The General Matrix Concept and Example of a Matrix Operation
M*T =
=
M
M
11
21
T
T
11
21
M T
M T
11 11
21 11
M T
M T
11 12
21 12
M T
M T
12 21
22 21
M T
M T
12 22
22 22
+
+
+
+
M
M
12
22
T
T
12
22
Note: M
to M
and T
to T
represent normal variables.
11
22
11
22
In the modeling transformations described in chapter 4, "Coordinate Transformations," new
polygon vertex data strings were actually created by multiplying polygon vertex data strings
represented as matrices by various transformation matrices (rotation, shift, scaling, etc.).
background image

Programmer's Tutorial / Matrices
5-3
Object Representation Using Hierarchical Structures
This section explains hierarchical structure representations of objects through matrices that use
the stack. In simple terms, this is a method of establishing relationships among multiple ob-
jects. This relationship is generally called a "parent-child" relationship.
Stack
The stack is a structure model for the efficient handling of matrices. This concept is illustrated
in Fig 5-2; the functions used for matrix stack operations are "slPushMatrix" and
"slPopMatrix".
In addition, The matrix at the bottom of the stack is called the "current matrix"; the various
matrix transformation operations are performed on the current matrix.
[Bool slPushMatrix (void);]
This function copies the current matrix to the bottom of the stack and also shifts the current
matrix designation to the bottom level. This function is used to temporarily store a matrix.
[Bool slPopMatrix (void);]
This function recovers a higher matrix that was temporarily stored and shifts the current matrix
designation to the higher level. The matrix in the lower position in the stack is discarded.
Fig 5-2 Stack Conceptual Model
: Current matrix
: Temporarily stored matrix
: Copy matrix to bottom of stack
: Recover matrix from top of stack
M1
M1
M1
M1
M1
M2
slPushMatrix
slTrans
slPopMatrix
Stack
Bottom
The stack can hold up to 20 matrices,
nested from the top of the stack to
the bottom.
Top
When the matrix environment has been initialized, the SGL stores a matrix, called the "environ-
ment matrix," as the current matrix.
This matrix defines the foundation for the SGL 3D matrix environment; if it is overwritten, it is
possible that the transformation operations will not be performed correctly.
The SGL supports the library function "slInitMatrix", which is used to initialize the stack and
various matrix variables.
[void slInitMatrix (void)]
This function initializes the stack and matrix variables. After initialization, the environment
matrix is stored in the stack as the current matrix.
background image

5-4
Programmer's Tutorial / Matrices
Overview of hierarchical structures
The following diagram is a conceptual model of an object group with a hierarchical structure.
Object 1 is set to the shallowest level of the structure, and object 2 and object 3 are defined at
consecutively deeper levels of the structure.
Fig 5-3 Conceptual Model of Hierarchical Structures
c) Hierarchical structure
(parent-child structure)
object1
object1
object2
object2
object3
object3
object3
object3
0
Y
X
M1
M2
M3
Deep
Hierarchical
level
Shallow
Parent
Child
Grandchild
a) Hierarchical object group
b) Stack structure
M = M *T
M = M *T
2
1
1
3
2
2
When the hierarchical structure is used, the object moves as shown in Fig 5-3. Fig 5-4 and 5-5
show the results when the same transformations are applied to an object group without a hierar-
chical structure and an object group with one. (Each object is being shifted in the X direction.)
Fig 5-4 Example of Shifting Objects without a Hierarchical Structure
object1
object2
0
0
0
X
X
X
Y
Y
Y
M1
M1
M1
M1
M1
M1
M1
M1
M1
M2
M3
slPush
slPop
slPop
slTrance
M2 = M1*T1
M3 = M1*T2
slTrance
slPush
c) Shift object 2
: Recover matrix from top of stack
: Copy matrix to bottom of stack
a) Initial state
b) Shift object 1
c) Shift object 2
b) Shift object 1
background image

Programmer's Tutorial / Matrices
5-5
Fig 5-5 Example of Shifting Objects with a Hierarchical Structure
object1
object2
0
0
0
X
X
X
Y
Y
Y
M1
M1
M1
M1
M1
M1
M1
M1
M2
M4
M2
M2
M2
M2
slPush
slPush
slPop
slTrance
M2 = M1*T1
M4 = M2*T1
slPop
slTrance
c) Shift object 2
: Recover matrix from top of stack
: Copy matrix to bottom of stack
a) Initial state
b) Shift object 1
First tier of hierarchy
Second tier of hierarchy
c) Shift object 2
b) Shift object 1
Definition of hierarchical structures in the SEGA Saturn system
The method for implementing hierarchical structures in the SEGA Saturn system is described
below, using a sample program as a reference.
background image


5-6
Programmer's Tutorial / Matrices
List 5-1 sample_5_2: Hierarchical Matrix Definition
/*-----------------------------------------------------*/
/*
Double Cube Circle Action
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
#define
DISTANCE_R1
40
#define
DISTANCE_R2
40
exterm PDATA PD_CUBE;
static void set_star(ANGLE ang[XYZ],FIXED pos[XYZ])
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
}
void main()
{
static ANGLE
ang1[XYZ];ang2[XYZ];
static FIXED
pos1[XYZ];pos2[XYZ];
static ANGLE tmp=DEGtoANG(0.0);
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program 5.2",slLocate(6,2));
ang1[X]=ang2[X]=DEGtoANG(30.0);
ang1[Y]=ang2[Y]=DEGtoANG(45.0);
ang1[Z]=ang2[Z]=DEGtoANG(0.0);
pos2[X]=toFIXED(DISTANCE_R2);
pos2[Y]=toFIXED(0.0);
pos2[Z]=toFIXED(0.0);
while(-1){
slUnitMatrix(CURRENT);
slPushMatrix();
{
pos1[X]=DISTANCE_R1*slSin(tmp);
pos1[Y]=toFIXED(30.0);
pos1[Z]=toFIXED(220.0)+DISTANCE_R1*slCos(tmp);
set_star(ang1,pos1);
slPutPolygon(&PD_CUBE);
slPushMatrix();
{
set_star(ang2,pos2);
slPutPolygon(&PD_CUBE);
}
slPopMatrix();
}
slPopMatrix();
ang1[Y]+=DEGtoANG(1.0);
ang2[Y]-=DEGtoANG(1.0);
tmp+=DEGtoANG(1.0);
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* make specified matrix a unit matrix */
/* move to bottom of stack */
/* move to bottom of stack */
/* move to top of stack */
/* move to top of stack */
/* overwrite angle */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


Programmer's Tutorial / Matrices
5-7
Flow Chart 5-1 sample_5_2: Flow Chart for Hierarchical Matrix Definition
START
Initialize system
Set initial
object angle
Draw object 1
Draw object 2
Set position of
object 1
Set position of
object 2
Call operation
matrix 2
Set initial
operation matrix
(create unit matrix)
Set object 1
display angle
Set object 2
display angle
Synchronize
with screen
Place object 1
Place object 2
Reset display
angle and position
Temporary allocation
of operation matrix 1
Temporary allocation
of operation matrix 2
Call operation
matrix 1
background image

5-8
Programmer's Tutorial / Matrices
Matrix Functions
In addition to those described previously, the SGL also supports the following matrix-related
library functions:
[void slLoadMatrix (MATRIX mtptr)]
This function copies the matrix specified as the parameter to the current matrix. Substitute a
MATRIX-type variable for the matrix being specified as the parameter.
[void slGetMatrix (MATRIX mtptr)]
This function copies the current matrix to the matrix specified as the parameter. Substitute a
MATRIX-type variable for the matrix being specified as the parameter.
[void slMultiMatrix (MATRIX mtrx)]
This function multiplies the current matrix with the matrix specified as the parameter.
Substitute a MATRIX-type variable for the matrix being specified as the parameter.
[Bool slPushUnitMatrix (void)]
This function allocates a unit matrix in the stack and makes it the current matrix. The
previous current matrix is temporarily stored at a high level in the stack.
[void slUnitMatrix (MATRIX mtptr)]
This function makes the matrix specified as the parameter into a unit matrix. Substitute a
MATRIX-type variable for the matrix being specified as the parameter.
If "CURRENT" is substituted for the parameter, the target matrix in this case is the current
matrix; this can be used to initialize the current matrix.
background image

Programmer's Tutorial / Matrices
5-9
Supplement. SGL Library Functions Covered in this Chapter
The functions listed in the following table were explained in this chapter.
Table 5-1 SGL Library Functions Covered in this Chapter
Function type
Function name
Parameters
Function
void
slLoadMatrix
MATRIX mtptr
Copy the specified matrix to the current matrix
Bool
slPushMatrix
void
Temporarily store a matrix
Bool
slPushUnitMatrix
void
Temporarily store a unit matrix in the stack
void
slGetMatrix
MATRIX mtptr
Copy the current matrix to the specified matrix
void
slInitMatrix
void
Initialize the matrix variables and buffer
void
slMultiMatrix
MATRIX mtrx
Multiply the specified matrix by the current matrix
Bool
slPopMatrix
void
Recover a temporarily stored matrix
void
slUnitMatrix
MATRIX mtptr
Make the specified matrix into a unit matrix
background image

Programmer's Tutorial / Demonstration Program B: Matrix Animation
D-B-1
[Demonstration Program B: Matrix Animation]
demo_B
This is a somewhat complex program that uses hierarchical structures.
Hierarchical structures are a concept that is unique to 3D graphics. This is because 3D graph-
ics, which involves handling a large volume of three-dimensional space, requires the ability to
handle a large volume of parameters at one time. Especially when maintaining relationships
among multiple objects as they move through a 3D space, it is necessary to handle fairly simple
yet highly intricate parameter groups at one time. As a result, the concept of the hierarchical
structure came into being.
The hierarchical structure is also called a "parent-child" structure. Hierarchical structures are
primarily used to represent joints (in modeling humans, etc.) and in representing object groups.
Fig B-1 Representation of Joints Using a Hierarchical Structure
b) Conceptual model of a hierarchical structure
(parent-child structure)
ude1
ude2
kata
te
yubi1
yubi2
yubi3
yubi4
yubi5
kata
ude2
ude1
te
yubi1
yubi2
yubi3
yubi4
yubi5
Shallow
Hierarchy level
Deep
a) Example of joints using a hierarchical structure
Demo program B is a sample program that shows animation using a hierarchical structure. In
the demonstration, complex motion (animation of an object group with a jointed structure) is
realized by creating and maintaining a relationship (parent-child structure) between three
objects. If the concept of hierarchical structures was not used, the resulting program would be
very complex and intricate.
Fig B-2 Conceptual Model of Demo Program B
object1
object1
object2
object2
object3
object3
1) Object 1 rotates around its fulcrum
2) Object 2 receives matrix from object 1
3) Object 2 rotates around its fulcrum
4) Object 3 receives matrix
5) Object 3 rotates around its fulcrum
Rotates
Rotates
Rotates
: Fulcrum of object rotation
Shallow
Deep
background image


D-B-2
Programmer's Tutorial / Demonstration Program B: Matrix Animation
List B-1 demo_B: Animation Using Hierarchical Structures
/*-----------------------------------------------------*/
/*
Matrix Animation
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA PD_PLANE1,PD_PLANE2,PD_PLA NE3;
static void set_poly(ANGLE ang[XYZ],FIXED pos[XYZ])
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
}
void main()
{
static ANGLE ang1[XYZ],ang2[XYZ],ang3[XYZ];
static FIXED pos1[XYZ],pos2[XYZ],pos3[XYZ];
static ANGLE tang,aang;
slInitSystem(TV_320x224,NULL,1);
slPrint("demo B",slLocate(6,2));
ang1[X]=ang1[Y]=ang1[Z]=DEGtoANG(0.0);
ang2[X]=ang2[Y]=ang2[Z]=DEGtoANG(0.0);
ang3[X]=ang3[Y]=ang3[Z]=DEGtoANG(0.0);
pos1[X]=toFIXED(0.0);
pos1[Y]=toFIXED(40.0);
pos1[Z]=toFIXED(170.0);
pos2[X]=toFIXED(0.0);
pos2[Y]=toFIXED(-40.0);
pos2[Z]=toFIXED(0.0);
pos3[X]=toFIXED(0.0);
pos3[Y]=toFIXED(-40.0);
pos3[Z]=toFIXED(0.0);
tang=DEGtoANG(0.0);
aang=DEGtoANG(2.0);
while(-1){
slUnitMatrix(CURRENT);
ang1[Z]=ang2[Z]=tang;
tang+=aang;
if(tang<DEGtoANG(-90.0)){
aang=DEGtoANG(2.0);
} else if(tang>DEGtoANG(90.0)){
aang=-DEGtoANG(2.0);
}
slPushMatrix();
{
set_poly(ang1,pos1);
slPutPolygon(&PD_PLANE1);
slPushMatrix();
{
set_poly(ang2,pos2);
slPutPolygon(&PD_PLANE2);
slPopMatrix();
{
set_poly(ang3,pos3);
ang3[Y]+=DEGtoANG(5.0);
slPutPolygon(&PD_PLANE3);
}
slPopMatrix();
}
slPopMatrix();
}
slPopMatrix();
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* substitution of initial angles for objects */
/* substitution of initial positions for objects */
/* move to bottom of stack (second tier of hierarchy) */
/* draw object 1 */
/* move to bottom of stack (third tier of hierarchy) */
/* draw object 2 */
/* move to bottom of stack (fourth tier of hierarchy) */
/* draw object 3 */
/* move to top of stack (third tier of hierarchy) */
/* move to top of stack (second tier of hierarchy) */
/* move to top of stack (first tier of hierarchy) */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image

Programmer's Tutorial / Demonstration Program B: Matrix Animation
D-B-3
Flow Chart B-1 demo_B: Flow Chart for Hierarchical Structures
START
Initialize system
Set initial
object angle
Draw object 1
Draw object 2
Call operation
matrix 3
Synchronize
with screen
Draw object 3
Change object 1
angle value
Change object 2
angle value
Change object 3
angle value
Sort polygons
Set initial object
position
Set object 1
display angle
Set object 2
display angle
Set object 3
display angle
Place object 1
Place object 2
Place object 3
Call operation
matrix 2
Call operation
matrix 1
Temporary allocation
of operation matrix 1
Set initial operation matrix
(create unit matrix)
Temporary allocation
of operation matrix 2
Temporary allocation
of operation matrix 3
The following chapters will explain polygon surface attributes (including priority, color, and
texture), background scrolling (which is indispensable for game development), drawing alpha-
numerics, and input/output control.
background image

Programmer's Tutorial
6
The Camera
This chapter explains the definition of the "camera" and its
operation method.
The camera defines the vantage point from which the 3D space
is being viewed, and is also called the "viewing transformation."
The camera consists of the viewpoint, the line of sight, and the
angle; by changing these three elements, it is possible to draw
anywhere within the space on the projection surface.
background image

6-2
Programmer's Tutorial / The Camera
Camera Definition and Setup
There are two methods of camera definition and setup in the SGL.
1) Fix the viewpoint at the origin and the line of sight on the Z axis and move the objects to
obtain the desired image
2) Fix the objects in place, and move the viewpoint and line of sight to obtain the desired image
In order to implement "1", it is necessary to apply modeling transformations to all of the objects
residing in the space.
To implement "2", use the library function "slLookAt".
However, even in the case of "2", method "1" is used internally, and it only appears that the
camera is moving freely within the space.
For more precise camera setup (which will not be covered here), use method "1". From the
standpoint of processing speed, method "1" is more efficient, and it is possible to add changes
to the viewpoint and line of sight.
background image

Programmer's Tutorial / The Camera
6-3
Camera Setup Using "slLookAt"
The SGL supports the library function "slLookAt", which simplifies camera setup.
[void slLookAt (FIXED *camera, FIXED *target, ANGLE angz);]
This function controls the 3D graphics camera (the direction of the field of view). There are
three parameters: the X, Y, and Z coordinates (three-dimensional matrix) of the camera, the
X, Y, and Z coordinates (three-dimensional matrix) of the target that determines the direc-
tion of the line of sight, and the angle of rotation of the camera versus the direction of the
line of sight. When used in conjunction with the functions "slPerspective" and "slWindow",
these three functions can completely determine the 3D graphics drawing region.
Fig 6-1 Conceptual Model of the Camera
b) Image seen by camera
Viewpoint
Line of sight
Angle: angle of twist versus the line of sight
Object
Target
Projection surface
a) Conceptual model of camera
We will explain the angle parameter in a little more detail here. Put simply, the angle parameter
determines the angle of the camera versus the line of sight. By changing the angle parameter, a
different image can be drawn on the same line of sight.
Fig 6-2 Differences in an Image Due to the Angle Parameter
Note: The camera position, target coordinates, and the object
are exactly the same in diagrams "a" and "b."
Projection surface
Projection surface
Object
Object
a) When top of camera is
aligned with the Y axis
b) When the top of the camera is
at a 45 angle to the Y axis
background image

6-4
Programmer's Tutorial / The Camera
Actual Camera Operation
The following listing is for a program that shows the changes in an image that result when the
camera parameters are changed so that the camera moves through a 3D space. A cubic polygon
with different colors on each side is placed in a 3D space away from the target coordinates.
List 6-1 sample_6_3: Camera Movement
/*-----------------------------------------------------*/
/*
Camera Action
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
#define POS_Z
100.0
typedef struct cam{
FIXEDpos[XYZ]
FIXEDtarget[XYZ]
ANGLE
ang[XYZ]
}CAMERA;
extern PDATAPD_CUBE;
static FIXED cubepos[][3]={
POStoFIXED(20,0,270),
POStoFIXED(-70,0,270),
POStoFIXED(40,0,350),
POStoFIXED(-60,0,370),
};
void dispCube(FIXED pos[XYZ])
{
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slPutPolygon(&PD_CUBE);
}
slPopMatrix();
}
void main()
{
static ANGLE ang[XYZ];
static CAMERA
cmbuf;
static ANGLE tmp=DEGtoANG(0,0);
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program6.3",slLocate(9,2));
cmbuf.ang[X]=cmbuf.ang[Y]= cmbuf.ang[Z]= DEGtoANG(0,0);
cmbuf.target[X]=cmbuf.target[Y]= toFIXED(0,0);
cmbuf. target [Z]=toFIXED(320,0);
cmbuf.pos[X]=toFIXED( 0.0);
cmbuf.pos[Y]=toFIXED(-20.0);
cmbuf.pos[Z]=toFIXED( 0.0);
while(-1){
slUnitMatrix(CURRENT);
slLookAt(cmbuf.pos, cmbuf.target, cmbuf.ang[Z]);
tmp+=DEGtoANG(2.0);
cmbuf.pos[X]=POS_Z*slCos(tmp);
cmbuf.pos[Z]=POS_Z*slSin(tmp);
dispCube(cubepos[0]);
dispCube(cubepos[1]);
dispCube(cubepos[2]);
dispCube(cubepos[3]);
slSynch();
}
}
/* include file containing various settings */
/* screen mode setting */
/* program title display */
/* initial setting of camera variables */
/* initialization of operation matrix */
/* camera setup */
/* change camera setting variables */
/* draw object */
Note: The lightly shaded portion is defined in "sgl.h" and "sl_def.h".
Note: The darkly shaded portion is defined in "polygon.c".
background image


Programmer's Tutorial / The Camera
6-5
Flow Chart 6-1 sample_6_3: Flow Chart for Camera Movement
START
Initialize system
Set viewpoint
position
Set viewpoint
angle
Set initial
object angle
Temporary allocation of
operation matrix 1
Set up viewpoint
position
Set position of center
of field of view
Set initial
object position
Place object
Draw object
Set object
display angle
Call operation
matrix
Synchronize
with screen
Reset viewpoint
position
Set initial operation matrix
(create unit matrix)
background image

6-6
Programmer's Tutorial / The Camera
Supplement. SGL Library Functions Covered in this Chapter
The functions listed in the following table were explained in this chapter.
Table 6-1 SGL Library Functions Covered in this Chapter
Function type
Function name
Parameters
Function
void
slLookAt
FIXED *camera, *target,
Multiplies line of sight matrix with the current matrix
ANGLE angz
background image

Programmer's Tutorial
7
Polygon Face Attributes
This chapter explains polygon face attributes in the SEGA
Saturn system. The polygon attributes include: "Sort", which
shows the reference position that determines the display order;
the "front-back attribute", which specifies whether one or both
sides of a polygon is to be displayed; and "texture", a 2D picture
(bit-mapped data) that is applied to the polygon.
By specifying the polygon attributes, it is possible to add a variety
of representations to polygons that were simply pictures before.
background image

7-2
Programmer's Tutorial / Polygon Face Attributes
Attributes
In the SEGA 3D Game Library (SGL), polygon attributes are specified by the ATTRIBUTE
macro.
In the sample programs used in this manual up to this point, these attributes have been set
tacitly without a detailed explanation of their contents.
However, the attributes are a collection of very important elements for the handling of poly-
gons. Therefore, this section will explain each of the parameters of the ATTRIBUTE macro in
detail.
List 7-1 Attribute Data
ATTR attribute_label [ ] = {
ATTRIBUTE ( plane, sort, texture, color, ground, mode, dir, option),
.....................
};
Attribute data
Note: The ATTRIBUTE macro is defined in "sl_def.h".
The meaning of each parameter is as follows:
plane:
Indicates whether the polygon is a one-sided polygon or a double-sided polygon
(front-back attribute).
sort:
Indicates the representative point for the polygon's positional relationships (Zsort).
texture: Indicates the texture name (No.).
color:
Indicates the color data.
gouraud: Indicates the gouraud shading table address.
mode:
Indicates the polygon drawing mode (various mode settings).
dir:
Indicates the status of the polygon and the texture.
option:
Indicates other functions (optional settings).
background image

Programmer's Tutorial / Polygon Face Attributes
7-3
Plane
The first attribute parameter, "plane", indicates the front-back attribute of the polygon. The front-
back attribute is the attribute that indicates whether the polygon is single-sided or double-sided.
A double-sided polygon can be seen from both the front and the back, but a single-sided poly-
gon disappears if viewed from the back.
The macros that can be specified for this parameter are introduced below.
Table 7-1 Plane (Front-Back Attribute)
Macro
Description
Single_Plane Single-sided display of polygon
Dual_Plane Double-sided display of polygon
Now let's examine the sample program (List 7-2). In this program, a single-sided yellow
polygon is rotating around the Y axis. Because it is a single-sided polygon, the back of the
polygon is not displayed.
List 7-2 sample_7_2: main.c
/*-----------------------------------------------------*/
/*
Rotation of Single Plane Polygon
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA PD_PLANE;
void main()
{
static ANGLE ang[XYZ];
static FIXED pos[XYZ];
slInitSystem(TV_320x224,NULL, 1);
slPrint("Sample program 7.2",slLocate(6,2));
ang[X]=ang[Y]=ang[Z]=DEGtoANG(0,0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(170.0);
while(-1){
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
ang[Y]+=DEGtoANG(2.0);
slPutPolygon(&PD_PLANE);
}
slPopMatrix();
slSynch();
}
}
/* initialization */
/* initial angle substitution */
/* initial position substitution */
/* save matrix */
/* set position */
/* set angle */
/* addition of Y axis rotation angle */
/* polygon drawing function */
/* recover matrix */
background image

7-4
Programmer's Tutorial / Polygon Face Attributes
Look again at line 27. This line calls the polygon drawing routine "slPutPolygon", and passes
the pointer to the polygon data "PD_PLANE".
"PD_PLANE" is defined in the source file "polygon.c" as shown below.
List 7-3 sample_7_2: Polygon.c
#include
"sgl.h"
POINTpoint_PLANE1[]={
POStoFIXED(-20.0,-20.0,0.0),
POStoFIXED( 20.0,-20.0,0.0),
POStoFIXED( 20.0, 20.0,0.0),
POStoFIXED(-20.0, 20.0,0.0),
};
POLYGONpolygon_PLANE1[]={
NORMAL(0.0,0.0,1.0),VERTICES(0,1,2,3),
};
ATTRattribute_PLANE1[]={
ATTRIBUTE(Single_Plane,SORT_CEN,No_Texture,C_RGB(31,31,0),NO_Gouraud,MESHoff,sprPolygon,No_Option),
};
PDATAPD_PLANE1={
point_PLANE,sizeof(point_PLANE)/sizeof(POINT),
polygon_PLANE,sizeof(polygon_PLANE)/sizeof(POLYGON),
attribute_PLANE
};
/* polygon data */
The polygon data starts in line 18. Because line 21 is the pointer for the attribute data, the data
actually starts in line 14.
As you can see, the first parameter is "Single_Plane". change this to "Dual_Plane" and execute
the program again. Whereas only one side of the polygon was displayed before, now both sides
of the polygon should be displayed.
background image

Programmer's Tutorial / Polygon Face Attributes
7-5
Sort
The second parameter, "Sort". specifies the Z sort position on the polygon. The Z sort method
uses a representative point on each polygon to determine its position in 3D space and its interre-
lationships with other polygons. This method offers the advantage of faster computing and
drawing than the Z buffer method (in which the position is determined for each pixel in the
polygon). The macros that can be specified for this parameter are introduced below.
Table 7-2 Z Sort Specification
Macro
Description
SORT_MIN
Makes the point (on the polygon) closest to the camera the representative point.
SORT_CEN
Makes the center point of the polygon the representative point.
SORT_MAX
Makes the point (on the polygon) farthest from the camera the representative point.
SORT_BFR
Displays the polygon in front of the last polygon that was registered.
The following diagram illustrates each of these specifications.
Fig 7-1 Z Sort Representative Points
"SORT_BFR" is a special specification that is used to display a certain polygon on top of (in
front of) another polygon. To be specific, the display position of the polygon for which
"SORT_BFR" is specified is right in front of the polygon that was registered last. This specifi-
cation is not used often, since it has meaning only in cases where you wish to group two poly-
gons together and use them as a unit.
Due to the nature of the Z sort method, the manner in which the representative point is deter-
mined may cause unusual interrelationships. The following illustration is an example of such as
case.
Fig. 7-2 Differences in Interrelationships Due to the Representative Points
"SORT_MAX" specification
"SORT_MIN" specification
Camera
background image

7-6
Programmer's Tutorial / Polygon Face Attributes
If the representative points are specified as shown in the above diagram, the actual screen image
will appear as shown below.
Fig. 7-3 Actual Screen Image
background image

Programmer's Tutorial / Polygon Face Attributes
7-7
Texture
The third parameter is required when using texture mapping. Specify the texture number to be
actually used from the texture table that was registered using the function "slInitSystem".
If texture is not to be used, specify the macro "No_Texture".
"Texture mapping" is the name of a function in which 2D graphics are applied to the surface of
a polygon. Polygons by themselves can only display colors, and it goes without saying that this
limits the realism of the objects. By using the texture mapping function, however, it is possible
to replicate 3D objects with a higher degree of realism by depicting textures and surface pat-
terns that could not be represented solely with polygons.
Fig 7-4 Texture Mapping
Polygon object
Texture
Texture-mapped object
As shown in Table 7-3, there are two major differences between texture mapping in the SEGA
Saturn system and texture mapping in computer graphics in general.
Table 7-3 Differences between Texture Mapping in the SEGA Saturn System and
Texture Mapping in General Computer Graphics
SEGA Saturn Texture Mapping
General Computer Graphics Texture Mapping
Texture application
Only one texture can be applied
One texture can be applied across multiple
to one polygon
polygons
Texture shape
Texture changes shape according
Texture is clipped according to shape of polygon
to shape of polygon
background image

7-8
Programmer's Tutorial / Polygon Face Attributes
Texture application
Fig 7-5 Special Texture Characteristic 1
b) Texture application in SEGA Saturn
TEXTURE
POLYGON
a) Texture application in general computer graphics
While in general computer graphics it is possible to apply one texture across multiple polygons, in
the SEGA Saturn system, one texture is applied to only one polygon. To apply texture across two
or more polygons, it is necessary to divide the texture for each polygon as shown in Fig 7-5.
Texture Shaping
In general computer graphics, if the polygon is not rectangular (or square), the texture is clipped
according to the shape of the polygon. However, in the SEGA Saturn system, the texture is not
clipped, and instead changes shape to conform to the polygon. Even if the polygon is a triangle,
the texture changes to a triangular shape.
TEXTURE
POLYGON
The texture changes shape to conform
with the shape of the polygon.
a) Texture application in
general computer graphics
b) Texture application in
SEGA Saturn
background image

Programmer's Tutorial / Polygon Face Attributes
7-9
Note: Texture distortion
When a polygon is rectangular and the texture is square, the texture will change to a
rectangular shape in order to match the aspect ratio of the polygon.
Therefore, is best to try to remember to keep the aspect ratio of the texture as close as
possible to the aspect ratio of the polygon in order to minimize texture distortion.
Fig 7-7 Texture Distortion
TEXTURE
POLYGON
+
Let's now examine another sample program (List 7-4).
In this program, a single polygon with texture applied rotates around the Y axis. In this pro-
gram, two textures are registered. One is a 4
4 matrix-type picture (size: 64
64 pixels), and
the other is the "AM2" mark (size: 64
64 pixels).
background image

7-10
Programmer's Tutorial / Polygon Face Attributes
List 7-4 sample_7_4: main.c
/*-----------------------------------------------------*/
/*
Polygon & Texture
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA
PD_PLANE;
exterm TEXTURE
tex_sample[];
exterm PICTURE
pic_sample[];
#define
max_texture
2
void set_texture(PICTURE*pcptr,Uint32 NbPicture)
{
TEXTURE*txptr;
for(;NbPicture-->0;pcptr++){
txptr=tex_sample+pcptr->texno;
slDMACopy(void*)pcptr->pcsrc,
(void*)(SpriteVRAM+((txptr->CGadr)<<3)),
(Uint32)((txptr->Hsize*txptr->Vsize*4>>(pcptr->cmode)));
}
}
void main()
{
static ANGLE ang[XYZ];
static FIXED pos[XYZ];
slInitSystem(TV_320x224,tex_sample,1);
set_texture(pic_sample,max_texture);
slPrint("Sample program7.4",slLocate(9,2));
ang[X]=ang[Y]=ang[Z]=DEGtoANG(0.0);
pos[X]=toFIXED( 0.0);
pos[Y]=toFIXED( 0.0);
pos[Z]=toFIXED(170.0);
while(-1){
slPushMatrix();
{
slTranslate(pos[X],pos[Y],pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
ang[Y]+=DEGtoANG(2.0);
slPutPolygon(&PD_PLANE);
}
slPopMatrix();
slSynch();
}
}
/* number of texture registrations */
/* store texture data in VRAM */
/* initialization */
/* store texture data */
/* initial angle substitution */
/* initial position substitution */
/* save matrix */
/* set position */
/* set angle */
/* addition of Y axis rotation angle */
/* polygon drawing function */
/* recover matrix */
The flow of the program is basically the same as that of List 7-2.
Look closely at line 29.
Although this is the initialization routine that has been tacitly used up to this point, the specifi-
cation of the second parameter is different this time. Here the parameter specifies the pointer
for the texture table to be passed to SGL. (The actual table is defined by "texture.c"; refer to
List 7-5.) Because texture has not been used up to this point, previously "NULL" was speci-
fied.
In line 30, the texture data is transferred to VRAM.
Because this texture data transfer can be executed at any point after initialization, it is easy to
draw over the previous texture in the middle of a game, for example.
The actual texture data transfer routine starts in line 12.
The starting address of the texture table and the number of texture registrations are accepted
here. In line 18, the function "slDMACopy" executes a high-speed DMA data transfer. The
first parameter of this function is the transfer source address, the second parameter is the trans-
fer destination address, and the third parameter indicates the size of the transfer.
background image

Programmer's Tutorial / Polygon Face Attributes
7-11
[void slDMACopy (void *src, void *dst, Uint16 cnt);]
This function executes a block transfer of data using the DMA built into the CPU.
For the parameters, substitute the start address of the area in memory that is the source of the
transfer, the start address of the area in memory that is the destination of the transfer, and the
number of bytes in the transfer block.
The function in question completes the transfer soon after DMA is activated.
Use the function "slDMAWait" if you want to know when the transfer is completed.
Next, let's examine the texture data.
List 7-5 sample_7_4: texture.c
#include
"sgl.h"
/******************************/
/*
Texture Data
*/
/*****************************/
TEXDAT sonic_64x64[]={
0xffff,0xffff,0xffff,0xffff,0xffff,0xffff,0xffff,0xffff,
...
...
};
TEXDAT am2_64x32[]={
0xffff,0xffff,0xffff,0xffff,0xffff,0xffff,0xffff,0xffff,
...
...
};
/*******************************/
/*
Texture Table
*/
/*******************************/
TEXTURE tex_sample[]={
TEXDEF(64,64,0),
TEXDEF (64,32,64*64*1),
};
/******************************/
/*
Picture Table
*/
/*****************************/
PICTURE pic_sample[]={
PICDEF(0,COL_32K,sonic_64x64),
PICDEF(1,COL_32K,am2_64x32),
};
/* include file containing various settings */
/* texture data 1 */
omitted
/* texture data 2 */
omitted
/* table to be passed to SGL */
/* table for transfer to VRAM */
The TEXDAT macro describes the actual texture data. Although omitted from the above
listing, all of the data is included in the source listing. Finally, the texture data format is beyond
the scope of this manual. Refer to the "Function Reference" of the Reference Manual.
The TEXTURE macro describes the texture table to be passed to SGL. This macro sets the size
(horizontal
vertical) and the offset from the start address of the actual texture data for each
texture.
Finally, the PICTURE macro describes the VRAM transfer table. This macro sets each texture
number, color mode, and texture data pointer.
background image

7-12
Programmer's Tutorial / Polygon Face Attributes
Lastly, we will examine the polygon data attributes.
List 7-6 sample_7_4: polygon.c
#include
"sgl.h"
#define
PN_SONIC
0
#define
PN_AM2
1
POINT point_plane[]={
POStoFIXED(-40.0,-40.0, 0.0),
POStoFIXED( 40.0,-40.0,0.0),
POStoFIXED( 40.0, 40.0,0.0),
POStoFIXED(-40.0, 40.0,0.0),
};
POLYGON polygon_plane[]={
NORMAL(0.0,0.01.0),
VERTICES(0,1,2,3),
};
ATTR attribute_plane[]={
ATTRIBUTE(Single_Plane,SORT_CEN, PN_SONIC, No_Palet, No_Gouraud, CL32KRGB|MESHoff,
sprNoflip, No_Option),
};
PDATAPD_PLANE={
point_plane, sizeof(point_plane)/sizeof(POINT),
polygon_plane, sizeof(polygon_plane)/sizeof(POLYGON),
attribute_plane
};
/* attribute settings */
/* polygon data */
The third "ATTRIBUTE" parameter is "PN_SONIC". In short, the "4
4 matrix" with the
texture number registered as "0" is applied to the polygon.
Next, change this parameter to "PN_AM2" and observe the result.
The texture changes to texture number 1, the "AM2" mark.
It is also possible to view the texture from the back by changing the first parameter,
"Single_Plane", to "Dual_Plane".
background image

Programmer's Tutorial / Polygon Face Attributes
7-13
Color
The fourth parameter "Color" specifies the polygon color and the offset address for the texture
color palette.
In the case of a polygon, the color data specification method is limited to RGB direct, and the
format is "C_RGB(r,g,b)". "r,g,b" refer to the three primary colors of light (red, green, and
blue), and can be specified with decimal numbers in the range from 0 to +31.
In the case of texture, the color data specification method depends on the "Mode" specification
(the sixth attribute parameter; refer to "Mode"). Specify either the macro "No_Palet" in the
case of 32,768-color RGB mode, or else the offset address for the color palette in the case of
another index mode.
background image

7-14
Programmer's Tutorial / Polygon Face Attributes
Gouraud
The fifth parameter, "Gouraud", specifies the gouraud table used for gouraud shading.
"Gouraud shading" is a technique that, as opposed to the flat shading which clearly delineates
the boundaries between polygons, applies shadow processing to the surfaces of polygons in
order to eliminate the boundary line between polygons and create the impression of a curved
surface. In the SEGA Saturn system, gouraud shading is implemented by using the color
gradations between polygon vertices.
Fig 7-8 Gouraud Shading
Gouraud shading
Flat shading
The sample program (List 7-7) shows a cube with gouraud shading rotating around the Y axis.
background image

Programmer's Tutorial / Polygon Face Attributes
7-15
List 7-7 sample_7_6: main.c
/*-----------------------------------------------------*/
/*
Gouraud Shading
*/
/*-----------------------------------------------------*/
#include
"sgl.h"
exterm PDATA PD_CUBE;
#idefine
GroffsetTBL(r,g,b)
(((b & 0x1f)<<10) | ((g & 0x1f)<<5) | (r & 0x1f))
#define
VRAMaddr
(SpriteVRAM+0x70000)
static Uint16 GRdata[6][4]={
{ GRoffsetTBL( 0,-16,-16) , GRoffsetTBL( 0,-16,-16) ,
GRoffsetTBL( 0,-16,-16) , GRoffsetTBL(-16, 15, 0) } ,
{ GRoffsetTBL( 0,-16,-16) , GRoffsetTBL( 0,-16,-16) ,
GRoffsetTBL(-16, 15, 0) , GRoffsetTBL( 0,-16,-16) ,
{ GRoffsetTBL(-16, 15, 0) , GRoffsetTBL( 0,-16,-16) ,
GRoffsetTBL( 0,-16,-16) , GRoffsetTBL( 0,-16,-16) ,
{ GRoffsetTBL( 0,-16,-16) , GRoffsetTBL(-16, 15, 0) ,
GRoffsetTBL( 0,-16,-16) , GRoffsetTBL( 0,-16,-16) ,
{ GRoffsetTBL( 0,-16,-16) , GRoffsetTBL(-16, 15, 0) ,
GRoffsetTBL( 0,-16,-16) , GRoffsetTBL( 0,-16,-16) ,
{ GRoffsetTBL(-16, 15, 0) , GRoffsetTBL( 0,-16,-16) ,
GRoffsetTBL( 0,-16,-16) , GRoffsetTBL( 0,-16,-16) ,
};
void main()
{
static ANGLE
ang[XYZ];
static FIXED
pos[XYZ];
slInitSystem(TV_320x224,NULL,1);
slPrint("Sample program 7.6", slLocate(9,2));
ang[X]=DEGtoANG(30.0);
ang[Y]=DEGtoANG(0.0);
ang[Z]=DEGtoANG(0.0);
pos[X]=toFIXED(0.0);
pos[Y]=toFIXED(0.0);
pos[Z]=toFIXED(200.0);
slDMACopy(GRdate,(void*)VRAMaddr,sizeof(GRdata));
while(-1){
slPushMatrix();
{
slTranslate(pos[X] , pos[Y] , pos[Z]);
slRotX(ang[X]);
slRotY(ang[Y]);
slRotZ(ang[Z]);
slPutPolygon(&PD_CUBE);
}
slPopMatrix();
ang[Y] += DEGtoANG(1.0);
slSynch();
}
}
/* gouraud table */
/* initialization */
/* initial angle substitution */
/* initial position substitution */
/* store gouraud table */
/* save matrix */
/* set position */
/* polygon drawing function */
/* recover matrix */
/* addition of Y axis rotation angle */
The routine that draws the cube and rotates it is not very different from what has been used
before, so its explanation is omitted here. What is different from previous programs is line 41,
where the gouraud table is sent to VRAM. The approach is the same as for the texture data
transfer; all of the required tables are first stored in VRAM.
Now let's proceed to the next attribute.
background image

7-16
Programmer's Tutorial / Polygon Face Attributes
List 7-8 sample_7_6: polygon.c
#include
"sgl.h"
#define GRaddr
0xe000
static POINT point_CUBE[]={
POStoFIXED(-20.0,-20.0,20.0),
POStoFIXED( 20.0,-20.0,20.0),
POStoFIXED( 20.0,20.0,20.0),
POStoFIXED(-20.0,20.0,20.0),
POStoFIXED(-20.0,-20.0,-20.0),
POStoFIXED( 20.0,-20.0,-20.0),
POStoFIXED( 20.0,20.0,-20.0),
POStoFIXED(-20.0,20.0,-20.0),
};
static POLYGON polygon_CUBE[]={
NORMAL( 0.0,0.0,1.0),VERTICES(0,1,2,3),
NORMAL(-1.0,0.0,0.0),VERTICES(4,0,3,7),
NORMAL( 0.0,0.0,-1.0),VERTICES(5,4,7,6),
NORMAL( 1.0,0.0,0.0),VERTICES(1,5,6,2),
NORMAL( 0.0,-1.0,0.0),VERTICES(4,5,1,0),
NORMAL( 0.0,1.0,0.0),VERTICES(3,2,6,7),
};
static ATTR attribute_CUBE[]={
ATTRIBUTE(Single_Plane,SORT_MIN, No_Texture,C_RGB(31,16,31),GRaddr, MESHoffiCL_Gourand,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN, No_Texture,C_RGB(31,16,31),GRaddr,+1,MESHoffiCL_Gourand,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN, No_Texture,C_RGB(31,16,31),GRaddr,+2,MESHoffiCL_Gourand,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN, No_Texture,C_RGB(31,16,31),GRaddr,+3,MESHoffiCL_Gourand,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN, No_Texture,C_RGB(31,16,31),GRaddr,+4,MESHoffiCL_Gourand,sprPolygon,No_Option),
ATTRIBUTE(Single_Plane,SORT_MIN, No_Texture,C_RGB(31,16,31),GRaddr,+5,MESHoffiCL_Gourand,sprPolygon,No_Option),
};
PDATA PD_CUBE={
point_CUBE, sizeof(point_CUBE)/sizeof(POINT),
polygon_CUBE,sizeof(polygon_CUBE)/sizeof(POLYGON),
attribute_CUBE
};
/* attribute settings */
/* polygon data */
Examine the attributes closely.
The VRAM address where the gouraud data was stored earlier is specified for the fifth param-
eter. The VRAM address specified here is relative address divided by eight.
Now look at the sixth parameter.
When using gouraud shading, this parameter must be specified as "CL_Gouraud". This specifi-
cation will be explained later.
Note that the macro "No_gouraud" should be specified for "Gouraud" when not using gouraud
shading.
background image


Programmer's Tutorial / Polygon Face Attributes
7-17
Mode
The sixth parameter is "Mode".
This parameter is used to add a variety of conditions and settings to the polygon. The macros
that can be specified for this parameter are shown in the following table.
Table 7-4 Modes
Group
Macro
Description
[1]
No_Window
Accept no window restrictions (default)
Window_In
Display inside window
Window_Out
Display outside window
[2]
MESHoff
Normal display (default)
MESHon
Display with mesh
[3]
ECdis
Disable EndCode
ECenb
Enable EndCode (default)
[4]
SPdis
Display clear pixels (default)
SPenb
Do not display clear pixels
[5]
CL16Bnk
16-color color bank mode (default)
CL16Look
16-color look-up table mode
CL64Bnk
64-color color bank mode
CL128Bnk
128-color color bank mode
CL256Bnk
256-color color bank mode
CL32KRGB
32,768-color RGB mode
[6]
CL_Rdplace
Overwrite (standard) mode (default)
CL_Shadow
Shadow mode
CL_Half
Half-bright mode
CL_Trans
Semi-transparent mode
CL_Gouraud
Gouraud shading mode
One option from each group can be specified. Use consecutive description, delimiting the
options with the "or" ("|") operator.
Note: If a group is omitted, the default option is assumed. However, it is not permis-
sible to omit specifications for all of the options. To use the default options for all
groups, specify "No_Window" as dummy data.
Because group [5] is used to specify the texture color mode, you must set the default option
(either specify "CL_16Bnk" or make no specification for this group) if texture is not to be used.
If any other mode is specified in this case, the polygon will not be displayed.
As an exception, in group [6] it is possible to specify "CL_Gouraud | CL_Half" and "CL_Gouraud
| CL_Trans" if you wish to use half-bright gouraud shading or semi-transparent gouraud shading.
Note that when using gouraud shading it is necessary to both set the fifth parameter and to
specify "CL_Gouraud" here.
When using half-bright mode, semi-transparent mode, or gouraud shading, polygons support
only RGB direct mode and textures support only 32,768-color RGB mode. Objects will not be
displayed properly with any other settings.
background image


7-18
Programmer's Tutorial / Polygon Face Attributes
Dir
The seventh parameter is "Dir". This parameter specifies whether the object is a polygon or a
texture, and if it is a texture, how it should be flipped.
Table 7-5 Dir
Macro
Description
sprNoflip
Display texture normally
sprHflip
Flip texture horizontally
sprVflip
Flip texture vertically
sprHVflip
Flip texture vertically and horizontally
sprPolygon
Display polygon
sprPolyLine
Display polyline
sprLine
Display a straight Line using the first
two points
Note: If texture is not being applied to an object, do not specify "sprHflip" or "sprVflip".
Specify sprLine with four points, just as with a polygon. (Repeat the specifications of the
first two points.)
background image


Programmer's Tutorial / Polygon Face Attributes
7-19
Option
The last parameter is "Option". Other settings concerning polygons and textures are made here.
At present, the SGL only supports the following two options:
Table 7-6 Options
Macro
Description
UseLight
Perform light source calculations
UseClip
Do not display vertices outside of the display area
UsePalette
Indicates that the palette format is used for the
polygon color
More than one option can be specified by using the "or" ("|") operator.
Note: If no options are to be used, specify the "No_Option" macro. To perform light
source calculations when the polygon color is in palette format, use both "UsePalette"
and "UseLight".
Supplement. SGL Library Functions Covered in this Chapter
The functions listed in the following table were explained in this chapter.
Table 7-7 SGL Library Functions Covered in this Chapter
Function type
Function name
Parameters
Function
void
slDMACopy
src, dst, cnt
CPU DMA blook transfer
background image

Programmer's Tutorial / Demonstration Program C: Walking Akira
D-C-1
[Demonstration Program C: Walking Akira]
demo_C
Demonstration program C depicts animation of a walking human model. The model is the
virtual fighter Akira.
Akira consists of 22 polygon objects, each part of a hierarchical structure as shown in the
following diagram.
Fig C-1 Akira's Hierarchical Structure
Akira is facing you
Head
Face
Neck
Right
shoulder
Right
arm
Right
hand
Right thumb
Right fingers
Left
shoulder
Left
arm
Left
hand
Left thumb
Left fingers
Chest
Abdomen
Hips
Right
thigh
Left
thigh
Right
lower
leg
Left
lower
leg
Right
foot
Left
foot
By supplying angle data between each set of parent-child objects, it is possible to create
"joints." By changing this angle data, it is possible to make Akira move. The angle data
between each set of parent-child objects is called "motion data."
background image

Programmer's Tutorial / Demonstration Program C: Walking Akira
D-C-2
This program uses normal 3D animation tools to create the complex motion data needed to
model human movement.
Flow Chart C-1 Main Process
START
Initialize system
Initialize motion
counter
Set up camera
Right arm
processing
Right thigh
processing
Right lower leg
processing
Left lower leg
processing
Right shoulder
processing
Hips processing
Chest processing
Head processing
Set up light
source
Set Akira's
position
Right hand
processing
Left ankle
processing
Left shoulder
processing
Left arm
processing
Right ankle
processing
Update motion
counter
Left thigh
processing
Update walking
position
Abdomen
processing
Left hand
processing
background image


Programmer's Tutorial / Demonstration Program C: Walking Akira
D-C-3
Flow Chart C-2 Main Processing
END
END
END
END
Save unit matrix
to stack
Set up light
source
Ankle processing
Shift polygon data
Y-, X-, and Z-axis
rotation
Call temporarily
stored matrix
Rotate ankles around
Y, X, and Z axes
Draw polygons
Shift to next
center position
Set current
position
Rotate Y, X, and Z axes
into alignment with
center of Akira
Rotate polygons
around Y, X, and Z axes
Convert non-parallel
shift portion of current
matrix to a unit matrix
Copy to current
matrix
World coordinates
Get result of unit
vector multiplied
by current matrix
Set up light
source
Draw polygons
Set walking
direction
Processing of
individual parts
Determination of
Akira's position
Get result of walking
speed multiplied by current
matrix as next position
Save unit matrix
to stack
Call temporarily
stored matrix
Get current
matrix
background image

Programmer's Tutorial
8
Scrolls
"Scrolls" are 2D graphics used for game backgrounds and text
display. In addition to scrolls, the SGL also has "sprites," which
also use 2D graphics. Sprites, however, are primarily used to
represent moving objects, while scrolls are used to express
stationary objects.
Fig 8-1 Example of Using a Scroll
c) Actual graphics
a) Scroll (background)
b) Object (moving object)
Note: In this example, the scroll is displayed behind the polygon.
background image

8-2
Programmer's Tutorial / Scrolls
Scrolls in SGL
The SGL permits the overlapping display of multiple scroll layers on a single screen. For
example, it is possible to display a text display scroll layer in front, a polygon layer in the
middle, and a background scroll layer in the rear.
The stacked drawing of graphics elements in this manner is controlled through "priority," and it
is possible to specify a priority for individual scroll, sprite, and polygon display layers. (For
details on priority, refer to "Priority.")
Fig 8-2 Screen Configuration Example
b) Actual graphics
Rear of screen
Front of screen
Background scroll layer
3D graphics layer
Text display scroll layer
1) Text display scroll layer
2) 3D graphics layer
3) Background scroll layer
a) Priority sequence
background image


Programmer's Tutorial / Scrolls
8-3
Scroll Configuration Units
Scrolls are collections of the very fine dots that make up the monitor screen. In order to use
these dots efficiently, the scroll unit system illustrated below has been adopted in the SGL.
An 8
8 group of dots is called a "cell;" in our discussion of the handling of scrolls, the cell
will be the minimum unit of dots. Groups of cells form character patterns, groups of character
patterns form pages, groups of pages form planes, and groups of planes form a map.
Fig 8-3 Scroll Screen Configuration Units
Note:All sizes are given as horizontal
vertical.
Cell
Character
pattern
Page
Plane
Map
8
8 dots
1
1 cell or
2
2 cells
64
64 cells;
in other words,
32
32 characters
or 64
64 characters
1
1 page or
1
2 pages or
2
2 pages
Normal scroll screen: 2
2 planes
Rotating scroll screen: 4
4 planes
Note: Scroll Configuration Units
Although the Sega Saturn hardware includes functions for handling scrolls not in cell
units, but in dot units (called bit-mapping), these functions are not discussed in this
manual.
However, the SGL library does include several functions that support scroll functions
that include bit-mapping, and a simple explanation of this group of functions has been
added to the function reference that comes with the Reference Manual.
For details on the several functions that include a bit-map mode, refer to "HARD-
WARE MANUAL vol. 2" and to the "Function Reference" of the Reference Manual.
background image

8-4
Programmer's Tutorial / Scrolls
Screen Modes
The screen mode determines settings such as the screen resolution, the screen size, and the
display device. Although the Sega Saturn system supports a large number of screen modes, of
these, the SGL supports the following 16 screen modes.
Table 8-1 Screen Modes
Display device
TV screen mode
Graphics mode
Interlace mode
Resolution: horizontal
vertical
(pixels)
NTSC system
Normal
Graphics A
Non-interlaced
320
224
320
240
Interlaced
320
448
320
480
Graphics B
Non-interlaced
352
224
352
240
Non-interlaced
352
448
352
480
Interlaced
Graphics A
Non-interlaced
640
224
640
240
Interlaced
640
448
640
480
Graphics B
Non-interlaced
704
224
704
240
Interlaced
704
448
704
480
Note: The default screen mode is 320
224 (horizontal
vertical)
For details on screen modes, refer to "HARDWARE MANUAL vol. 2: VDP2," page 12.
In the SGL, the library function "slInitSystem" is to initialize scrolls, set the screen mode, etc.
The function "slInitSystem" also initializes and makes the initial settings for elements other
than scrolls at the same time. For details, refer to the default list at the end of the "Function
Reference" of the Reference Manual.
[void slInitSystem (Uint16 type, TEXTURE *texptr, Uint16 cnt);]
This function initializes settings, including those for scrolls, sets the screen mode, and sets
the graphics processing units. For the parameters, substitute the "#define" value indicating
the screen mode, the starting address in memory where texture data is stored ("NULL" if
textures are not to be used), and an integer value (from 1 to 127) that indicates the screen
processing unit. The default screen mode is the mode with a resolution of 320
224 (hori-
zontal
vertical) pixels.
In addition, TV monitors are not able to completely display 352
240 mode because they do
not offer adequate resolution; 352
240 mode can only be fully displayed on monitors that
accept RGB input.
background image

Programmer's Tutorial / Scrolls
8-5
Table 8-2 "slInitSystem" Parameter Substitution Example (TV_MODE)
Resolution (pixels)
320 (hor.)
224 (ver.)
352 (hor.)
240 (ver.)
Substitution value
TV_320
224
TV_352
240
Note: The values in the above table are defined by "sl_def.h".
To specify resolution of 320
224 pixels, no texture, and a drawing processing unit of 1 (1/60
second), the function "slInitSystem" would appear as follows:
Fig 8-4 Example of Using the Function "slInitSystem"
slInitSystem(TV_320x224,NULL,1);
System Initialization
Drawing processing unit: 1 (1/60 second)
Resolution: 320
224 pixels
No texture
Note: Drawing processing unit
The drawing processing unit parameter specifies the interval for updating (rewriting)
the image.
In the SGL, the range of values that can be set is from 1 to 127, with 1 drawing process-
ing unit equaling 1/60 of a second in non-interlaced mode and 1/30 of a second in
double interlaced mode.
The longer the update interval is, the more operations that can be processed, but
because the interval is long moving images will appear jerky.
On the other hand, the shorter the interval is, smooth image movement can be ob-
tained, but the amount of processing that can be performed at one time decreases.
As shown by the examples in the
table at left, the screen mode can
be specified by using a macro in the
form "TV_(horizontal pixels) x
(vertical pixels)" in accordance with
the desired resolution mode.
background image



8-6
Programmer's Tutorial / Scrolls
Scroll Screens
In the Sega Saturn system, up to five scroll screens can be displayed simultaneously on one
screen. There are two types of scroll screens: normal scroll screens and rotating scroll screens;
in addition, there are four types of normal scroll screens. The SGL permits these five types of
scroll screens to be output to the monitor at the same time.
The following table summarizes the scroll screen types and summarizes their primary functions.
(For details on the scroll functions and how to set them, refer to "Scroll Function settings.")
Table 8-3 Scroll Screens
Scroll screen name
Abbre-
viation
Function
Remarks
Movement
Enlarge-
ment/
reduction
Normal scroll
screen
Rotating scroll
screen
Normal
scroll 0
Normal
scroll 1
Normal
scroll 2
Normal
scroll 3
Rotating
scroll 0
Rotation
Number of colors
that can be dis-
played
NBG0
NBG1
NBG2
NBG3
RGB0
q
q
q
q
q
q
q
q
q
16.77 million colors
32.768 colors
256 colors
256 colors
16.77 million colors
Enlargement
setting ranges
from 1/4 to 256x
Enlargement
setting can be as
desired
Note: For details on the scroll functions, refer to the section on scroll functions.
The maximum number of colors that can be set and the enlargement/reduction functions differ
among the normal scroll screens "NBG0 to 3". (For details, refer to "Scroll Functions.")
In the default state, the scroll screens permit 256 colors.
Note: Limitation on the number of scroll screens
Although the maximum number of scroll screens that can be output simultaneously is
five, that does not mean that it is always possible to output five screens. Because there
is a limit on the maximum number of accesses that can be made during one processing
interval to VRAM, where the scroll data is stored, there are a number of limitations
placed on scroll drawing.
For details, refer to the "HARDWARE MANUAL vol. 2:VDP2," pp. 31 to 42.
background image


Programmer's Tutorial / Scrolls
8-7
Storing Scroll Data in Memory
This section explains the different types of scroll data and the methods for storing each type of
scroll data in memory.
Scroll data types
In the SGL, there are three major types of scroll data that differ according to the information
that they contain.
1) Character pattern data: Character pattern dot information
(This type of data is sometimes abbreviated as "CG" within the text.)
2) Pattern name data: Character pattern identification and placement information
(This type of data is sometimes abbreviated as "PN" within the text.)
3) Color palette data: Color data when using a color palette
In terms of the scroll screen configuration units described in "Scroll Configuration Units", the
type 1 information contains information in dot units for the character pattern level, while type 2
contains the placement information for character patterns at the page level and beyond. Data of
type 1 and 2 is stored in an area in memory called VRAM and the actual image is drawn by
accessing the area and reading data in.
The type 3 information is palette-format color information used in scrolls. "Palette format" is a
color setting system that uses 16, 256, or 2048 (or, for some settings, 1024) colors as a single
palette for character pattern units. A color palette consists of three types of data:
Individual color RGB data:
stored in color RAM
Identification numbers for colors within the palette:
used within the character pattern data
Identification numbers for individual palettes:
Used within the pattern name data
The color palette data is stored in an area of memory called color RAM, and the actual image is
drawn by accessing the area and reading data in.
background image

8-8
Programmer's Tutorial / Scrolls
Storing scroll data in VRAM
VRAM is the general name for the data storage area used to store graphic data, such as scrolls.
In the SGL, VRAM is divided into four partitions. Each area is named VRAM-A0, -A1, -B0,
and -B1, and the various types of scroll data are stored in these four data areas called "banks."
Because the Sega Saturn system has a VRAM capacity of 4 megabits, the VRAM capacity of
each bank is 1 megabit.
Drawing of actual images is accomplished by accessing these four data banks and reading in
data. The following diagram shows the VRAM addresses.
Fig 8-5 VRAM Address Map
VRAM capacity: 4 megabits
VRAM-A0
VRAM-B0
VRAM-A1
VRAM-B1
0x25e00000
0x25e1FFFF
0x25e20000
0x25e3FFFF
0x25e40000
0x25e5FFFF
0x25e60000
0x25e7FFFF
1 megabit
1 megabit
1 megabit
1 megabit
In the SGL, scroll information is stored in these four banks, and scroll screens are drawn on the
actual screen by calling the data from these banks.
In the sample program, the data storage operation is performed by two functions, "Cel2VRAM"
and "Map2VRAM" (registered in the program).
These functions are not supported as library functions; use them as a reference.
[void Cel2VRAM (cel_adr, VRAM_adr, chara_size);]
This function stores character pattern data in VRAM.
For the parameters, substitute the starting address in memory where the character pattern is
currently stored, the starting address in VRAM where the character pattern data is to be
stored, and the amount of character pattern data.
[void Map2VRAM (pat_adr, VRAM_adr, mapY, mapX, pal_off, map_off);]
This function stores the pattern name data in VRAM.
For the parameters, substitute the starting address in memory where the pattern name table is
currently stored, the starting address in VRAM where the pattern name data is to be stored,
the vertical and horizontal size of the map in cells, the offset for the color palette to be used
next, and the map data offset.
background image

Programmer's Tutorial / Scrolls
8-9
Notes on storing data in VRAM (1)
Due to hardware limitations, there are a number of restrictions that apply to the storing of scroll
data in VRAM banks as described above.
Although the details of these restrictions will not be discussed here, the following two points
should be observed:
1) Priority of VRAM bank usage according to scroll type:
Do not store scroll data for normal scroll screens and rotating scroll screens in the same
VRAM bank.
2) Restriction on storing pattern name data in VRAM banks:
All of the pattern name data can only be stored in two of the four VRAM banks, in one of
either VRAM_A0 and B0, and one of either VRAM_A1 and B1.
Fig 8-6 Restriction on Storage of Pattern Name Data in VRAM Banks
PN: pattern name data
VRAM-A0
VRAM-B0
VRAM-A1
VRAM-B1
PN can be specified
for only one of
A0 and B0
PN can be specified
for only one of
A1 and B1
If these restrictions are not observed, the drawing of scrolls will be affected in the following
ways:
If restriction 1 is not observed:
Due to the priority of usage of the VRAM banks, the normal scroll screen data will be
ignored, and only the rotating scroll screen data will be valid.
If restriction 2 is not observed:
If the pattern name data is stored in VRAM banks with the same digit at the ends of their
names, the scrolls will either not be drawn properly or will not be drawn at all.
Note: PN storage restrictions
For details on PN storage, restrictions, refer to "SEGA SATURN HARDWARE MANUAL
vol. 2." (VDP2 User's Manual: p. 35)
background image

8-10
Programmer's Tutorial / Scrolls
Notes on storing data in VRAM (2)
The following notes on data storage concern the SGL initial settings.
In the default state of the SGL, the ASCII cells, which are the scroll data (including color data)
used for displaying letters and numerals, are already stored in memory.
If the ASCII scroll data stored in the default state is overwritten by other scroll data, the SGL
functions that display letters and numerals can no longer be used properly.
The ASCII scroll consists of 128 cells and 256 colors, and uses the normal scroll "NBG0".
The ASCII scroll data is stored in RAM as follows:
Fig 8-7 ASCII Scroll Data Storage Area
VRAM-A0
VRAM-B0
VRAM-A1
VRAM-B1
CRAM
0x25e00000
0x25e40000
0x25e20000
0x25e60000
0x25f00000
0x25e7FFFF
0x25f00FFF
CEL_DATA: 0x25e60000 - 0x25e61FFF
2000H
MAP_DATA: 0x25e76000 - 0x25e76FFF
1000H
CAL_DATA: 0x25f00000 - 0x25f0001F
20H
Character data: For 2000H, starting from address 0x25e60000
Map data:
For 1000H, starting from address 0x25e76000
Palette data:
For 20H, starting from address 0x25ef0000
If the ASCII scrolls are to be used, specify offsets when storing scroll data so that the scroll data
is not written to the above regions.
background image

Programmer's Tutorial / Scrolls
8-11
Color RAM
Color RAM is used to control color for all palette-type sprites and scroll screens. Depending on
the color RAM, the color data consists of either five bits or eight bits for each of red, green, and
blue.
The following table shows the three color RAM modes:
Table 8-4 Color RAM Mode
Color mode
Color bits
Data size
Number of colors
Mode 0
15 bits; 5 bits each for R, G, and B
1 word
1024 colors out of 32,768
Mode 1
15 bits; 5 bits each for R, G, and B
1 word
2048 colors out of 32,768
Mode 2
24 bits; 8 bits each for R, G, and B
2 words
1024 colors out of 16.77 million
Note: In color mode 0, color RAM is partitioned into two banks, each storing the same color data.
The color RAM modes utilize color RAM as shown in the following diagram:
Fig 8-8 Color RAM Address Map
0x25f00000
0x25f00000
0x25f00000
0x25f00FFF
0x25f00FFF
0x25f00FFF
16 bits
1024 colors
16 bits
2048 colors
32 bits
1024 colors
Same color data
a) Mode 0
b) Mode 1
b) Mode 2
The color RAM modes are selected and used in the following circumstances:
Color RAM mode 0: Used when using extended color operation functions
Color RAM mode 1: Used when 2048 colors out of 32,768 colors are desired
Color RAM mode 2: Used when 1024 colors out of 16,77 million colors are desired
As Fig 8-8 makes clear, in color RAM mode 0, the color RAM area is partitioned into two
banks, each containing the same color data. As a result, while the number of colors that can be
used is only half that of color RAM mode 1, this configuration does permit the use of extended
color operation functions.
background image


8-12
Programmer's Tutorial / Scrolls
Note: However, extended color operation mode is not supported in the current version
of the SGL. To use the extended color operation mode, refer to the "HARDWARE
MANUAL vol. 2."
The difference between modes 1 and 2 is the number of colors that can be used.
Mode 1 permits 2048 colors to be selected from among 32,768; mode 2 permits 1024 colors to
be selected from among 16.77 million colors. As a result, while mode 1 permits the use of more
colors, because the data length is shorter than in mode 2, the gradations between colors in mode
1 are coarser than in mode 2.
On the other hand, while only half as many colors can be used in mode 2 as in mode 1, the
longer data length in mode 2 permits the choice of finer gradations.
The library function "slColRam" is used to set the color RAM mode.
[void slColRAMMode (Uint16 mode)]
This function sets the color RAM mode.
For the parameter, substitute a #define value from the following table corresponding to the
desired color RAM mode.
Table 8-5 slColRAMMode Parameter Substitution Values
Color RAM mode
Mode 0
Mode 1
Mode 2
Substitution value
CRM16_1024
CRM16_2048
CRM32_1024
Note: 2048 colors can be used only when color RAM mode 1 is selected.
Initial color RAM setting:
When the system is initialized, color RAM mode 1 is set.
Storing data in color RAM
In the SGL, color information (color palette information) is stored in color RAM, and scroll
screens can be drawn by calling out the data when needed.
In the sample program, the color data storage operation is performed by the "Pal2CRAM"
function (registered in the program). This function is not supported as a library function; use it
as a reference.
[void Pal2CRAM (col_adr, CRAM_adr, col_no.);]
This function stores the color information (color palette information) in the color RAM.
For the parameters, substitute the starting address in memory where the color palette to be
registered is currently stored, the starting address in color RAM where the palette is to be
stored, and the size of the color palette.
background image


Programmer's Tutorial / Scrolls
8-13
Scroll Function Settings
This section explains the method for setting up scrolls, starting from character units and con-
tinuing on up to map settings. In the SGL, the scroll functions (number of character colors,
character size, etc.) are set at each stage of scroll setup.
The following table lists the scroll functions.
Table 8-6 Scroll Functions List
Function
Normal scrolls
Rotating scrolls
NBG0
NBG1
NBG2
NBG3
RBG0
Number of character
Select 16, 256,
Select 16, 256,
Select either 16
Select either 16
Select 16, 256,
2048*, 32,768,
2048*, or 32,768 or 256 colors
or 256 colors
2048*, 32,768, or
or 16.77 million
colors
16.77 milion
colors
colors
Character size
Select either 1 (hor.)
1 (ver.) cell, or 2 (hor.)
2 (ver.) cells
Pattern name data size Select either 1 word or 2 words
Plane size
Select either 1 (hor.)
1 (ver.) page, 2 (hor.)
1 (ver.) pages, or 2 (hor.)
2 (ver.) pages
Number of planes
4
4
4
4
16
Enlargement/
1/4 to 256x
No
Any ratio
reduction function
Rotation function
No
Yes
Note: 2048 (marked by an asterisk) is available as a choice when color RAM mode 1 is in effect. If mode
0 or mode 2 is in effect, 1024 is available as a choice instead.
VRAM access restrictions
The list of functions shown in Table 4-6 above is a list of possible functions for each
scroll screen. This does not mean that when actually using these scroll screens in a
program all of these functions will be available for use with every scroll screen. There
is also no guarantee that it will be possible to draw all scroll screens at the same time.
This results from limitations on VRAM access that restrict the number of scroll screens
that can be used at one time and the setting of the functions.
For details on the access limitations, refer to the "HARDWARE MANUAL vol. 2"
(VDP2 User's Manual: pp. 31 to 42).
In addition to the VRAM access specification limitations, there are also scroll drawing
restrictions that are founded in the setting of the number of characters for normal
scroll screens NBG0 to 3. (Refer to the section on character patterns.)
Therefore, the number of scroll screens that can be drawn simultaneously and their
functions are limited and determined by the two types of restrictions indicated above.
colors
background image

8-14
Programmer's Tutorial / Scrolls
Character patterns
Character patterns are square patterns consisting of 1
1 cell or 2
2 cells, and are used to
store information (such as the dot drawing color) for individual dots. In the SGL, units of
character pattern information called "data tables" are stored and accessed as needed in VRAM.
This is also the level at which the number of colors for each character in the scroll screen is
specified. In addition, when one character consists of four cells, it is necessary to store the cell
data used within one character pattern so that the cell data is continuous within the character
pattern table.
Fig 8-9 Character Patterns
c) Character pattern table
Cell data 0
8 dots
8 dots
Cell data 0
Cell data 2
Cell data 1
Cell data 3
Cell data 0
Cell data 4
Cell data 2
Cell data 1
Cell data 3
16 dots
16 dots
Starting address
When the character pattern
consists of four cells, the cell
data used within the same character
pattern must be stored consecutively.
a) 1
1 cell
b) 2
2 cell
Table 8-7 Number of Character Colors
Color format
Number of
Number of bits per dot
Number of colors that can be used on
character colors
each screen
NBG0
NBG1
NBG2
NBG3
RBG0
Palette format
16 colors
4 bits
q
q
q
q
q
256 colors
8 bits
q
q
q
q
q
2048 colors
16 bits
q
q
q
(only low-order 11 bits are used)
RGB format
32,768 colors
16 bits
q
q
q
16.77 million colors
32 bits
(only MSB and low-order 24 bits
q
q
are used)
Note: For color RAM modes 0 and 1, "2048 colors" changes to "1024 colors."
In the SGL, use the library functions "slCharNbg0 to 3" and "slCharRbg0".
[void slCharNbg0 to 3 (Uint16 color_type, Uint16 char_size);]
[void slCharRbg0 (Uint16 color_type, Uint16 char_size);]
These functions specify the number of character colors and character size for each scroll
screen (indicated by the scroll screen name that follows "slChar"). For the parameters,
substitute the "#define" value that corresponds with the number of colors and character size
according to the following chart. Note, however, that on some scroll screens there are limits
on the number of colors that can be used. (Refer to "Scroll Function List.")
Number of
character colors
background image



Programmer's Tutorial / Scrolls
8-15
Table 8-8 Parameter Substitution Values for slCharNbg0 to 3 and slCharRbg0
Number of character colors
Palette format
RGB format
Character size
16 colors
256 colors
2048 colors
32,768 colors
16.77 million colors
1
1
2
2
Substitution value
COL_TYPE_16
COL_TYPE_256
COL_TYPE_2048 COL_TYPE_32768
COL_TYPE_1M
CHAR_SIZE_1
1
CHAR_SIZE_2
2
Note 1: For color RAM modes 0 and 1, "2048 colors" changes to "1024 colors."
Note 2: The values in the above table are defined in "sl_def.h", which is included with the system.
Scroll limitations due to the number of character colors
A restriction may be placed on the number of scroll screens that can be output, depending on
the number of colors set for normal scroll screens NBG0 and NBG1.
These restrictions are summarized in the following table:
Table 8-9 Scroll Screen Restrictions Due to Number of Character Colors
Number of colors for NBG0 and NBG1
Effective scroll screens
NBG0
NBG1
NBG0
NBG1
NBG2
NBG3
16.77 million colors
*
q
2048 or 32,768 colors
*
q
q
q
*
2048 or 32,768 colors
q
q
q
2048 or 32,768 colors
2048 or 32,768 colors
q
q
Note: An asterisk represents selection of 256 colors or less
If the NBG0 setting is 16.77 million colors, NBG1 to 3 cannot be displayed.
If the NBG0 setting is 2048 colors or 32,768 colors, then NBG2 cannot be displayed.
If the NBG1 setting is 2048 colors or 32,768 colors, then NBG3 cannot be displayed.
Scroll restrictions due to VRAM access
In the Sega Saturn system, there are other restrictions on scroll screens due to VRAM
access as a result of hardware performance.
These restriction apply in addition to the restrictions arising from the number of
character colors on the normal scroll screen. In particular, when the reduction setting
is made for a normal scroll screen and when the rotating scroll screen is used, the
number of scroll screens that can be drawn is markedly restricted on top of the restric-
tions due to the number of character colors.
For details on access restrictions, refer to the "HARDWARE MANUAL vol. 2" (VDP2
User's Manual: pp. 31 to 42).
background image

8-16
Programmer's Tutorial / Scrolls
Pattern name data
Pattern name data is data generated from dot unit data created as a character pattern, particularly
by extracting the two kinds of information indicated below.
Character number: The starting address of the character pattern (VRAM); 20H is stored for the
character pattern as one unit.
Palette number:
Palette number of the color palette to be used (color RAM).
In addition to the above two types of information, the pattern name data in its final form also
consists of the following two types of function control bits concerning the character pattern.
Special function bits (two bits): Control special function operations and special priorities.
Reverse function bits (two bits): Control top-bottom, left-right reversal of the character pattern.
However, there are some instances where the special function bits and reverse function bits are
not added to the pattern name data. This is because, depending on the pattern name data type
(described later), the number of bits used in the pattern name data changes.
The following figure is a conceptual model of the pattern name data. The details of the pattern
name data types are described in the next section.
Fig 8-10 Pattern Name Data Concept
a) 1-word type: character number bits are the 10 low-order bits (reversal function bits present)
b) 1-word type: character number bits are the 12 low-order bits (reversal function bits not present)
c) 2-word type: character number bits are the low-order 16 bits
15
11
13
9
5
7
3
1
14
10
12
8
4
6
2
0
bit
Palette number
Reversal
function
Character number
15
11
13
9
5
7
3
1
14
10
12
8
4
6
2
0
bit
Palette number
Character number
15
11
13
9
5
7
3
1
14
10
12
8
4
6
2
0
bit
Character number
31
27
29
25
21
23
19
17
30
26
28
24
20
22
18
16
bit
Special
function
Reversal
function
Palette number
Not used
Pattern name data is used when setting up pages; pattern name data tables are created as a group
of 64
64 continuous pattern name data entries, and are then passed to the plane and map
placement information.
background image


Programmer's Tutorial / Scrolls
8-17
Pattern name data types
There are two types of pattern name data: 1-word and 2-word.
The 1-word type is further broken down into two types, according to the number of information
bits used for character identification. (There are either 10 or 12 pattern identification bits.)
Each data type has its advantages and disadvantages; in the SGL, one of these three data types
must be selected and used.
Table 8-10 Pattern Name Data Sizes
*Word size
Number of character number bits
Remarks
1-word
10 low-order bits
The reversal function can be specified for individual characters
12 low-order bits
The reversal function cannot be used
2-word
15 low-order bits
The reversal function can be specified for individual characters
*: The 1-word size is recommended for the SGL.
1-word pattern name data is divided into two types, depending on whether or not two reverse
function bits are inserted into the pattern name data.
As its name indicates, the character pattern reversal function is used to control and execute top-
bottom and left right reversal of the corresponding character pattern. This control requires the
allocation of two reversal function bits in the pattern name data.
In the case of 1-word pattern name data, the reversal function bits are always allocated, but in 1-
word pattern name data, because there are only a limited number of bits available for use, if the
reversal function bits are allocated then the number of character patterns that can be identified is
reduced by an amount corresponding to the two bits. As a result, there are two types of 1-word
pattern name data distinguished by whether the reversal function bits are used or not, or by the
difference in the number of character patterns that can be identified.
The difference between the 2-word type and the 2-word type is simply the number of character
patterns that can be processed. However, the amount of memory used by the 2-word type is
double that used by the 1-word type; in addition, while offsets can be specified with the 1-word
type, the absolute address must be specified with the 2-word type. Therefore, from the stand-
point of ease of use, in the SGL the use of the 1-word type is recommended.
Supplemental data
When using 1-word pattern name data, not all of the pattern name data can be speci-
fied. Therefore, the system provides the 10 low-order bits of the pattern name data
control register to supplement the pattern name data. This is called "supplemental
data."
For details, refer to the "HARDWARE MANUAL vol. 2: VDP2," pp. 69 to 78.
background image

8-18
Programmer's Tutorial / Scrolls
Pages
A page is a square covered with 64
64 character pattern cells. The actual data format consists
of a table of the pattern name data for each character pattern for all 64
64 cells, stored con-
secutively in memory. This table is called the pattern name data table.
The pattern name data table created when the page is set up is passed to the plane or map that
the page belongs to and is then rearranged.
Fig 8-11 Page Image
b) Pattern name data table image
Character pattern
Page
64 cells
64 cells
64
64 = 4096
PN
PN0
PN4094
PN1
PN4095
Pattern name data
Pattern name data table
a) Page image
In the SGL, the library functions "slPageNbg0 to 3" and "slPageRbg0" are used for each scroll
screen to set up pages.
[void slPageNbg0 to 3 (void *cell_adr, void *col_adr, Uint16 data_type);]
[void slPageRbg0 (void *cell_adr, void *col_adr, Uint16 data_type);]
These functions set up pages (pattern name data tables).
For the parameters, substitute the starting address of the character patterns to be used, the
starting address of the color palette to be used (offset specification is possible in the case of
1-word type data), and the pattern name data type specification (refer to the following table
for the parameter substitution value).
Table 8-11 slPageNbg0 to 3, Rbg0 Parameter Substitution Values (data_type)
Number of words
Character number bits
Substitution value
1-word
10 low-order bits
PNB_1WORD
12 low-order bits
PNB_1WORD
CN_12BIT
2-word
15 low-order bits
PNB_2WORD
Note: The values in the above table are defined by "sl_def.h".
background image

Programmer's Tutorial / Scrolls
8-19
An example of an actual page setup specification and a list of the #define values used in the
page setting parameters are shown below.
Fig 8-12 "slPageNbg0 to 3", "slPageRbg0" Parameter Setting Example
slPageNbg0(NBG0_CELL_ADR, 0, PNB_1WORD | CN_10BIT);
Character pattern starting address
Palette starting address (offset specification)
Word count specification
Character number bit specification
List 8-1 #define Values for the Page Setting Parameters
/* VRAM_BANK ADDRESS */
#define
#define
#define
#define
/* slPage */
#define
#define
#define
#define
/* others */
#define
VDP2_VRAM_A0
VDP2_VRAM_A1
VDP2_VRAM_B0
VDP2_VRAM_B1
PNB_2WORD
PNB_1WORD
CN_10BIT
CN_12BIT
NBG_CELL_ADR
0x25e00000
0x25e20000
0x25e40000
0x25e60000
0
0x8000
0
0x4000
VDP2_VRAM_B0
Define values used in the page setting parameters
Note: These #define values are defined in "sl_def.h".
background image

8-20
Programmer's Tutorial / Scrolls
Planes
Planes consist of pages in a 1
1, 2
1, or 2
2 (horizontal
vertical) arrangement. When a
plane consists of multiple pages, the page data (pattern name data tables) must be stored con-
secutively in VRAM.
The plane data is passed up to the map and rearranged.