• Digital Archeology - SPIKE
  

Project Status

• A short analysis of the original Spike cartridge and source code

• Some findings of questionable usefulness...
  

• Something odd that caught my eye while playing Spike. Not sure if anybody else has ever noticed this before?

• In the intro cutscene, when Spud captures Molly, the Spud figure is drawn with some "flaws", making it look a bit odd. However, the cutscene is so short and fast, that this (at least in my case before) is very hard to notice.

•  Here are pictures of Spud, as shown in the Spike Manual, and on the Spike Box:
  

• However, the left picture below shows how Spud is effectively drawn in the cutscene. The vertical line at the top of his face, going down to his eyes, should not be visible. And so should be the line going down from his left brow to his left tooth. Also, the cigar he is smoking is drawn slightly inaccurate, and there are some other tiny gaps in the vectors.

• The picture on the right above shows how the scene looks like with these flaws fixed, which is probably the way it was intended to be.
  

• I can only guess why the programmers decided to draw Spud the way they did: They had likely run out of bytes and still had to fit the complete game into 8K. So they could not use the (more costly) vector-list format which also allows invisible vectors (moves). Thus they had to draw the complete Spud figure in-one-go, using the more space-efficient vector-list format which has visible vectors only (no moves). But that is just a theory of mine.

• The animations of the cutscenes are incredibly well made. The movements of the legs and arms of the protagonists are very smooth, and a lot of love was put into details, like e.g. Molly blinking her eyes.

• The instructions of the cutscene contain the following interesting part (in pseudo-code notation):
  

       if (direction_of_Spud_movement_is_left)
       {
         // Spud entering
          draw_Molly();
       }
       else
       {
         // Spud leaving with Molly
          draw_Molly();
       }

• What is interesting here is that in both cases Molly is drawn in exactly the same way. The case-switch here is completely useless. So why is it in the code? 
  

• My guess is that in some earlier stage of development, a different routine was used for drawing Molly while she is being dragged out of the room. This routine required additional code and additional vector-data. And for the same reason as supposed above, later this feature was cut and removed when the programmers needed to fit the final version into 8K of ROM space. And the easiest way to do this was to simply patch-in the same subroutine-call into the else-branch as used in the if-branch.

• Again, this is just a theory of mine, but what might support it is one of the pictures that are printed on the back of the GCE version of the Spike box (this is not to be found on the MB version of the box). It is shown on the left below:
  

• I had always assumed that Spike uses the usual and straightforward way of playing sound samples. Like in recording the sound "Eek" at a specific sample rate, storing the sampled data, and then playing it back at the same rate. Turned out, my assumption was wrong.

• The Spike code uses parts of a complex speech engine, which creates the sound of words by putting together and replaying samples of the phonems of which those words do consist of. Simply put, in order to let Molly say "Eek", the Spike code contains sample-data for the "e"-sound and for the "k"-sound, and also some meta-data that tells the sample-playing routine to first process the "e"-sound and then to follow up with the "k"-sound. Later, the very same "k"-sound sample-data is also used for the "k" when speaking "Spike".

• This is very much like it was done in the SAM (Software Automatic Mouth) text-to-speech program, that became popular on various 8-bit systems in 1982. That software allowed the user to type in any text which was then parsed and split into phonems, for which the corresponding sound-samples then were played back.

• The Spike code does not contain a full text-to-speech engine, but only the raw sample-data of the phonems of the words which are used in the game. So there is no (straightforward) way to make Spike e.g. say "Hello Vectrex". However, the meta-data does include information regarding the speed, the pitch, and the degree of echo which is to be used with the phonems, and the sample-playing routine preprocesses the phonem-data accordingly. So, for example, to a certain limited degree it is possible to let Spike speak slower, or Molly with a slightly deeper or even more metallic voice.

• Spike uses a sample resolution of 2 bits, which means that only four different volume levels are used for playing the samples. The effective volume levels are taken from a hard-coded look-up table.
  

• Sample data is space-efficiently stored in bytes, i.e. each byte contains four 2-bit samples.

• If my measurements are correct, then the sound samples are played effectively at a rate of 7500 Hz to 8000 Hz.

• See this blog entry written by Malban for more information about Vectrex sound samples.
  

• Again, this analysis would not have been possible without Vide.
• Continued thanks to Malban for once more adding new features I suggested or asked for.