move todo file to docs directory

and stupid caps, what was I thinking

diff --git a/TODO b/TODO
deleted file mode 100644 (file)
index 93b880c..0000000
--- a/TODO
+++ /dev/null
@@ -1,110 +0,0 @@
-block placement/removal timers
-
-       removal timing depending on the tool/block combination
-       animation for remove
-
-composite entity animations
-
-       complex entities are made up of part which have their own local
-       transform that can be animated (like e.g. an arm or head)
-
-font rendering
-
-       with background now being a thing, a padding might be nice
-       that or maybe separate bg from fg rendering
-
-       it may also be feasible to get rid of SDL_ttf and use freetype
-       directly to eliminate the unneccessary surface creation
-       ftgl might also be worth looking at
-
-command line
-
-       usefull for development and later on world administration
-
-persistence
-
-       merge IO counters, so number of operations per frame is kept
-       low, no matter what exactly is done
-
-       store some kind of byte order mark?
-
-block asset loading
-
-       parameterization of chunk generator should be less static/dangerous
-
-networking
-
-       write tests
-       do some manual testing
-       some more testing
-       a little optimization
-
-launcher ui
-
-       select or create a world with configurable parameters
-
-entity ai
-
-       pathfinding, chase and roam states
-
-(block) lighting
-
-       occlusion/neighbor light mixing is implemented, but still linear
-       this could be solved by using a pre-interpolated light texture and
-       mapping light levels to coordinates on that
-
-       also: how could block light affect entity lighting?
-       maybe get the interpolated light level at the entity's center and use
-       that as the light power for the directional lighting shader and use a
-       direction that's fixed relative to the camera?
-
-       there's a bug where a chunk's model is not updated if its neighbor
-       changes border light levels
-       I kinda mitigated it a little for direct neighbors during linking, but
-       it still can happen in (hopefully) rare corner cases
-
-       propagation through semi-filled blocks is wonky. I worked around it by
-       having the light propagate into solid blocks, but feels like this
-       could cause some weird behaviours
-
-gravity
-
-       maybe like light levels? should also store a direction with it in
-       that case. also, global gravity may be a world option.
-       no, per-block gravity vector is most probably too expensive.
-       better have the chunks store a few point masses (maybe blocks that
-       emit gravitation?) and calculate from that
-
-block attributes
-
-       when blocks are not just a solid rock of color, attributes may
-       become interesting. like labels on signs and contents of
-       containers
-
-chunk traversal
-
-       maybe the chunk loader should keep an index of interesting, if not
-       all chunks by position, possibly base-relative
-
-       profiling indicates that this is not neccessary atm. maybe it will
-       when there's some more action in the world
-
-transparency (blocks and entities)
-
-       transparent blocks because awesome
-
-world generator that is not boring
-
-       maybe divide into biomes and add special features like
-       settlements, ruins, all kinds of interesting stuff
-
-entity/world collision
-
-       first draft of entity/world collision is implemented
-       it jitters and has some surprising behaviour
-       finding a spawn point which doesn't put entities in solids is
-       now a little more crucial. press N if you're in trouble
-
-better noise
-
-       current simplex noise implementation repeats itself pretty quickly

diff --git a/doc/todo b/doc/todo
new file mode 100644 (file)
index 0000000..93b880c
--- /dev/null
+++ b/doc/todo
@@ -0,0 +1,110 @@
+block placement/removal timers
+
+       removal timing depending on the tool/block combination
+       animation for remove
+
+composite entity animations
+
+       complex entities are made up of part which have their own local
+       transform that can be animated (like e.g. an arm or head)
+
+font rendering
+
+       with background now being a thing, a padding might be nice
+       that or maybe separate bg from fg rendering
+
+       it may also be feasible to get rid of SDL_ttf and use freetype
+       directly to eliminate the unneccessary surface creation
+       ftgl might also be worth looking at
+
+command line
+
+       usefull for development and later on world administration
+
+persistence
+
+       merge IO counters, so number of operations per frame is kept
+       low, no matter what exactly is done
+
+       store some kind of byte order mark?
+
+block asset loading
+
+       parameterization of chunk generator should be less static/dangerous
+
+networking
+
+       write tests
+       do some manual testing
+       some more testing
+       a little optimization
+
+launcher ui
+
+       select or create a world with configurable parameters
+
+entity ai
+
+       pathfinding, chase and roam states
+
+(block) lighting
+
+       occlusion/neighbor light mixing is implemented, but still linear
+       this could be solved by using a pre-interpolated light texture and
+       mapping light levels to coordinates on that
+
+       also: how could block light affect entity lighting?
+       maybe get the interpolated light level at the entity's center and use
+       that as the light power for the directional lighting shader and use a
+       direction that's fixed relative to the camera?
+
+       there's a bug where a chunk's model is not updated if its neighbor
+       changes border light levels
+       I kinda mitigated it a little for direct neighbors during linking, but
+       it still can happen in (hopefully) rare corner cases
+
+       propagation through semi-filled blocks is wonky. I worked around it by
+       having the light propagate into solid blocks, but feels like this
+       could cause some weird behaviours
+
+gravity
+
+       maybe like light levels? should also store a direction with it in
+       that case. also, global gravity may be a world option.
+       no, per-block gravity vector is most probably too expensive.
+       better have the chunks store a few point masses (maybe blocks that
+       emit gravitation?) and calculate from that
+
+block attributes
+
+       when blocks are not just a solid rock of color, attributes may
+       become interesting. like labels on signs and contents of
+       containers
+
+chunk traversal
+
+       maybe the chunk loader should keep an index of interesting, if not
+       all chunks by position, possibly base-relative
+
+       profiling indicates that this is not neccessary atm. maybe it will
+       when there's some more action in the world
+
+transparency (blocks and entities)
+
+       transparent blocks because awesome
+
+world generator that is not boring
+
+       maybe divide into biomes and add special features like
+       settlements, ruins, all kinds of interesting stuff
+
+entity/world collision
+
+       first draft of entity/world collision is implemented
+       it jitters and has some surprising behaviour
+       finding a spawn point which doesn't put entities in solids is
+       now a little more crucial. press N if you're in trouble
+
+better noise
+
+       current simplex noise implementation repeats itself pretty quickly