assets/developer-notes/stephanie-gawroriski/2015/10/14.mkd

   1 # 2015/10/14
   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 ## 02:19
  10
  11 Found this nice animation, looks like a moving staircase. I have different
  12 animations to choose a color depending on the block type and I stumbled upon
  13 this one, so I will need to figure out what something to give to it.
  14
  15 ## 12:00
  16
  17 I can calculate the face offset coordinates using the face direction code I
  18 have written.
  19
  20 ## 12:11
  21
  22 Or I can just use precalculated coordinates. I have a tissue box next to me so
  23 I can quickly determine the values visually rather than mathematically. I
  24 suppose this is cheating however.
  25
  26 ## 12:27
  27
  28 It is possible to simulate a Z buffer sort of using the framebuffer graphics.
  29 I just have to use a byte based mode say grayscale.
  30
  31 ## 13:20
  32
  33 However Z buffers could potentially be slow because of the per pixel stuff
  34 going on. That is also a ton of array bound checks.
  35
  36 ## 13:29
  37
  38 I can determine which areas of a chunk are visible by using the mapping stuff
  39 and a simple set of flags for each block in a chunk which indicate the faces
  40 which are visible from that block. The flood fill algorithm can calculate that
  41 information as needed. This requires recalculation whenever a block is changed
  42 however, but for chunks which are static (such as those consisting entirely of
  43 air or terrain the player walks over to ignore) then it only has to be
  44 calculated once.
  45
  46 ## 14:45
  47
  48 Believe I need to change the way the loop is called, because with the locking
  49 and such, the game becomes very sluggish. I could most likely split the
  50 framebuffer and a few other things out so that they are controlled by the main
  51 loop rather than having the code rely on Swing doing things. Then this way it
  52 will hopefully be a smooth experience rather than missing locks and such. If I
  53 remove all of the locks I will have the game run only in a single thread with
  54 swing stuff in other threads.
  55
  56 ## 19:39
  57
  58 After changing the render stuff but before removing the synchronization stuff,
  59 the frame time is rather horrible.
  60