WARNING WILL NOT COMPILE
Ok this commit really is just so I can then go make
serious changes to cepl:gl and have some record of what I
have been fiddling with.

I have bought a copy of 'let over lambda' recently and the
effects are starting to be obvious...more macros!

Not always a good thing, but the experience is fun so they
are in for now. Also I am starting to be able to make some
opinionated choices about how I want to interface with OpenGL.

base-macros is a home for macros I am using across the board

base-maths is base.lisp renamed

cepl-gl is not in its full form yet so this version will not compile
(in fact this will be true for much of this commit!)

cepl-time is home for the time functions I have started making.
Thesse a really to try and abstract areas of the game loop so we
dont have to have some kind of special loop macro just for games.
That always rubs me up the wrong way.

cepl-utils is expanding with handy, if slow, functions

cepl.asd is not correct yet

cepl-package is modified

matrix3 and 4 have been tweaked as packages have been renamed
*WARNING: NEW STUFF ALMOST CERTAINLY WILL NOT WORK*

Alright! This is a very exciting one as I have been powering
away at the cepl-gl package and i think I may have all the
parts finally written. They have not been run yet so will
definitely fail BUT all the main abstractions around cl-opengl
are there.

My next step is to write some demos to make sure all the features
work (and fix them when they invariably don't!).

Ok so the main ideas in cepl-gl (cgl from now on)

bind-buffer, use-program and bind-vertex-array are all memoized
functions which only evaluate if the value you pass in is
different from the value passed in on the last call.
This minimises the number of calls and thus allows it to be
used more liberaly without concern for the cost of the bind.
Of course this adds a little overhead but the idea is that the
user will never really have to use these functions themselves.
A few functions have been shadowed to use this functionality
but it's still early days here.

I have extended the functionality of the gl-arrays provided by
cl-opengl. They were good but provided functionality for all
versions of opengl. By forgoing this and focusing on opengl 2.3+
I was able to use the binding functions to autogenerate the
attrib-pointer calls used to make the vaos.

Oh I have also dropped the idea of streams=vao
renderable=vao+details in favour of a naming convention closer
to the opengl spec. There are soem pretty cool changes though:
* you define data structures using define-gl-array-format and
  use it to create gl-arrays. (you can use the
  destructured-populate to make filling arrays MUCH tidier)
* You use multi-populate-buffer to fill a buffer with a list of
  arrays. Arrays using the gl-array-formats are interleaved and
  the arrays a packed in one after another in the buffer.
  multi-populate-buffer spits out a buffer-format list which is
  can be used to autogenerate vaos
* make-vao takes a list telling it what buffer (and where in the
  buffer) to take the data for each attribute from. By using
  multi-populate-buffer you are given this automatically.
  It will then create a vao and spit out the vao-id
* streams are structs which contain details for drawing, namely:
  vao-id, start, length, element-type (nil unless making using
  an element-array-buffer) and a draw style (defaults to
  :triangles).
* Programs are a big leap from the standard.
  when you call make-program you pass in a list of shaders
  make-program links them and produces a program-id. This is then
  used to extract the uniforms from the shader program. The
  uniform names are then lispified ("aVal_b_c"->":AVAL-B-C")
  and used as a hash key for the function used to update that
  particular type of uniform.
  make-program then makes a closure which takes a list of streams
  and an optional &key list of uniforms to update. Once it has
  updated any uniforms it has had passed in it then loops through
  the streams and calls draw-arrays (or draw-elements) on them.

Programs seem crazy but they are essentially treating glsl
programs as a function. You give the function streams and it
draws them. The function remembers the uniforms it was provided
previously so you only need to pass uniforms details if you need
to update them.

There is LOOOADS of room for optimisation in cepl-gl, it is just
a first hash at the abstractions I think will make writing things
in opengl fast and fun. The opengl state is a bitch to keep track
of in your head and so I try to limit that as much as possible
by making the calls look like concepts that are familiar in lisp
(closures, lists, structs and arefs).

Other changes are pretty trivial. Ok so now I am off to try and
use this stuff...wish me luck!
*ITS STILL NOT WORKING!*
I've made some progress here that I'm very happy with but I've
also run into a limitation of the macro system defined in cl-opengl
and really need to scrap some of it and rework it.

It will mean doing some things at run time, but they are the kinds
of operations that are run very infrequently so trying to optimise
the situation through the macros is only increasing complexity
without providing any messured benefit.
I'd like to be very clear though, I like macros cl-opengl put in
because for some of the situations in fixed function rendering it
would have been a really boon, but alas not for modern opengl work.

Most of the commit is bug fixing and tidying up but as I'm about
to go on a code-culling-rampage I thought I better commit.
IT LIVES! This is the working push of the new opengl abstractions.
I've been working through the old arc-synthesis tutorials again
both to ensure cepl-gl is bug free and also to make sure it is
pleasent to use. In both cases it is certainly getting closer!

cepl-gl
-------
I have done some serious reworking here to get things to work and
feel right. The latter is something that still needs work and the
state of the package is still not great in that alot of things
aren't exported yet.

The flow of getting data into opengl buffers is now much simpler
than before.
First off you can define 'attribute formats' these are the
data-types that our vertex stream will be made off.
so:
(define-attribute-format just-position :type :float
                                       :components (x y z w))
gives you a datatype called 'just-position' which will be passed
to your shader/s as a float-4 vector.

Seen as we have to get data into gl-arrays first so we can send
them to buffers, we can use the attribute format we just made as
an array type so: (alloc-gl-array 'just-position 10) will make a
gl-array (note: gl-arrays are just pretty wrappers around c-arrays)
of 10 vectors each with an x,y,z & w coordinate.

Now often we want to interleave our data as it makes it faster for
the gpu to read...unfortunately working out the strides and offsets
is a royal pain in the bum, so I've made it really easy with
attribute formats.
(define-interleaved-attribute-format position-and-color
            		 (:type :float :components (x y z w))
			 (:type :unsigned-char :components (r g b)))
The code above will make an attribute format with interleaved data.
we can make arrays with it just like before

If you need to quickly squirt data into these arrays you may find
writing loops and using aref-gl a bit repetative so you can use
'destructuring-populat
This takes an array and a list of data and populates the array
using the data in the list.

 (setf *pos-and-color-array* (alloc-gl-array 'position-and-color 3))
 (destructuring-populate *pos-and-color-array*
                '((( 0.0   0.2  0.0  1.0) (255   0   0))
      		  ((-0.2  -0.2  0.0  1.0) (0   255   0))
		  (( 0.2  -0.2  0.0  1.0) (0     0 255))))

Notice how the data in the list mirrors the structure of the
attribute format from above.

Ok so now you have data in an array and you need it in a buffer.
All you do is call buffer-data passing the array and buffer-id.
cepl's buffer-data is different from the standard opengl one as it
returns a list containing the layout  of all the arrays in the
buffer with all the stride information, offsets and such calculated.
The reason for this is that it can be passed straight into the
'make-vao' functions to create a vao. You can mix and match data
from different buffers if you like but it will certainly be faster
if the data is in one buffer wherever possible.

vaos can be used in making streams. Streams are something that are
used constantly in opengl but don't have their own datatype. In
cepl a stream is a vao with a start and end index which are used
when rendering.

another area that is substantially different from standard opengl
in syntax, is the opengl programs.
Programs are compiled shaders which are used to encapsulate the
pipeline.
I felt that rather than this being just a number to be passed to
'use-program' it would be much more logical to treat this as a
function which ran on the gpu. In lisp, we deal a lot with lambdas
so when you run cepl's 'make-program' and pass in a list of shaders,
you get given back a lambda.
When you call this function, passing in a list of stream, it will
render the data in those streams using the gpu pipeline.
As well as streams of data, shader programs also use uniforms.
These can also easily be passed in using the uniform name as a key
so to pass in the 'camera-matrix' uniform you can do the following
(funcall *program-lambda* (stream1 stream2)
	                  :camera-matrix (gen-camera-matrix))
The uniforms are stored in the lambda's lexical scope between calls
so you only need to pass in a uniform when you need to update it..
NOT every loop.

---------------------

Also in cepl-gl I fixed a STUPID bug in the matrix uniform code.

---------------------

cepl-time.lisp was missing an 'in-package' so that is added now.

---------------------

package.lisp has obviously been updated but cepl-gl is still messy
and incomplete...I will be looking into this soon.
The user should Never have to use cl-opengl

---------------------

Some files have been changed and added in arc-tuts but this whole
directory is pretty much redundant now and will be removed in the
next commit.

---------------------

the 'examples' directory now contains the SDL versions of the
arc-synthesis tutorials I have done thus far. It is where I am
playing with the features and seeing how they look in 'real' code.

The naming of the files is crap and will be fixed in the next commit

---------------------

the 'experiments' directory is more a stash of my mental droppings
rather than real experiments, I'm commiting these files for the
record but they may be deleted in the next commit.

---------------------

Thats all folks, this took WAAYY to long but I've learnt alot so
thats a relief at least!
Hope your all well
Ciao
After the last commit I realised how much I needed to do a big
tidy-up of files.

I have removed all the arc-tuts folder as it was made before
all of the new abstractions were available and thus was very
out of date.

I have renamed the files in the examples folder as they were
thown together as I was bug fixing and didnt have any obvious
order.

I have also cleared out the experiments folder and the misc-notes
file as the useful ideas had been incorperated and are still
available in git history if I should ever need them.

Well thats all for now, no code changes this time.
Ciao
After the last commit I found some files that still refered to
the old code, it was very easy to swap/remove the offending lines
and all should now be clean.
Added a new demo showing world to camera transforms. very happy with
this and am now in a position to having multiple 'objects' in a
scene and rotate, scale and position them as I choose.

It's all still simple stuff but it allows me to start seeing where
I need to make the experience for the users as clean as possible and
where I really need to work.

It seems like a good time to go and review some of the functional
programming styles and read some articles on how they could pertain
to game programming.

I also am really cheese off with an error that means I have to
restart my lisp session after every run of a demo. I think it is
that I am not cleaning up opengl resources adfter I am done with
them and thus the next tiem I start creating opengl resources it
simply crashes. I'm going to go on a hunt for this as this bug is
utterly unacceptable.

Other that example 4 I have just made a couple of bug fixes in a
few files.
Cheers all.