assets/developer-notes/stephanie-gawroriski/2016/01/05.mkd

   1 # 2016/01/05
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 00:38
  10
  11 I should look at the XPM decoder code and make sure that it is more safe than
  12 usual.
  13
  14 ## 00:48
  15
  16 The code is about a year old and is rather ugly compared to how I write code
  17 now. Although currently only Squirrel Quarrel uses it my OS will rely on XPMs
  18 and such so it should be better handled.
  19
  20 ## 11:48
  21
  22 Time to continue work on my XPM decoder/encoder.
  23
  24 ## 12:29
  25
  26 I wonder if I can split off some AWT stuff such as shapes and images into their
  27 own package.
  28
  29 ## 16:28
  30
  31 So far this new XPM reading code looks much better. I believe for my voxel data
  32 I am going to have a group of XPMs be the image data for the voxel. Then for
  33 Squirrel Quarrel all voxels will be 16x16x16 so that they remain simple. The
  34 sprites would be scaled as needed for larger units (such as buildings).
  35
  36 ## 19:52
  37
  38 The sample XPM at [http://www.fileformat.info/format/xpm/egff.htm] is not
  39 readable by GIMP and looks very oddly formed. ImageMagick fails on it, however
  40 the image viewer I use can read it. So I suppose I will have to guess how it is
  41 to be viewed.
  42
  43 ## 22:03
  44
  45 Despite the sample plaid.xpm not loading in GIMP and looking wrong in my image
  46 viewer, it actually looks mostly nice in my decoder. I just need a fallback
  47 for short rows.
  48