TODO

   1 block placement/removal timers
   2
   3         removal timing depending on the tool/block combination
   4         animation for remove
   5
   6 composite entity animations
   7
   8         complex entities are made up of part which have their own local
   9         transform that can be animated (like e.g. an arm or head)
  10
  11 textures
  12
  13         okay, now I need a better solution for the crosshair ^^
  14
  15 font rendering
  16
  17         with background now being a thing, a padding might be nice
  18         that or maybe separate bg from fg rendering
  19
  20         it may also be feasible to get rid of SDL_ttf and use freetype
  21         directly to eliminate the unneccessary surface creation
  22         ftgl might also be worth looking at
  23
  24 command line
  25
  26         usefull for development and later on world administration
  27
  28 persistence
  29
  30         merge IO counters, so number of operations per frame is kept
  31         low, no matter what exactly is done
  32
  33         store some kind of byte order mark?
  34
  35 networking
  36
  37         exchange of chunks and entities
  38
  39 launcher ui
  40
  41         select or create a world with configurable parameters
  42
  43 entity ai
  44
  45         pathfinding, chase and roam states
  46
  47 (block) lighting
  48
  49         occlusion/neighbor light mixing is implemented, but still linear
  50         this could be solved by using a pre-interpolated light texture and
  51         mapping light levels to coordinates on that
  52
  53         also: how could block light affect entity lighting?
  54         maybe get the interpolated light level at the entity's center and use
  55         that as the light power for the directional lighting shader and use a
  56         direction that's fixed relative to the camera?
  57
  58         there's a bug where a chunk's model is not updated if its neighbor
  59         changes border light levels
  60         I kinda mitigated it a little for direct neighbors during linking, but
  61         it still can happen in (hopefully) rare corner cases
  62
  63         propagation through semi-filled blocks is wonky. I worked around it by
  64         having the light propagate into solid blocks, but feels like this
  65         could cause some weird behaviours
  66
  67 gravity
  68
  69         maybe like light levels? should also store a direction with it in
  70         that case. also, global gravity may be a world option.
  71         no, per-block gravity vector is most probably too expensive.
  72         better have the chunks store a few point masses (maybe blocks that
  73         emit gravitation?) and calculate from that
  74
  75 block attributes
  76
  77         when blocks are not just a solid rock of color, attributes may
  78         become interesting. like labels on signs and contents of
  79         containers
  80
  81 chunk traversal
  82
  83         maybe the chunk loader should keep an index of interesting, if not
  84         all chunks by position, possibly base-relative
  85
  86         profiling indicates that this is not neccessary atm. maybe it will
  87         when there's some more action in the world
  88
  89 transparency (blocks and entities)
  90
  91         transparent blocks because awesome
  92
  93 world generator that is not boring
  94
  95         maybe divide into biomes and add special features like
  96         settlements, ruins, all kinds of interesting stuff
  97
  98 entity/world collision
  99
 100         first draft of entity/world collision is implemented
 101         it jitters and has some surprising behaviour
 102         finding a spawn point which doesn't put entities in solids is
 103         now a little more crucial. press N if you're in trouble
 104
 105 better noise
 106
 107         current simplex noise implementation repeats itself pretty quickly