From: Daniel Karbach Date: Fri, 25 Sep 2015 07:26:48 +0000 (+0200) Subject: move todo file to docs directory X-Git-Url: https://git.localhorst.tv/?a=commitdiff_plain;h=8e0cb4f95d87e9e8196ca6aa06dcaeab855b9a2e;p=blank.git move todo file to docs directory and stupid caps, what was I thinking --- diff --git a/TODO b/TODO deleted file mode 100644 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 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