summaryrefslogtreecommitdiff
path: root/doc/api.texi
blob: 1524acc2ccb1f4943dbeb0c92e618404b40c7cba (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
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
@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.  This hook is run
with four arguments:

@enumerate

@item
@var{button}: The symbolic name of the button that was pressed, such
as @code{left}, @code{middle}, or @code{right}.

@item
@var{clicks}: The number of times the button has been clicked in a row.

@item
@var{x}: The x coordinate of the mouse cursor.

@item
@var{y}: The y coordinate of the mouse cursor.

@end enumerate

@end defvr

@defvr {Scheme Variable} mouse-release-hook
A hook that is run when a mouse button is released.  This hook is run
with three arguments:

@enumerate

@item
@var{button}: The symbolic name of the button that was released.

@item
@var{x}: The x coordinate of the mouse cursor.

@item
@var{y}: The y coordinate of the mouse cursor.

@end enumerate

@end defvr

@defvr {Scheme Variable} mouse-move-hook
A hook that is run when the mouse is moved.  This hook is run with
five arguments:

@enumerate

@item
@var{x}: The x coordinate of the mouse cursor.

@item
@var{y}: The y coordinate of the mouse cursor.

@item
@var{dx}: The amount the mouse has moved along the x axis since the
last mouse move event.

@item
@var{dy}: The amount the mouse has moved along the y axis since the
last mouse move event.

@item
@var{buttons}: A list of the buttons that were pressed down when the
mouse was moved.

@end enumerate

@end defvr

@defvr {Scheme Variable} controller-add-hook
A hook that is run when a game controller is connected.  This hook is
run with a single argument, @var{controller}, the controller that was
connected.
@end defvr

@defvr {Scheme Variable} controller-remove-hook
A hook that is run when a game controller is disconnected.  This hook
is run with a single argument, @var{controller}, the controller that
was disconnected.
@end defvr

@defvr {Scheme Variable} controller-press-hook
A hook that is run when a button on a game controller is pressed.
This hook is run with two arguments:

@enumerate

@item
@var{controller}: The controller that triggered the event.

@item
@var{button}: The symbolic name of the button that was pressed.
Possible buttons are:

@itemize
@item
@code{a}
@item
@code{b}
@item
@code{x}
@item
@code{y}
@item
@code{back}
@item
@code{guide}
@item
@code{start}
@item
@code{left-stick}
@item
@code{right-stick}
@item
@code{left-shoulder}
@item
@code{right-shoulder}
@item
@code{dpad-up}
@item
@code{dpad-down}
@item
@code{dpad-left}
@item
@code{dpad-right}

@end itemize

@end enumerate

@end defvr

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

This hook is run with two arguments:

@enumerate

@item
@var{controller}: The controller that triggered the event.

@item
@var{button}: The symbolic name of the button that was released.

@end enumerate

@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.  This hook is run with three arguments

@enumerate

@item
@var{controller}: The controller that triggered the event.

@item
@var{axis}: The symbolic name of the axis that was moved.  Possible
values are:

@itemize
@item
@code{left-x}
@item
@code{left-y}
@item
@code{right-x}
@item
@code{right-y}
@item
@code{trigger-left}
@item
@code{trigger-right}
@end itemize

@end enumerate

@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

@deffn {Scheme Procedure} load-image @var{file} [#:min-filter nearest]
       [#:mag-filter nearest] [#:wrap-s repeat] [#:wrap-t repeat]

Load the image data from @var{file} and return a new texture object.

@var{min-filter} and @var{mag-filter} describe the method that should
be used for minification and magnification when rendering,
respectively.  Possible values are @code{nearest} and @code{linear}.

@var{wrap-s} and @var{wrap-t} describe how to interpret texture
coordinates that are greater than @code{1.0}.  Possible values are
@code{repeat}, @code{clamp}, @code{clamp-to-border}, and
@code{clamp-to-edge}.

@end deffn

@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!