Skip to main content

Design Philosophy

In an earlier epoch I designed embedded system hardware and software in two different areas:

  • Pro Audio
  • Digital Signal Processing

Both of these fields are 'real-time' programming. It's not dissimilar to what you have to deal with in Unity3D:

  • A frame in pro audio at 44.1 kHz doesn't allow much time per-sample to process much, about 22 microseconds.

  • A frame in a game at 60 Hz is about 17 milliseconds which sounds quite generous by comparison.

Either way, you have a certain amount of time to do your processing or:

  • Audio ==> Audible 'artifacts' such as clicks and pops
  • Game ==> Dropped frames

For audio, back in the day, normal PC processors were way too slow to process even audio. Hence we had DSP (Digital Signal Processing) chips from TI, AT&T, Motorola, and others.

There were no development tools for these chips, so our company (read: me) developed them. Originally on MS-DOS PC 16-color VGA displays using line-drawing characters (do those characters still exist??).

PrettyThese highlyDSP-chip regarded:debuggers were popular enough that I rewrote one in Objective-C forthat the a released debuggerwas shipped with the original NeXT machines.

Anyway, coding DSP chips was difficult. It was all machine language with exposed pipelines in some cases.

Exposed Pipeline: operations don't execute in the order that you write them, Fun!

Fun Reading An early DSP chip spec sheet.

Hence, at 100 or 200 ns per instruction you just could not execute all that many instructions in one frame. So you had to code with performance as #1. You could never write code that wasn't fully optimized for perfomance from the start because you couldn't even test it. And debugging was guesswork (no tools at first).

This is all to say that this biased my approach to coding.

So I tend to eschew the modern programming idiom of write first optimize later.

  • Use inheritance and interfaces for Tile classes.
  • Use generics where it makes sense (to me), such as in the Messaging Service's messages.
  • Tightly hardcode things that by nature have to be optimized, such as the Tweener Service and the internals of TpLibTasks.
  • Extensively pool class instances and other objects.
  • Extensively cache tile instances in the layout system.

No acronym-based coding style will be found anywhere :-)

Back to top