combine text handling stuff into a class

[blank.git] / TODO

diff --git a/TODO b/TODO
index b7b614b2038c9885d4822868ccec5e8fd76ae98e..8cea29221b5cc7ee94086e8b4cd359a655ac2b9b 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,8 +1,7 @@
 block placement/removal timers
 
-       currently block placement and removal is instantaneous. it should
-       actually take some time to place and remove a block. with
-       removal timing depending on the tool used to remove the block
+       removal timing depending on the tool/block combination
+       animation for remove
 
 composite entity animations
 
@@ -13,13 +12,18 @@ textures
 
        do I need to say anything? :)
 
-command line
+font rendering
 
-       usefull for development and later on world administration
+       with background now being a thing, a padding might be nice
+       that or maybe separate bg from fg rendering
 
-font 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
 
-       mostly for labelled blocks and some ui elements
+command line
+
+       usefull for development and later on world administration
 
 networking
 
@@ -40,13 +44,31 @@ entity ai
 
 (block) lighting
 
-       light levels are roughtly implemented. the shader has to be
-       adjusted so they actually have an impact on the resulting color
+       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
 
@@ -59,6 +81,9 @@ 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
@@ -67,3 +92,14 @@ 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