- We do .not. have some kind of magical data compression machine that is able to squeeze
  hundreds of megabytes of mesh/texture and sound data into 96k. We merely store the
  individual steps employed by the artists to produce their textures and meshes, in a very
  compact way. This allows us to get .much. higher data density than is achievable with
  normal data compression techniques, at some expense in artistic freedom and loading times.
- .kkrieger is not written in 100% assembler/machine language. Not even nearly. Like the
  vast majority of game projects being developed today, .kkrieger was mostly written in
  C++, with some tiny bits of assembler where it is actually advantageous (notably, there
  are a lot of MMX optimisations in the texture generator). 
- A kilobyte is, historically, defined to be 1024 (2^10) bytes, not 1000. Thus .kkrieger is
  a game in 96k even though it's actually 98304 bytes. 
- The concept of the texture/mesh generators was developed by fiver2. We do .not. want to
  claim that the techniques we used to develop .kkrieger are new inventions. It´s rather a 
  selection of useful operations and their parameters to optimise the results.