Ok I don't know if that is my C brain talking but the `m_` for member variables in classes in C++ makes me question using classes at all. Main benefit of methods are implicit `this` pointer (and obj.func but meh). But that creates confusion which are class and which are function variables. So instead of being explicit and using `this` you add `m` or `_m` before that. With free function you can even define your own name for instead of `this`and call that from the method and have a C API as well.

@uucidl Could be skill issue on my end. Not knowing all the secrets, 'unmask' and compiler flags but at least for my example with my current base of knowledge feels like a let down. Understandably ISPC tries to be very conservative when translating for code that does not fit as closely.

But it feels fragile and similar to trying to get multiple compilers to generate good assembly for a piece of C code. Lots of confusion why it generated this output and trying nudge in a direction.

Unhappy with ISPC. Perfect example with 32-byte alignment, data layout multiple of lane size. So it should just load, compute and store. Hand written version is ~700 line in C and ~600 instructions in AVX2 assembly. ISPC generates ~2500 instructions with vmaskmovps everywhere (--opt=force-aligned-memory) + assumes. Feels like worst of both worlds. Needs knowledge of SIMD intricacies while fighting compiler to generate good code. Would rather write Neon, SSE and AVX2 separately then trust ISPC

Is there any good editor on linux that has builtin perforce support? Only one I know is VS Code and I kinda want to stay away from that...

The same group also build the lonely mountain in 10.000 hours of work with around 30 people: https://www.youtube.com/watch?v=ZibVpFAmCfY . Absolute massive undertaking with a lot of detain (sadly video is in German but still visually stunning without context)

Minas Tirith from Lord of the Rings rebuild in Enshrouded. https://www.youtube.com/watch?v=0MqOufzvAIA . Just showing the scale some of our players go when building.

Some more great lighting screenshots

@christer Congrats and have a well deserved rest and wish you the best for whatever comes next in the future.

For those interested some of our rendering team were at the Graphics Programming Conference and talked a bit about Realtime Global Illumination in Enshrouded: https://www.youtube.com/watch?v=57F1ezwH7Mk

@pervognsen We started with around 10 programmers and for 4-5 years with around 12-15 programmers and Keen in total 40 people including office, QA, leadership,... until roughly EA launch and have grown now to 60. With ~25 programmers. Overall very deliberate slow growth over time. Initial team was experienced with average age of 36 and with many 10+ years at Keen. Also grew a lot of young talent later with hiring.

@pervognsen In terms of content like building, crafting, scale, sense of adventure it already delivers a lot (100+ hours). Progression also improved a lot since EA launch. Personally the biggest weakness for me is the combat. Lots of interesting ideas but It is closer to current survival games and less like modern RPGs and lacks in depth for me personally.

@pervognsen Building can be done with "templates" for example walls, edges, roofs,... but also block by block. Number of blocks keeps on growing by each patch. Since everything is voxel based non 90 degree builds look more voxelixed. We also have an automatic displacement system similar to tiny blade but a lot simpler to make things look nicer and not blocky.

Still lots to do but so far what I am personally most proud of is how fast we are in terms of updates and new patches with content.

@pervognsen Since launch a lot has changed. Videos from 6 month ago listing changes for 16 minutes https://www.youtube.com/watch?v=N8diNdZNZHs and we are now two additional patches in: https://www.youtube.com/watch?v=EInxe1MnlbQ. Launch is next year while keep on working on our road map (water).

Yes world is voxel based (underground bases). World is fully destructible but persistent changes are only in freely user placed build zones (can be combined up to 150x150m each). Players also build Minas Tirith 1on1.

Also awe inspiring what our players are building in game

I don't often post about our game Enshrouded but seeing the great work our rendering team has done over the last years and the last patch is something to behold. Visually absolutely stunning. Especially since it is a voxel game which comes with its own challenges.

Watching Digital Foundries interview with Billy Khan https://youtu.be/DZfhbMc9w0Q?feature=shared&t=413 and this section about keeping latency and variance down between frames as much as possible by basically executing at worse-case at all time (almost like a hard real time system) just makes me so happy to hear.

Basically supporting the intuition I had of my current way of thinking about performance and code architecture.

Also focus on speed of iteration especially on content side is something that Keen really shines.

Resulting source looks similar to safety-critical code, that uses very few and basic programming language features (record/struct, conditions, arrays, for loops). No dynamic arrays, list, arenas...

Why is that interesting? Well for one language support is great. But also useful for LLMs which generate better output. Resulting in the biggest win for programming with LLMs for me in generating problem specific, optimized (SIMD) code based on generalized libraries/solutions.

Had a bit of yak shave with formal Design by Contract. Don't like it. The formal part is just not worth it. So went back to (better) runtime checks.

Formal verification guarantee that checks are correct for all cases. Runtime asserts check the code passes/states being run. Bugs are in corner cases, which bothered me.

Solution: always run at worse case. Asserts become as good as formal verification. Result is low variance helped by fixed arrays, bounded loops and precise state verification.

Finding the globally optimal memory layout seems to be an np-complete problem (if I am not terribly mistaken) but are there any heuristics or algorithms that fair better than a locally optimal allocator?

@MikkoMononen@gamedev.place @slembcke@gamedev.place Ah you are right I completely forgot about this version. Yes having the list in the separate array itself. Yeah init, insert, remove, update similar to stack. Like bit set data that is not active is not cached unlike the 'active' member check in the free array which forces a cache load in all cases (see my other toots).