summaryrefslogtreecommitdiff
path: root/doc/api.texi
blob: 4ea97fb3573c79be043bfea87ad80af96863b353 (plain)
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
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
@menu
* Kernel::                      The fundamental components.
* Input::                       Keyboard, mouse, and controller input.
* Math::                        Linear algebra and more.
* Graphics::                    Eye candy.
* Audio::                       Sound effects and music.
@end menu

@node Kernel
@section Kernel

At the very core of Chickadee, in the @code{(chickadee)} module, lies
an event loop.  This loop, or ``kernel'', is responsible for creating
and managing the game window, dispatching input events, ensuring that
the game is updated at the desired interval, and rendering graphics.
The kernel implements what is known as a ``fixed timestep'' game loop,
meaning that the game simulation will be advanced by a fixed interval
of time and will never vary from frame to frame, unlike some other
styles of game loops.  The appropriately named @code{run-game} and
@code{abort-game} procedures are the entry and exit points to the
Chickadee kernel.

On its own, the kernel does not do very much at all.  In order to
actually respond to input events, update game state, or draw something
to the game window, a hacker with a penchant for game development must
latch onto extension points built into the kernel, called ``hooks'',
and specify what action ought to be taken for any given event.  For
example, the @code{key-press-hook} can be used to respond to the
@code{a} key being pressed by swinging the player's mighty sword.
There are many hooks available, so read on to learn about all of them.
For information about using Guile's hook API, see @xref{Hooks,,,
guile, GNU Guile Reference Manual}.

@deffn {Scheme Procedure} run-game [#:window-title "Chickadee!"]
       [#:window-width 640] [#:window-height 480] [#:window-fullscreen? #f]
       [#:update-hz 60]
Start the event loop.  This procedure will not return until
@code{abort-game} is called.

The @code{update-hook} will be run @var{update-hz} times per second.

A new graphical window will be opened with @var{window-width} x
@var{window-height} as its dimensions, @var{window-title} as its
title, and in fullscreen mode if @var{window-fullscreen?} is
@code{#t}.
@end deffn

@deffn {Scheme Procedure} abort-game
Stop the currently running Chickadee event loop.
@end deffn

@deffn {Scheme Procedure} time
Return the current game time in milliseconds.
@end deffn

@defvr {Scheme Variable} load-hook
A hook that is run once when the event loop boots, before any other
hook is run.  This hook is run with zero arguments.

@example
(add-hook! load-hook (lambda () (display "hello!\n")))
@end example

@end defvr

@defvr {Scheme Variable} update-hook
A hook that is run every time the game simulation should be advanced.
This hook is run with a single argument @var{dt}, the fixed timestep
that was configured when the event loop was started, in milliseconds.

@example
(add-hook! update-hook (lambda (dt) (display "tick!\n")))
@end example

@end defvr

@defvr {Scheme Variable} before-draw-hook
A hook that is run before a frame is rendered.  This hook is run with
zero arguments.

@example
(add-hook! before-draw-hook (lambda () (display "about to draw!\n")))
@end example

@end defvr

@defvr {Scheme Variable} after-draw-hook
A hook that is run after a frame is rendered.  This hook is run with
zero arguments.

@example
(add-hook! after-draw-hook (lambda () (display "done drawing!\n")))
@end example

Combined with @code{before-draw-hook}, one can perform a frames per
second calculation to monitor game performance and stability.

@end defvr

@defvr {Scheme Variable} draw-hook
A hook that is run each time a frame should be rendered.  This hook is
run with a single argument @var{alpha}, a value in the range [0, 1]
which represents how much time has past since the last game state
update relative to the upcoming game state update, as a percentage.
Because the game state is updated independent of rendering, it is
often the case that rendering is occuring between two updates.  If the
game is rendered as it was during the last update, a strange
side-effect will occur that makes animation appear rough or
``choppy''.  To counter this, the @var{alpha} value can be used to
perfrom a linear interpolation of a moving object between its current
position and its previous position.  This odd trick has the pleasing
result of making the animation look smooth again, but requires keeping
track of previous state.

@c TODO: Add example of linear interpolation

@example
(add-hook! draw-hook (lambda (alpha) (display "<(._.<) \n")))
@end example

@end defvr

@defvr {Scheme Variable} quit-hook
A hook that is run when the user clicks the close button on the game
window.  This hook is run with zero arguments.

@example
(add-hook! quit-hook (lambda () (display "bye!\n")))
@end example

@end defvr

@defvr {Scheme Variable} key-press-hook
A hook that is run when a key is pressed on the keyboard.  This hook
is run with four arguments:

@enumerate
@item
@var{key}: The symbolic name of the ``virtual'' key that was pressed.
For example: @code{backspace}.  It's called a virtual key because the
operating system may map a physical keyboard key to another key
entirely, such as how the author binds the ``caps lock'' key to mean
``control''.

@item
@var{scancode}: The symbolic name of the physical key that was
pressed.

@item
@var{modifiers}: A list of the symbolic names of modifier keys that
were being held down when the key was pressed.  Possible values
include @code{ctrl}, @code{alt}, and @code{shift}.

@item
@var{repeat?}: @code{#t} if this is a repeated press of the same key.

@end enumerate

@example
(add-hook! key-press-hook
           (lambda (key scancode modifiers repeat?)
             (display "pressed key: ")
             (display key)
             (newline)))
@end example

@end defvr

@defvr {Scheme Variable} key-release-hook
A hook that is run when a key is released on the keyboard.  This hook
is run with three arguments:

@enumerate
@item
@var{key}: The symbolic name of the ``virtual'' key that was released.

@item
@var{scancode}: The symbolic name of the physical key that was
released.

@item
@var{modifiers}: A list of the symbolic names of modifier keys that
were being held down when the key was released.

@end enumerate

@end defvr

@defvr {Scheme Variable} text-input-hook
A hook that is run when printable text is typed on the keyboard.  This
hook is run with a single argument, @var{text}, a string containing
the text that was entered.
@end defvr

@defvr {Scheme Variable} mouse-press-hook
A hook that is run when a mouse button is pressed.
@end defvr

@defvr {Scheme Variable} mouse-release-hook
A hook that is run when a mouse button is released.
@end defvr

@defvr {Scheme Variable} mouse-move-hook
A hook that is run when the mouse is moved.
@end defvr

@defvr {Scheme Variable} controller-add-hook
A hook that is run when a game controller is connected.
@end defvr

@defvr {Scheme Variable} controller-remove-hook
A hook that is run when a game controller is disconnected.
@end defvr

@defvr {Scheme Variable} controller-press-hook
A hook that is run when a button on a game controller is pressed.
@end defvr

@defvr {Scheme Variable} controller-release-hook
A hook that is run when a button on a game controller is released.
@end defvr

@defvr {Scheme Variable} controller-move-hook
A hook that is run when an analog stick or trigger on a game
controller is moved.
@end defvr

@node Input
@section Input

@node Math
@section Math

Chickadee contains data types and procedures for performing the most
common computations in video game simulations such as linear algebra
with vectors and matrices and axis-aligned bounding box collision
detection.

@menu
* Vectors::                     Euclidean vectors.
* Matrices::                    Transformation matrices.
* Rectangles::                  Axis-aligned bounding boxes.
@end menu

@node Vectors
@subsection Vectors

@node Matrices
@subsection Matrices

@node Rectangles
@subsection Rectangles

@node Graphics
@section Graphics

Chickadee aims to make hardware-accelerated graphics rendering as
simple and efficient as possible by providing high-level APIs that
interact with the low-level OpenGL API under the hood.  Anyone that
has worked with OpenGL directly knows that it has a steep learning
curve and a lot of effort is needed to render even a single triangle.
The Chickadee rendering engine attempts to make it easy to do common
tasks like rendering a sprite while also providing all of the building
blocks to implement additional rendering techniques.

@menu
* Rendering Engine::            Rendering state management.
* Sprites::                     Draw 2D images.
* Lines and Shapes::            Draw line segments and polygons.
* Textures::                    2D images.
* Blending and Depth Testing::  Control how pixels are combined.
* Vertex Arrays::               Create 2D/3D models.
* Shaders::                     Create custom GPU programs.
* Framebuffers::                Render to texture.
* Viewports::                   Restrict rendering to
@end menu

@node Rendering Engine
@subsection Rendering Engine

Chickadee defines rendering using a metaphor familiar to Scheme
programmers: procedure application.  A shader (@pxref{Shaders}) is
like a procedure for the GPU to apply.  Shaders are passed arguments:
A vertex array containing the geometry to render (@pxref{Vertex
Arrays}) and zero or more keyword arguments that the shader
understands.  Similar to how Scheme has @code{apply} for calling
procedures, Chickadee provides @code{gpu-apply} for calling shaders.

Additionally, there is some dynamic state that effects how
@code{gpu-apply} will behave.  Things like the current viewport,
framebuffer, and blend mode are stored as dynamic state because it
would be tedious to have to have to specify them each time
@code{gpu-apply} is called.

The following procedures and syntax can be found in the
@code{(chickadee render)} module.

@deffn {Scheme Syntax} gpu-apply @var{shader} @var{vertex-array} [#:uniform-key @var{uniform-value} ...]
@deffnx {Scheme Syntax} gpu-apply* @var{shader} @var{vertex-array} @var{count} [#:uniform-key @var{uniform-value} ...]

Render @var{vertex-array} using @var{shader} with the uniform values
specified in the following keyword arguments.

While @code{gpu-apply} will draw every vertex in @var{vertex-array},
@code{gpu-apply*} will only draw @var{count} vertices.

@end deffn

@deffn {Scheme Procedure} current-viewport
Return the currently bound viewport.  @xref{Viewports} for more
details about using viewports.
@end deffn

@deffn {Scheme Procedure} current-framebuffer
Return the currently bound framebuffer.  @xref{Framebuffers} for more
details about using framebuffers.
@end deffn

@deffn {Scheme Procedure} current-blend-mode
Return the currently bound blend mode.  @xref{Blending and Depth
Testing} for more details about using blend modes.
@end deffn

@deffn {Scheme Procedure} current-depth-test
Return @code{#t} if depth testing is currently enabled.
@xref{Blending and Depth Testing} for more details about using the
depth test.
@end deffn

@deffn {Scheme Procedure} current-texture
Return the currently bound texture.  @xref{Textures} for more details
about using textures.
@end deffn

@deffn {Scheme Procedure} current-projection
Return the currently bound projection matrix.  @xref{Matrices} for
more details about matrices.
@end deffn

@deffn {Scheme Syntax} with-viewport @var{viewport} @var{body} ...
Evaluate @var{body} with the current viewport bound to @var{viewport}.
@end deffn

@deffn {Scheme Syntax} with-framebuffer @var{framebuffer} @var{body} ...
Evaluate @var{body} with the current framebuffer bound to
@var{framebuffer}.
@end deffn

@deffn {Scheme Syntax} with-blend-mode @var{blend-mode} @var{body} ...
Evaluate @var{body} with the current blend mode bound to
@var{blend-mode}.
@end deffn

@deffn {Scheme Syntax} with-depth-test @var{depth-test?} @var{body} ...
Evaluate @var{body} with the depth-test disabled if @var{depth-test?}
is @code{#f}, or enabled otherwise.
@end deffn

@deffn {Scheme Syntax} with-texture @var{texture} @var{body} ...
Evaluate @var{body} with the current texture bound to @var{texture}.
@end deffn

@deffn {Scheme Syntax} with-projection @var{projection} @var{body} ...
Evaluate @var{body} with the current projection matrix bound to
@var{projection}.
@end deffn

@node Sprites
@subsection Sprites

@node Lines and Shapes
@subsection Lines and Shapes

@node Textures
@subsection Textures

@node Blending and Depth Testing
@subsection Blending and Depth Testing

@node Vertex Arrays
@subsection Vertex Arrays

@node Shaders
@subsection Shaders

Shaders are programs for the GPU to evaluate.  They are written in the
OpenGL Shading Language, or GLSL.  Chickadee does not currently
provide a Scheme-like domain specific language for writing shaders.
Since shaders must be written in GLSL and not Scheme, they are
considered an advanced feature.

@node Framebuffers
@subsection Framebuffers

@node Viewports
@subsection Viewports

@node Audio
@section Audio

There is no audio support yet.  Stay tuned!