summaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
authorEric Anholt <eric@anholt.net>2013-12-09 22:56:03 -0800
committerEric Anholt <eric@anholt.net>2013-12-09 22:57:41 -0800
commitd73f06fb4520705ad89036cdf2142307ccd1646c (patch)
treec75e3aae2a4cb9657f198016a9a1973d4fe978df /README.md
parentedf5aedb6fb0a10280cd68dd443df0322d0447b6 (diff)
downloadlibepoxy-d73f06fb4520705ad89036cdf2142307ccd1646c.tar.gz
Use ``` on a bunch of code in the README.
Some of it is to be prettier, and some of it is to avoid misformatting when using live preview at http://tmpvar.com/markdown.html
Diffstat (limited to 'README.md')
-rw-r--r--README.md25
1 files changed, 13 insertions, 12 deletions
diff --git a/README.md b/README.md
index af11573..57890e2 100644
--- a/README.md
+++ b/README.md
@@ -1,10 +1,11 @@
Epoxy is a library for handling OpenGL function pointer management for
you.
-It hides the complexity of dlopen(), dlsym(), glXGetProcAddress(),
-eglGetProcAddress(), etc. from the app developer, with very little
-knowledge needed on their part. They get to read GL specs and write
-code using undecorated function names like glCompileShader().
+It hides the complexity of ```dlopen()```, ```dlsym()```,
+```glXGetProcAddress()```, ```eglGetProcAddress()```, etc. from the
+app developer, with very little knowledge needed on their part. They
+get to read GL specs and write code using undecorated function names
+like ```glCompileShader()```.
Don't forget to check for your extensions or versions being present
before you use them, just like before! We'll tell you what you forgot
@@ -16,9 +17,9 @@ Features
* Automatically initializes as new GL functions are used.
* GL 4.4 core and compatibility context support.
* GLES 1/2/3 context support.
-* Knows about function aliases so (e.g.) glBufferData() can be used with
- GL_ARB_vertex_buffer_object implementations, along with GL 1.5+
- implementations.
+* Knows about function aliases so (e.g.) ```glBufferData()``` can be
+ used with ```GL_ARB_vertex_buffer_object``` implementations, along
+ with GL 1.5+ implementations.
* EGL and GLX support.
* Can be mixed with non-epoxy GL usage.
@@ -40,14 +41,14 @@ As long as epoxy's headers appear first, you should be ready to go.
Additionally, some new helpers become available, so you don't have to
write them:
-int epoxy_gl_version() returns the GL version:
+```int epoxy_gl_version()``` returns the GL version:
* 12 for GL 1.2
* 20 for GL 2.0
* 44 for GL 4.4
-bool epoxy_has_gl_extension() returns whether a GL extension is
-available ("GL_ARB_texture_buffer_object", for example).
+```bool epoxy_has_gl_extension()``` returns whether a GL extension is
+available (```GL_ARB_texture_buffer_object```, for example).
Note that this is not terribly fast, so keep it out of your hot paths,
ok?
@@ -65,8 +66,8 @@ GLEW has several issues:
* Doesn't support EGL.
* Has a hard-to-maintain parser of extension specification text
instead of using the old .spec file or the new .xml.
-* Has significant startup time overhead when glewInit() autodetects
- the world.
+* Has significant startup time overhead when ```glewInit()```
+ autodetects the world.
* User-visible multithreading support choice for win32.
The motivation for this project came out of previous use of libGLEW in