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
+audio
- mostly for labelled blocks and some ui elements
+ do the sources thing rightâ„¢
+ (or at least in a way that it doesn't error out on shutdown :P )
-networking
+persistence
- exchange of chunks and entities
+ merge IO counters, so number of operations per frame is kept
+ low, no matter what exactly is done
-persistence
+ store some kind of byte order mark?
+
+block asset loading
- unloaded chunks should be saved to disk and restored when they
- are loaded again
+ parameterization of chunk generator should be less static/dangerous
+
+networking
+
+ exchange of chunks and entities
launcher ui
(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
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
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