X-Git-Url: https://git.localhorst.tv/?a=blobdiff_plain;f=TODO;h=93b880c8b0ea80f54821098d9eb26e72d19a2453;hb=2e3774eb3f2d5d23a08731175b168566457e2192;hp=244e938c259c8283cafa73b09be54cbeba6fb3db;hpb=c877ddd21f402381d88a6bebdd5c7c0b4ac28ba9;p=blank.git diff --git a/TODO b/TODO index 244e938..93b880c 100644 --- a/TODO +++ b/TODO @@ -1,34 +1,43 @@ 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 complex entities are made up of part which have their own local transform that can be animated (like e.g. an arm or head) -textures +font rendering + + with background now being a thing, a padding might be nice + that or maybe separate bg from fg rendering - do I need to say anything? :) + 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 -font rendering +persistence - mostly for labelled blocks and some ui elements + merge IO counters, so number of operations per frame is kept + low, no matter what exactly is done -networking + store some kind of byte order mark? - exchange of chunks and entities +block asset loading -persistence + parameterization of chunk generator should be less static/dangerous - unloaded chunks should be saved to disk and restored when they - are loaded again +networking + + write tests + do some manual testing + some more testing + a little optimization launcher ui @@ -40,17 +49,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 - - there seems to be a bug with propagating light across chunk borders + 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 @@ -63,6 +86,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 @@ -74,10 +100,11 @@ world generator that is not boring entity/world collision - entities should be stopped from entering solid parts of the world + 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 - also there seems to be a (imo) better implementation here: - http://flafla2.github.io/2014/08/09/perlinnoise.html