1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
|
<xml>
<head>
<title>ClanLib Tutorial: Design of ClanLib</title>
</head>
<body>
<a href="basics.html"><img src="Images/prev.gif"></a>
<a href="index.html"><img src="Images/toc.gif"></a>
<a href="advanced.html"><img src="Images/next.gif"></a>
<h3>THIS TUTORIAL IS OUTDATED, PLEASE DO NOT USE!</h3>
<h2> Introduction </h2>
This chapter will give a brief description of the ideas behind ClanLib. This is
basic knowledge needed to comprehend the examples.
<ul>
<li> <a href="#basic">Basics</a>:<br>
The available libraries, CL_ClanApplication class
<li> <a href="#2dgraphics">2D Graphics</a>:<br>
Using basic 2d graphics
<li> <a href="#sound">Sound</a>:<br>
Using sound in your game
<li> <a href="#resourcemanager">Resourcemanager</a>:<br>
Using resources
<li> <a href="#input">Input</a>:<br>
Using keyboard, mouse and joystick input
<li> <a href="#network">Network</a>:<br>
Making you game network-aware
</ul>
<a name="basic"></a>
<h2> Basic </h3>
<a name="basic_libraries"></a>
<h4> Libraries </h4>
As explained in the previous chapter, ClanLib exists of several libraries:
<ul>
<li> <b>clanCore</b>
Basic functions, 2d and sound support.
<li> <b>clanGL</b>
Support for OpenGL, 3d functions and texture loading.
<li> <b>clanMikMod</b>
Support for soundmodules (.mod, etc )
<li> <b>clanPNG</b>
Support for loading PNG files
<li> <b>clanLua</b>
Support for the scripting language Lua
<li> <b>clanMPEG</b>
Support for playing and loading MPEG movies
<li> <b>clanGUI</b>
Support for Graphical User Interfaces, being developed at the moment
</ul>
<a name="basic_clanapplication"></a>
<h4> The CL_ClanApplication class </h4>
All ClanLib applications must be derived from the CL_ClanApplication class. This is
because the different targets on which ClanLib runs have different needs and
initialisation code. If you derive your application using this class, you do not
have to worry about these things, it is all hidden by this class. <br>
You need to do some initialization of the libs you would like to use here,
too. This will be explained in more detail in the next chapter.
<a name="2dgraphics"></a>
<h3> 2D Graphics </h3>
<a name="2dgraphics_displays"></a>
<h4> Displays </h4>
The CL_Display class is used to communicate with the videocard(s) in the system. It
contains a list of CL_DisplayCard classes, one for each videocard. Furthermore, all
function calls to CL_Display will be done to the primary card. This way, you don't
have to worry about systems having more than one videocard. It is also possible to
select a different videocard on which CL_Display operates by default. Every display
runs in a videomode. A videomode is described by the CL_VidMode class and contains
the width and the height of the screen in pixels, and the bits per pixel (bpp).
<br>
At this moment ClanLib does not support palette modes. As most modern games use
true color modes, it is not likely that it will be included in ClanLib, unless
you're willing to do it yourself ;)
<a name="2dgraphics_surfaces"></a>
<h4> Surfaces </h4>
ClanLib hides the pixelformat you're working in. As a programmer you probably don't
want to convert palettebased images to truecolor, and between the truecolor formats
themselves. So, what ClanLib does is this: You supply an image with an
SurfaceProvider. This image is then loaded and converted to an internal
representation of the image. This depends on the videomode you're working in. The
data is stored in a CL_Surface and can be blitted very fast. To complicate (and
speed up) things even more: Some of the data is stored on the videocard, others in
normal memory. This way the programmer need not worry about the actual mode the
Display is running in and still get a good performance. ClanLib provides several
SurfaceProviders for different formats such as PCX, Targa, MPEG movies etc.
For a complete list, see the reference manual.
<br>
A surfaceprovider can be true-color or palette-based, depending on the type of data
it holds. Although ClanLib does not support palettized displays, it can use
palette-based surfaceproviders. These will get converted into the display's native
target.
<br>
A disadvantage of this system is doing image manipulations like putpixel and
getpixel actions. If you want to do a putpixel(), you have two options:
<br>
<ul>
<li> Provide a new image with the changed pixel using a CL_SurfaceProvider,
load it into a CL_Surface and blit the surface. This means translating
the whole image again and is probably not what you want.
<li>Access the CL_Surface data and modify it there. Beware: the format
surfp->get_data() is in depends on the videomode you're in. In the worst
case you've to write functions for several formats. Also, as far as I
know, the data is for some part (the alphapart) RLE-compressed to allow
for faster blitting.
</ul>
To overcome this problem, ClanLib has a CL_Canvas class. Using this class you can
create a canvas using your own pixelformat (RGB656 for example, see <a
href="basics.html#2dgraphics_abbreviations">abbreviations</a> for more
details) and convert between them. For more details on the CL_Canvas class, see the
<a href="advanced.html#cl_canvas">advanced section.
<br>
<a name="2dgraphics_palette"></a>
<h4>Palettes</h4>
As mentioned earlier, displays and surfaces can be palette-based. See <a
href="basics.html#2dgraphics_aboutcolors">Basics</a> for a brief
discussion of palettes. ClanLib stores palette information in a CL_Palette class.
Each surface has its own palette if applicable.
<a name="2dgraphics_clipping"></a>
<h3>Clipping</h3>
Sometimes it is needed to specify a portion of a display, surface or image. The
CL_ClipRect allows you to specify a rectangle or some other user-defined area. All
pixels in this rectangle will be used, all others outside the rectangle will be
discarded. These clipping regions can be pushed and popped onto a CL_Surface and
then become active.
<a name="sound"></a>
<h3> Sound </h3>
This will explain how to use soundeffects and music in your game.
<a name="sound_cards"></a>
<h4> Using soundcards </h4>
ClanLib communicates with the soundcards using the CL_SoundCard class. Just as with
2d graphics, there is a wrapperclass which will pick a default soundcard so you
don't have to do anything if you want to use just one of the available cards. This
class is called CL_Sound. These classes provide access to the main volume, the
panning register and to the microphone- and line-in.
<a name="sound_buffers"></a>
<h4> Using buffers </h4>
To provide a soundcard with music or sound, the CL_SoundBuffer class is used. This
class holds a buffer of the sound to be played, and possibly uploads it to the
soundcard. The data is held in a platform specific way. Compare this to the
CL_Surface class. The data is supplied by either a CL_StaticSoundProvider or a
CL_StreamSoundProvider, which hold platform independant information. For a
discussion of the differences between these, see <a
href="basics.html#sound_static_stream">Basics</a>. When a sound is
played, the CL_SoundBuffer class returns a CL_SoundBuffer_Session. Using this class
you can alter the way the sample is being played: stop, restart or change the
volume.
<a name="sound_envelopes"></a>
<h4> Envelopes </h4>
Sound has several properties like frequency, panning or volume. These are stored in
the CL_Envelope class. Each specific property is inherited to resp.
CL_SoundEnvelope_Frequency, CL_SoundEnvelope_Panning and CL_SoundEnvelope_Volume.
<a name="sound_looping"></a>
<h4> Looping </h4>
When you need to repeat a sound for some reason (like a backgroundmusic) you can
use looping.
<a name="resourcemanager"></a>
<h3> The Resourcemanager </h3>
<i> copied from the API reference </i>
<br>
When creating a game using many resources in the form of graphics, samples,
leveldefinitions etc., a structuring of this data becomes important. For this
purpose ClanLib includes a program called the DatafileCompiler that can store all
game resources in a single compressed file, thus hiding the names of the actual
filenames from the gameplayer, while saving space. When all resources are stored in
a single datafile (or several) containing all data used in the game, a method must
be devised for the game to locate a given resource inside the datafile. This could
of course be the name of the original file, but a descriptive string (a
resource-id) is more useful, as it separates the issue of file-names/locations from
the source code. In ClanLib all resources (graphics, samples, fonts, palettes,
raw-data) are mapped to resource-id's in a resource script file, interpreted inside
the game using the CL_ResourceManager class.
<a name="input"></a>
<h3> Input </h3>
This will discuss the classes ClanLib provides to communicate with the gamer.
Support for mouses, joystick and the keyboard will be explained.
ClanLib has several classes which communicate directly with the several
inputdevices. You can easily check if for example the 'x' button on the keyboard is
pressed.
<br>
However, in a more complex situation you'll find you need an abstraction to
input-devices. For example, when your coding your game you probably want to think
of a "fire-button". Which physical button this is isn't much of interest in the
greater part of the code. ClanLib support this kind of abstraction. You can create
a logical "fire"-button which actually represents one or more buttons on the
keyboard, mouse or joystick. The same holds for axis. If you use this abstraction
throughout your game, it is easy to let the gamer reassign the keys and use one or
more inputdevices.
<br>
Furthermore, there is a callback system in which you can let ClanLib call certain
functions when a key is pressed. This provides a different way to handle
input. This method is most commonly used with graphical user interface's and suchs.
<a name="network"></a>
<h3> Network </h3>
ClanLib has excellent functions and classes for network support. ClanLib has
functions which manage the creating, joing and exiting of a network game. The
CL_Network class encapsulates all these. A network game is set up using just one
tcp/ip socket, although the protocol used allows you to use more than one so-called
'NetChannels'. For the programmer these are almost the same as sockets, although
actually only one is used. The server can allow a client read, write or readwrite
access on a NetChannel. This way you have a more secure way of controlling what a
client may or may not do.<br> Note that ClanLib is not event-based. So, to check
for joining or leaving of clients you have to call a certain function.
<br>
Communication between objects on different machines can be done on two levels:
<ul>
<li> <b>lowlevel</b>
Writing and reading data to a channel. This way you have most
control of the datatraffic.
<li> <b>higher level</b>
Using NetObjects. These objects are network-aware and
the updating is done almost completely automatically.
</ul>
<p>
<a href="basics.html"><img src="Images/prev.gif"></a>
<a href="index.html"><img src="Images/toc.gif"></a>
<a href="advanced.html"><img src="mages/next.gif"></a>
</body>
</xml>
|
