Skip to content

Self Regard?

September 17, 2009

How does one best measure when a post is considered self regarding? Is there a good measuring stick? I have seen blogs that were nothing more than an ego trip and don’t really wish to become one of them. However I have also seen posts that are mostly a discussion about what people have been working on/doing recently. I got some rather instant feedback to something I posted yesterday about the beginnings of a foray into Clojure  which was deemed too self regarding. I find it rather funny that he didn’t appear to want to stick his account to that comment but I’ll take accept his statement and keep such posts private. When I have something a bit more meaty I’ll publish.


For posterity

September 17, 2009
For anyone who wants to be retentive about it I grabbed this from:
I’m storing it here for no other reason than it interests me and I don’t know how long it will remain up for on the original site :S


Things Naughty Dog Liked about Lisp

At last, some more details on what Naughty Dog gained from using Lisp to program their games:
Responses inline:

>From what I gathered, what GOAL had that I’d like:
>– fast iteration (due to the listener)

Well, fast iteration times weren’t merely due to the the listener – that was
a nice touch, but only the tip of the iceberg.  We could basically
dynamically link per-function or variable.  Effectively, you could hit a key
while working in the IDE, and whatever function the cursor was on would
instantly get compiled, sent across the network to the TOOL, linked and
dropped into the game while it was running.  The whole process took a
fraction of a second.  You could also do the same per-file.  This feature
was sort of like Edit and Continue, but you didn’t have to broken in the
debugger – it could be done while the game was running.  This was insanely
useful for programming gameplay, physics, and fx, as well as prototyping,
visual debugging (just drop in some debug spheres or prints while you have
the game in some interesting state), etc.  We also used it for dynamic code
streaming – so only a fraction of the executable code was loaded at any
given time (to conserve memory).

It’s astonishing at how much this ability changes your coding style – you
gravitate to a much more iterative development process, and write small bits
of code that evolve the codebase while the game is running.  It’s obviously
also much better for robustness and reliability, because you’re testing out
each little piece of code as it gets added (as opposed to writing a whole
mess of code and trying to get it compiled and debuggged).  As for bugs,
often you can fix them while the game is running and test out your changes
instantly – this makes bugfix verification much easier.

>– more performant generated code (I honestly find it hard to believe that
any small group of people (at least the ones I know!) could write a better
compiler (as in generates faster code) than Microsoft or GCC4 at this point,
but, perhaps compared to an ancient/early version of GCC on PS2?). Or is it
more that if you expressed certain things in
C++ that they’d be inherently slower?

On the performance front, the actual optimizing compiler really wasn’t that
great.  In fact, in most cases it generated code that was clearly inferior
to GCC (it did take advantage of native register sizes, but overall very
little development time was spent on the optimizer).  However, due to GOAL’s
seamless and tight integration with assembly, this wasn’t as much of a
problem as it may seem.  On the PS2, most heavy, performance-critical
operations you’re going to want to delegate to the VU anyway.  Writing
assembly code was awesome in GOAL – it unified the assembly syntax across
all of the disparate PS2 processors (with the same syntax as GOAL), you
could freely intermix assembly from all of the processors and normal GOAL
code, and it could access standard GOAL member variables, plus you had all
of the macro facilities, etc, to do stuff like automatic loop unwinding,
code pasting, etc.  It was pretty typical to write a bunch of GOAL code and
just replace the inner loop with some macro-mode VU code for nice
performance gains.  This was a pretty easy task given the fact that all
assembly code had the same syntax (no MSVC “__asm” blocks or GCC’s extremely
awkward intrinsics), and it took advantage of the register colorer).

As for the other stuff, like co-routines, etc – one of the salient points
here is that GOAL was extensible.  Since we wrote the language in-house, we
were able to extend it when the demands of our game required it.  This adds
a whole new dimension to problem solving – when you aren’t constrained by
the limitations of the language, you find that many problems become a lot
easier to tackle.

It was this ability to shape GOAL to our needs that allowed us to develop
features like coroutines, state inheritance, variable overlays, unique IDs,
etc.  This really was one of our key advantages in working with the

That said, GOAL wasn’t exactly designed with language extensibility in mind.
The macro syntax was quite powerful, but fell short of really allowing you
to add stuff to the core language, like new tags and keywords.  This meant
that a lot of new features had to be implemented by extending the actual
compiler, which was unfortunate – it was simply too time consuming to do
later in the PS2’s lifecycle.

In the future, I think it is absolutely critical that any game development
language is built with extensibility in mind.  This would imply both a good
macro syntax (for extensible code generation), compile-time reflection,
syntax extensions, and also the ability to add new tags, qualifiers, and
keywords (facilities that tools like OpenC++ try to provide).  After all, a
DS developer has a very different set of problems to solve than a PS3
developer, and a lot of these problems can be greatly aided by the
programming language (managing the many processors on the PS3, for example).

[Here’s some sample GOAL code from a later email message in the same thread]
Okay.  Here’s some old code I dug up from Jak3 that uses regular GOAL code,
EE assembly, and VU0 assembly in macro-mode.

A few words of warning:
The syntax takes a while to get used to (it is LISP, after all), and this
function is sort of weird (it’s a particle system callback function – the
assembly is there because I needed to convert some data from fixed point).
Also, it’s been over a year and a half since I wrote this, and it was a
quick one-off for a weapon effect, so it’s a bit messy.

Most of the code here is GOAL code, except for the code in the rlet.  (‘let’
is the way you declare variables in LISP, and rlet specifically guarantees
that variables will be bound to registers).

(defun sparticle-red-2-converge ((sp-system sparticle-system) (particle
sparticle-cpuinfo) (spvec sprite-vec-data-2d))
“Red gun 2 charge glow effect”
(let ((control (the sparticle-launch-control (-> particle key)))

;; figure out the offset from the player’s position
(let ((origin-vec (stack-vector))
(offset-vec (stack-vector))

;; retrieve offset vec off of userdata, omega.  We only had 8 bytes
for data storage,
;; but needed to store a full vec3, so we packed it into fixed
(let ((combined-vec (new ‘stack ‘vector4w))
(set! (-> combined-vec x) (-> particle user-uint32))
(set! (-> combined-vec y) (-> particle data 0))

(rlet ((offset :reg vf1)
(preconverted :reg vf2)
(l.q src combined-vec)   ;; GOAL->EE
(mer.vh lo iconv0 src r0) ;; EE
(sr.vw iconv0 iconv0 16)  ;; EE
(m preconverted iconv0)   ;; EE->VU0

;; (format *stderr* “Value is ~d~%” iconv0) ;; GOAL

;; VU ftoi15
(cvt.s.w offset preconverted :fixed 12) ;; VU0

(s.q offset offset-vec)  ;; VU0->GOAL

;; figure out distance
(let ((time-remaining (-> particle timer))
(distance 0.0)
(tt 0.0)
(set! tt (/ (the float (-> particle timer)) (the float (frame-time
(*! tt tt )
(set! tt (- 1.0 tt))

(vector-normalize! offset-vec (lerp PARTICLE_RED_2_CHARGE_SIZE
(meters 0) tt))

(vector-copy! origin-vec (-> *target* gun fire-point))

(set! (-> spvec trans x) (+ (-> offset-vec x) (-> origin-vec x)))
(set! (-> spvec trans y) (+ (-> offset-vec y) (-> origin-vec y)))
(set! (-> spvec trans z) (+ (-> offset-vec z) (-> origin-vec z)))

Scott Shumaker
Lead Programmer, Naughty Dog

The Aurora Browser – Your future today?

January 28, 2009

The Aurora Browser concept which has been commissioned by mozilla labs from Adaptive Path for their browser concept as potential browser of the future.

There are four video’s showcasing the paradigms that they envision as being the future of browsing with commentary as well as one complete one without it.  I recommend you watch all of them as some of the ideas are quite interesting.

Aurora Video Part 1 | Aurora Video Part 2 | Aurora Video Part 3 | Aurora Video Part 4 | Aurora Video Complete

The concepts behind it are showcased in this talk by Dennis Wixon at UX Week 2008. I do however wonder if it is possible to build it today. I’m going to look at the possibilities and every time I spot something I’ll tag it Aurora. Weave looks like a great way to interleave web history with mobile devices and your PC or laptop.

Open Source Hardware

January 19, 2009

Another day another wonder. I just found out about Arduino the open source chip. I was wondering when this would happen, a quick wiki search will bring up an article on Electronic Design Automation, gEDA and Magic 7 which in a sense lays the groundwork for open source hardware. Resources such as Open Cores to lookup design documents and tools along the lines of Rep Rap to manufacture the parts. I suppose as it stands that a little bit of a pipe dream. Not that this is any different to Open Source Software. You still need to have a fair bit of technical knowledge, know what your doing and be comfortable troubleshooting the problems that will inevitably crop up but its a start to what could become a beautiful thing. I suppose I sound a bit idealistic but hears to the hope for a more open source society.

Reading your mind

January 18, 2009

Scientists at Japan’s ATR Computational Neuroscience Laboratories have managed to extract low quality images via fMRI by teaching a computer how to read image data from from the fMRI scans while the test subjects are shown pictures, they then show them a series of new images and try to purely use the data from the brain scans to recreate these new images. An extract of the article can be found on pink tentacle with abstracts been posted on the December 10th issue of Neuron and science direct.

DIYbio – Genetic Engineering for the Masses

January 18, 2009

I was poking around on New Scientist today and came across this article on DIYbio. The existence of this hobby though not something I was aware of before today isn’t something that surprises me nor is the the mad scientist contest run by io9. The implications of this are too early to judge in my mind but I thought I’d point out the interesting when I saw it.

VR coming soon?

January 13, 2009

So how far are we from seeing the coming of affordable VR? First it was the glove with companies such as Immersion selling gloves hoping for the day they sell like hot cakes along with VR glasses or sunglasses in the case of Vuzix’s recent release. Other ancillary technologies seem to be coming up such as the remote control girl which showcased the idea of using small jolts of electricity to shift the balance in the inner ear causing the person to move to compensate the feeling of the ground moving under them.

It seems we are in for some interesting innovations to come.