summaryrefslogtreecommitdiff
path: root/doc/api.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/api.texi')
-rw-r--r--doc/api.texi14
1 files changed, 7 insertions, 7 deletions
diff --git a/doc/api.texi b/doc/api.texi
index 813c66a..18c13e7 100644
--- a/doc/api.texi
+++ b/doc/api.texi
@@ -1290,7 +1290,7 @@ blocks to implement additional rendering techniques.
* Framebuffers:: Render to texture.
* Viewports:: Restrict rendering to a particular area.
* Rendering Engine:: Rendering state management.
-* GPU Buffers:: Send data to the GPU.
+* Buffers:: Send data to the GPU.
* Shaders:: Create custom GPU programs.
@end menu
@@ -1872,10 +1872,10 @@ Return the list of clear flags for @var{viewport}.
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{GPU Buffers})
-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.
+A vertex array containing the geometry to render (@pxref{Buffers}) 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,
@@ -1968,8 +1968,8 @@ Evaluate @var{body} with the current projection matrix bound to
@var{projection} (@pxref{Matrices}).
@end deffn
-@node GPU Buffers
-@subsection GPU Buffers
+@node Buffers
+@subsection Buffers
Alright, let's brush aside all of those pretty high level abstractions
and discuss what is going on under the hood. The GPU exists as a