Textures in opengl have parameters that affect how they are sampled. They dictate what happens when they are magnified or minified, what happens if you sample outside the texture etc.

Sampler objects allow you to override the sampling params in a texture. One sampler object can be used on multiple textures in a single draw call.

As of last night these are now available in cepl if (>= (version-float *gl-context*) 3.3)).

You can use them like this

(defvar sampler (make-sampler :wrap #(:repeat :clamp-to-edge :repeat)))

(with-sampling ((tex sampler))
  (map-g #'some-pipeline some-stream :tx tex))

With sampling overrides a texture’s sampling params with the sampler object for the duration of the scope. The texture then reverts to it’s own sampling parameters.

The functions that are used on samplers to change their parameters also work on textures so:

(setf (lod-bias some-texture) 0.5)
(setf (lod-bias some-sampler) 0.5)

are both valid.

Next up are blend-modes. I have had to hold off making new videos for a few days as they are going out of date so fast as we keep getting new features.

IT FINALLY FUCKING WORKS!

Video coming saturday explaining in detail how to get set up on osx but the tldr is:

• run osx-sbcl-launch.sh from the terminal
• slime-connect
• (in-package :cepl)

Back soon!

It’s buggy as hell right now but I’ve been working on a new way (for cepl) to write and compose shaders.

You now write gpu functions and compose them using defpipeline, the gpu functions can be used as stages or as regular functions and varjo will compile them correctly for each task. We also have lost explicit return in favour of implicit tail returns, just like in regular common lisp.

A quick code sample

(defun-g v ((vert g-pc))
  (values (v! (cgl:pos vert) 1.0)
          (:smooth (cgl:col vert))))

(defun-g f ((color :vec4))
  color)

(defpipeline prog-1 (g-> v f))

Compiles to

// vertex shader
#version 330

layout(location = 0) in vec3 fk_vert_position;
layout(location = 1) in vec4 fk_vert_color;

smooth out vec4 out_86v;

void main() {
    vec4 return1;
    vec4 v_tmp_83v_84v = vec4(fk_vert_position,1.0f);
    return1 = fk_vert_color;
    gl_Position = v_tmp_83v_84v;
    out_86v = return1;
}

// fragment shader
#version 330

in vec4 out_86v;

layout(location = 0) out vec4 output_color_87v;

void main() {
    output_color_87v = out_86v;
}

I tried to write a short reply to someone on extending a language with macros…I failed…it got long

This was the thread: http://www.reddit.com/r/lisp/comments/2wy18r/is_this_what_people_mean_when_they_say_lisp/

[note: this assumes you’re a lisp newbie, sorry if this is patronising] Is it what ‘THEY’ mean when they say Lisp allows you to invent your own language. No, not really. But it is nice to be able to use symbols normally deemed off limits right? But syntax is part of language so what you are doing is in the sphere of language. Let’s have a look at a macro:

(defmacro fn^ (name args &body body)
  `(defun ,name ,args
     ,@body))

Ok so first let’s see what it does and then how it does it.

A macro is a function that runs at a different time, weird right?! It the above kind is run before your program is compiled. the arguments will be source code and the return value will be new code to go in place of the old code. So this:

(fn^ some-func (x) (* x 10))

-becomes-

(defun some-func (x) (* x 10))

See what happened there? The macro was give the following arguments: name -> some-func args -> (x) body -> ((* x 10))

if not you may want to read up on ‘backquote syntax’, it is (aproximately) a very tidy way of splicing lists and data together.

Ok so now we have functions and this kind of macro (yes there are other kinds) we can image that we redefine every common contruct in common lisp.

lets say: let becomes val<-, make-hash-table becomes hsh^,

(f^ fnc (%) (val<- ((x (hsh^)) (y :dflt)) (<> % x)))

Well it’s clearly still lisp but it’s very unfamilar (and ugly! :D). While this may affect language design it doesnt feel like a new language. Let’s do something else with these macros

(defmacro val<- (&rest form)
  (let* ((body (last form))
         (bindings (butlast form))
         (b (loop for i below (1- (length bindings)) by 2 collect
                 (list (elt bindings i) (elt bindings (1+ i))))))
    `(let ,b
       ,@body)))

so now

(val<- ((x (hsh^)) (y :dflt))
       (<> % x))

could be writen as

(val<- x (hsh^) y :dflt
       (<> % x))

OK! so now this is different. This feels more like changing the language as we messing with how the code behaves. The issue is…now we are messing with language we not only have the normal problems a programmer deals with but also with those of a language designer. These are issues of feel and experience as well as functionality (it’s very like api design but with much deeper implications), the answers are often subjective and based on what the language is designed to solve. A big one for me is ‘Does the programmer have to think more to acheive something using this’.

In my own project I use macros to make defining glsl shaders feel like defining regular lisp functions.

(defshader some-name ((x :int))
  (+ x 10))

And translate the lisp code into glsl for the programmer.

We have only scratched the surface of what we can do in this little blogpost. There are also other kinds of macros, like reader macros for example. Reader macros are function that run before the macros we have seen already. They don’t recieve the code as lists of symbols, they recieve the actual characters from the code you wrote. They can allow for cool and often crazy stuff, all the of literal syntax you see around lisp is made usign reader macros: ‘ ` , #() . etc are all made possible using reader macros, and you can extend that in any way you can concieve.

I hope this was of some use. Sorry it turned into a whole post rather than a comment!

p.s. Also check out: http://enthusiasm.cozy.org/archives/2013/07/optima <- macros give CL pattern matching https://gist.github.com/chaitanyagupta/9324402 <- Info on reader macros Look symbol-macrolet <- this type of macro swaps out a symbol for another whole form

Just stuck a new video on youtube showing a bit of multipass rendering, normal mapping and refraction.

BBC uses RIPA terrorism laws to catch TV licence fee dodgers in Northern Ireland

https://medium.com/@tyrale/your-content-feed-is-broken-f8c6576077c2

“Our Point of Acknowledgment is the moment when we (the user) understand what we are viewing and can then recall that this information has been consumed. It is a continuous moving variable that helps us track where we are in time.”

Time tracking doesn’t require acknowledging every point though, just enough discrete points that we get a sense of moving forward, coupled with the critical assurance that the points will not rearrange themselves.

Movie and book analogies are broken, both experiences are designed knowing the content volume is fixed (designed is a very generous term if you are dealing with dvd/blueray UIs .. or most devices for hard media for that matter)

Interesting concept but naive implementation just optimizes for a different view habit, the author acknowledges this by saying: “Each feed will need to choose an appropriate location to place new users.” - this is a non-trivial problem, deciding a user’s content priority is hard, if you are picking one and dictating then we are just setting things up so that another well intentioned blog post like this will come up saying ‘wouldn’t it be great to have our media presented like X’

“whining as loud as the rest of you” - Dismissing issues as whining is a massive fallacy. User experience is not just design, it isn’t just entry points, it covers the gamut of ways the user and the medium interact; experience is not a one way phenomenon.

How you treat people’s data is part of experience as if you fuck up they experience it. Whether it is losing credit card details or leaking browsing habits, the experience lives beyond a page view if you choose to retain data.

The fundamental we are dealing with, once again is, ‘how do I track my position in a world changing to rapidly to comprehend alone?’.

This question remains open and is hard, I believe these problems are solvable with going down the road of companies/websites/etc saying ‘well with just one more bit of data we can make your life better, wait…no just two more bits’.

Just wrote a handy function for working with slime.

• It takes the top level form at that point e.g. (make-instance 'test)
• Wraps it in a defparameter with a new var name (defparameter <iv-0> (make-instance 'test))
• evals it using slime and injects the var name (in this case <iv-0>) into the file just after the toplevel form

This is useful when sketching out ideas in a file and you want to compile something but also capture the result in a global for messing with later

running it 3 times would give you something like

(make-instance 'test)
<iv-2> <iv-1> <iv-0>

which makes it very easy to wrap a list around and throw it where you see fit.

(defvar eval-into-file-count 0)
(defun slime-eval-into-file ()
  "Evaluate the current toplevel form.
store the result in a new global and insert the 
var into the code"
  (interactive)
  (let* ((form (slime-defun-at-point))
         (var-name (concat "<iv-" (number-to-string eval-into-file-count) ">"))
         (form-with-var (concat "(defparameter " var-name form ")")))
    (setq eval-into-file-count (+ eval-into-file-count 1))
    (end-of-defun)
    (slime-eval-async `(swank:eval-and-grab-output ,form-with-var)
      (lambda (result)
        (cl-destructuring-bind (output value) result
          (push-mark)
          (insert value " "))))))

Ciao

Ah one thing I need to nail before geometry shaders is better support for FBOs as I remembered I need a way to draw to mutiple textures from one shader.

(defpipeline prog-1 ((vert vert-data))
  (:vertex (setf gl-position (pos vert))
           (out (the-color :smooth) (col vert)))
  (:fragment (let ((lerp-value (/ (y gl-frag-coord) 500.0)))
               (out outputColor (mix the-color 
                                     (v! 0.2 0.2 0.2 1.0)
                                     lerp-value)))))

Currently setting the out vars of a shader stage is done with the out special form. The above code compiles to

// vertex shader
#version 330

layout(location = 0) in vec4 fk_vert_position;
layout(location = 1) in vec4 fk_vert_colour;
smooth out vec4 the_color;

void main() {
    gl_Position = fk_vert_position;
    the_color = fk_vert_colour;
}

// fragment shader
#version 330

smooth in vec4 the_color;
out vec4 outputcolor;

void main() {
    float lerp_value_4v = (gl_FragCoord.y / 500.0f);
    outputcolor = mix(the_color,vec4(0.2f,0.2f,0.2f,1.0f),lerp_value_4v);
}

Notice how the out form essentially compiles to a global var and a setf.

In the quest for lispyness, should this stay as it is? There isn’t anything wrong with setf per se, however it is worth investigating other forms to see if anything surprises us…and by us I mean me :)

Here is a version with a version of values that allows naming

(defpipeline prog-1 ((vert vert-data))
  (:vertex (values (gl-position (pos vert))
                   ((the-color :smooth) (col vert))))
  (:fragment
   (values (outputColor
            (let ((lerp-value (/ (y gl-frag-coord) 500.0)))
              (mix the-color 
                   (v! 0.2 0.2 0.2 1.0)
                   lerp-value))))))

Eh..the vertex shader is ok but this introduces an extra level of indentation that looks ugly

Ok so how about setf style? Setf allows a name-value style to set multiple variables

(setf a 1
      b 2)

So for the shaders that is…

(defpipeline prog-1 ((vert vert-data))
  (:vertex (values gl-position (pos vert)
                   (the-color :smooth) (col vert)))
  (:fragment
   (values
    outputColor
    (let ((lerp-value (/ (y gl-frag-coord) 500.0)))
      (mix the-color 
           (v! 0.2 0.2 0.2 1.0)
           lerp-value)))))

.. nope, doesn’t feel better aesthetically and now makes identifying the val and name forms more difficult.

Declare style?

(defpipeline prog-1 ((vert vert-data))
  (:vertex
   (declare (out gl-position (the-color :smooth)))
   (values (pos vert) (col vert)))
  (:fragment
   (declare (out outputColor))
   (values (let ((lerp-value (/ (y gl-frag-coord) 500.0)))
             (mix the-color 
                  (v! 0.2 0.2 0.2 1.0)
                  lerp-value)))))

..Interesting, yesterday I was looking at declare for types, so if that was the case then using this would feel natural.

Lets see what happens if the types are in declare too

(defpipeline prog-1 (vert) (:vertex (declare (vert-data vert) (out gl-position (the-color :smooth))) (values (pos vert) (col vert))) (:fragment (declare (out outputColor)) (values (let ((lerp-value (/ (y gl-frag-coord) 500.0))) (mix the-color (v! 0.2 0.2 0.2 1.0) lerp-value)))))

Haha, not much as almost everything here was already being done with inference.

There is still an issue though that is best summed up in Erik Naggum’s quote on c++. For my purposes the fact that this is about c++ is irrelevant.

C++ is philosophically and cognitively unsound as it forces a violation
of all known epistemological processes on the programmer.  as a language,
it requires you to specify in great detail what you do not know in order
to obtain the experience necessary to learn it. -- Erik Naggum

Declaring types in advanced forces the programmer to make an assertion about the nature of the code not yet written. This violates the concept of live coding as we are coding, not because we have the solution, but because we are looking for one.

Now obviously with coding in the restricted environment of the GPU types are currently a necessity so the best we can do is minimize the cognitive damage. Other than having inference everywhere we possibly can, the other way is to delay specifying the type until it is actually needed, in most cases with the arg definition.

Hmm so no progress on this but I’m glad I’ve been able to empty my head a little.

Goodnight