summaryrefslogtreecommitdiff
path: root/doc/api.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/api.texi')
-rw-r--r--doc/api.texi69
1 files changed, 49 insertions, 20 deletions
diff --git a/doc/api.texi b/doc/api.texi
index 6669b5f..473e3b9 100644
--- a/doc/api.texi
+++ b/doc/api.texi
@@ -1359,26 +1359,55 @@ It's not uncommon to need to draw hundreds or thousands of sprites
each frame. However, GPUs (graphics processing units) are tricky
beasts that prefer to be sent few, large chunks of data to render
rather than many, small chunks. Using @code{draw-sprite} on its own
-will involve at least one GPU call @emph{per sprite}, which will
-quickly lead to poor performance. To deal with this, a technique
-known as ``sprite batching'' can be used. Instead of drawing each
-sprite immediately, the sprite batch will build up a large of buffer
-of sprites to draw and defer rendering until the last possible moment.
-Batching isn't a panacea, though. Batching only works if the sprites
-being drawn share as much in common as possible. Every time you draw
-a sprite with a different texture or blend mode, the batch will be
-sent off to the GPU. Therefore, batching is most useful if you
-minimize such changes. A good strategy for reducing texture changes
-is to stuff many bitmaps into a single image file and create a
-``texture atlas'' (@pxref{Textures}) to access the sub-images within.
-
-Taking advantage of sprite batching in Chickadee is easy, just wrap
-the code that is calling @code{draw-sprite} a lot in the
-@code{with-batched-sprites} form.
-
-@deffn {Syntax} with-batched-sprites @var{body} @dots{}
-Use batched rendering for all @code{draw-sprite} calls within
-@var{body}.
+will involve at least one GPU call @emph{per sprite}. This is fine
+for rendering a few dozen sprites, but will become a serious
+bottleneck when rendering hundreds or thousands of sprites. To deal
+with this, a technique known as ``sprite batching'' is used. Instead
+of drawing each sprite immediately, the sprite batch will build up a
+large of buffer of sprites to draw and send them to the GPU all at
+once. There is one caveat, however. Batching only works if the
+sprites being drawn share a common texture. A good strategy for
+reducing the number of different textures is to stuff many bitmaps
+into a single image file and create a ``texture atlas''
+(@pxref{Textures}) to access the sub-images within.
+
+@deffn {Procedure} make-sprite-batch @var{texture} [#:capacity 256]
+Create a new sprite batch for @var{texture} with initial space for
+@var{capacity} sprites. Sprite batches automatically resize when they
+are full to accomodate as many sprites as necessary.
+@end deffn
+
+@deffn {Procedure} sprite-batch? @var{obj}
+Return @code{#t} if @var{obj} is a sprite batch.
+@end deffn
+
+@deffn {Procedure} sprite-batch-texture @var{batch}
+Return the texture for @var{batch}.
+@end deffn
+
+@deffn {Procedure} set-sprite-batch-texture! @var{batch} @var{texture}
+Set texture for @var{batch} to @var{texture}.
+@end deffn
+
+@deffn {Procedure} sprite-batch-add! @var{batch} @var{position} @@
+ [#:origin] [#:scale] [:rotation] @@
+ [#:tint @code{white}] [#:texture-region]
+
+Add sprite located at @var{position} to @var{batch}.
+
+To render a subsection of the batch's texture, a texture object whose
+parent is the batch texture may be specified as @var{texture-region}.
+
+See @code{draw-sprite} for information about the other arguments.
+@end deffn
+
+@deffn {Procedure} sprite-batch-clear! @var{batch}
+Reset size of @var{batch} to 0.
+@end deffn
+
+@deffn {Procedure} draw-sprite-batch @var{batch} [#:blend-mode @code{alpha}]
+Render @var{batch} using @var{blend-mode}. Alpha blending is used by
+default.
@end deffn
With a basic sprite abstraction in place, it's possible to build other