Still working on moving office (it’ll be a while - we have a lot of stuff!), but still finding time to get some things done. I put off a couple of large pieces of feature work, and mostly focused on foundational items because I’ve not had a lot of uninterrupted time - but lots of small time blocks. (There’s one exception - a new ECS!). There’s a new pre-alpha build on itch with these changes in it.

• The back-end code that handles shadows is a LOT more efficient now. It uses a geometry buffer to emit to all the cubemap layers at once, and I optimized the living daylights out of it. It’s quite a lot faster as a result. It also shows somewhat better shadows, even on low shadow-map detail levels.
• Implemented a “world flags” SSBO (shader buffer object, an OpenGL 4.3 feature). When the terrain changes, it copies the maps “flags” vector into GPU memory (it’s an int32 bitset). It’s awesome to be able to map it and do a simple memcpy rather than all the stupid fiddling with vertex buffers and attributes. This is used by other shaders.
• Reworked the terrain cube generation code slightly, fixing some “winding” issues; cubes are now ALWAYS wound correctly, so enabling GL_CULL_FACE will correctly remove only the inivisible cube faces. This gave a good performance boost, particularly on my low-end laptop.
• Rewrote the sunlight code (big dark shadows from trees were annoying me, and while it looked good it wasn’t good to play). The sun/moon shader polls the new “world flags” bitset to determine if a tile is indoors or outdoors, and lights outdoor tiles with the sun/moon. I removed sun/moon shadows, they were too confusing (and slow). It looks pretty decent right now.
• Added an exposure-based tonemapper, and some primitive code that determines exposure based on the average lightness of the screen. It needs work, but it already looks better on dark scenes.
• Re-enabled the bloom code (smudging bright lights), with less stupid blur code. It’s very subtle (I hate the overdone bloom in some games - the blurriness gives me a headache), and I’m reasonably happy with it.
• The engine now knows how to load compute shaders.
• Ran into some horrible issues with game saving/loading. I ended up rewriting my ECS. See below.
• Re-enabled the “wish” command sploosh. It sets the top of the sky to be full of water, which then stress-tests the fluids system by having it all fall and make a mess.
• Savegames now use Cereal’s binary format. I thought XML would be helpful for debugging, but it really wasn’t. Starting savegames went from 1.5mb to 120k!
• Optimized the living daylights out of the fluid dynamics code. Ended up not using a compute shader for now (I’ll almost certainly try it), after my “lets write this for the CPU to see how it should work” pass was successful for anything less than a truly extreme amount of water. Had a lot of fun playing with various scenarios in which people drowned themselves. Also identified a few problems with terrain generation giving me a river that wasn’t water-tight. Spent some fun time adjusting worldgen to produce rivers that don’t leak (I seriously love worldgen).

The New Entity-Component System (ECS)

I’ve had a pretty solid ECS going for 2.5 years now (closer to 3, my ECS actually predates the game). It’s worked fine in various other games, and has always been a good performer. It was based on EntityX, which always impressed me. I ran into problems with saving/loading games that have been going for a while (new games work every time), and after some very frustrating debugging realized that the ECS wasn’t consistent in the ID numbers it assigned to component types. Rather than force you to register every type upfront, it used a static to determine a family_id by component type on registration (and also looked these up when it saw a component). In a long-running game that introduces new components that aren’t seen during world-gen, it becomes increasingly unlikely that they will always get the same family_id. That leads to really confusing bugs, and things generally falling apart after save/load. Oops. I spent several hours trying to fix this, before concluding that some of my underlying designs in the ECS were incorrect for this type of game (they work fine for more predictable games). I also identified some inefficiencies I could fix while I was at it.

I’m a big believer in forcing myself to use interfaces, so fortunately every access to the ECS in-game goes through one interface. So I created a test project, implemented the same interface and rebuilt the entity/component store and query mechanisms from the ground up - writing tests as I went. Once it passed every test I could throw at it, I put it into NF - compiled and ran it. Other than having to clean up after deciding to use int rather than size_t in a couple of places, it ran really well. Faster than before, and load/save worked every time. :-) (This took a total of about 6 hours; I didn’t sleep much that night…)

So first up, I made the ECS require that you declare all the components with which it can interact up-front. NF uses a lot of components (98 last time I counted); this led to a truly horrific statement:

using my_ecs_t = bengine::ecs_t<position_t, designations_t, farming_designations_t, ai_tag_work_farm_plant, ai_tag_work_guarding,
        ai_mode_idle_t, ai_settler_new_arrival_t, ai_tag_leisure_shift_t, ai_tag_my_turn_t, ai_tag_sleep_shift_t, ai_tag_work_architect,
        ai_tag_work_building, ai_tag_work_butcher, ai_tag_work_farm_clear, ai_tag_work_farm_fertilize, ai_tag_work_farm_fixsoil,
        ai_tag_work_farm_water, ai_tag_work_farm_weed, ai_tag_work_harvest, ai_tag_work_hunting, ai_tag_work_lumberjack,
        ai_tag_work_miner, ai_tag_work_order, ai_tag_work_pull_lever, ai_tag_work_shift_t, architecture_designations_t,
        bridge_t, building_t, building_designations_t, construct_container_t, construct_power_t, construct_door_t, construct_provides_sleep_t,
        entry_trigger_t, receives_signal_t, smoke_emitter_t, turret_t, designated_farmer_t, designated_hunter_t,
        calendar_t, camera_options_t, claimed_t, corpse_harvestable, corpse_settler, designated_lumberjack_t, explosion_t,
        falling_t, game_stats_t, grazer_ai, health_t, initiative_t, lever_t, lightsource_t, logger_t, name_t, natural_attacks_t,
        renderable_t, renderable_composite_t, riding_t, sentient_ai, settler_ai_t, sleep_clock_t, slidemove_t, species_t,
        stockpile_t, viewshed_t, water_spawner_t, wildlife_group, world_position_t,
        item_ammo_t, item_bone_t, item_chopping_t, item_digging_t, item_drink_t, item_farming_t, item_fertilizer_t,
        item_food_t, item_hide_t, item_leather_t, item_melee_t, item_ranged_t, item_seed_t, item_skull_t, item_spice_t,
        item_topsoil_t, item_t, item_carried_t, item_creator_t, item_quality_t, item_stored_t, item_wear_t, designated_miner_t,
        mining_designations_t
    >;

I was afraid that this would kill compile times, but it had the opposite effect: all the component headers get parsed once, so the compiler is able to re-use them a lot. I also worried about size limits on parameter packs, but I haven’t hit them.

The biggest change is in how components are stored/identified. Previously, I didn’t enforce registration up-front, so the ECS did a little dance with a template component_family and a static counter to figure out an ID#. Since I didn’t know the component types at compile-time, but didn’t want to force components to adhere to an interface, a lot of things were dynamic. A component_base class contained is_deleted and the entity_id; a templated component_holder class then inherited from that base to decorate it. Finally, components were stored in a vector of unique_ptr to the template component_holder type (which in turn forced me to register a TON of base-types in Cereal). These were themselves stored in another vector, indexed by component_family index. It worked, was pretty fast, but relied upon a number of compiler optimizations to perform well (vtable elimination, and the unique_ptr being optimized away).

The new system determines family_id at compile-time, via an std::index_sequence (and the near-magical std::create_index_sequence_for function that makes a sequential ID # for each entry in a tuple). So all of the static incrementer is gone, and each component is guaranteed to get the same ID # each time. I eliminated the inheritance by making component_holder<C> a simple struct of entity_id, is_deleted and C component - so it simply “decorates” your component by adding an int ant a bool to the beginning. And since we know all of the types up front, allocating component storage becomes:

std::tuple<std::pair<size_t, std::vector<component_holder<Components>>>...> storage;

That lets me use std::get<std::pair<size_t, std::vector<component_holder<Component>>>> to retrieve the correct storage blck at compile time (and allocate the initial vectors at compile time!). The ECS constructor populates the size_t with the family_ids (helpful in some retrieval code). So the new system eliminates the unique_ptr indirection, guarantees that the vector objects (not their contents, which the vector will allocate on its own) are adjacent in memory for happy caches, and eliminates the need for a vtable/virtual lookup completely. When querying, a lot of the type lookups are now purely compile-time, which is more of a performance win than I expected.

This gives a number of advantages:

• Determining the ID# (family_id) of a given Component is now a compile-time task, and I can return a handy error message via static_assert (rather than 100+ lines of gobbledegook) if a component isn’t registered. So every function that needs to determine the IDs of component types can do so with zero overhead.
• This lets me store components in a big tuple of vector<component_holder<C>>. Accessing it via std::get<vector<component_holder_<C>>> is also compile time, so there’s zero overhead for finding the right component store. (It previously used a static counter and instantiated an empty component to find the ID, which apparently was slower than I thought!)
• Since family_id is determined at compile time, the bitset of which components an entity has is also sized automatically. I can compile-time generate a list of bit numbers to test given a variadic parameter pack of component types, so a complex query is very, very fast.
• It eliminated any allocation from query calls.
• It really cleaned up my serialization code. No more polymorphic type registrations for Cereal!
• Much to my surprise, it compiles really fast.

The net result is a big speed increase, one I really wasn’t expecting!