Molecular Matters

This unfortunately breaks down with (bad acting) NIFs. Thankfully you can mark 'em as the dirty evil little things that they are (with negligible overhead): ERL_NIF_DIRTY_JOB_CPU_BOUND. [1]

I implore anyone interested in Erlang or its surrounding languages, to read its source code. [2] More specifically, the BEAM. I'll warn you that it's very 80's hackeresque, but in a good way. Incredibly pragmatic. The way they achieve their world-class scheduling? Tip: not via a perfect theoretical design cooked up in some comp-sci lab. [3] If you've been following game engine design within the last 9 years or so, you'll probably have a good idea of how they do it. [4][5]

[1]: https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7#.sakhllz5r

[2]: https://github.com/erlang/otp/tree/maint/erts/emulator/beam

[3]: https://hamidreza-s.github.io/erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html

[4]: http://blog.molecular-matters.com/2012/04/05/building-a-load-balanced-task-scheduler-part-1-basics/

[5]: There's a hell of a lot of depth to this problem domain. Charles Bloom's guiding principles for Oodle are spot, and well worth a look.

We've invested some time to improve this situation for the games we port, at least to some extent. Keyboard input is read as a combination of scan code + win32 virtual key information to determine the physical key pressed on your keyboard. This way the keybindings are (almost) independent of the keyboard layout.

However, we also reflect your current key bindings with dynamic button prompts that tell you which key to press in game. For this we translate the determined physical key back through the selected keyboard layout to figure out what the corresponding label on your keyboard might be.

Most of this is just win32 API shenanigans, but the following post provides a bit more detail on reading inputs this way.

https://blog.molecular-matters.com/2011/09/05/properly-handling-keyboard-input/

Glad to hear that!

I dont have anymore the exact numbers, usually when you have around 1000 commands/calls you won't really feel a difference, in that case even using std::sort is fast enough and there's no point in using radix sort, however when you go over 10k commands/calls you'll feel it (can be up to a msec on the dispatch side).

You can check this great post that provides numbers (see part 4): https://blog.molecular-matters.com/2014/11/06/stateless-layered-multi-threaded-rendering-part-1/

The performance should be very similar and it even goes further by adding thread local storage to reduce false sharing even more, which I didn't add but should be considered as it's easy to do.

If you are into no-nonsense software design, Molecular Musings [1] written by Stefan Reinalter is also a goldmine. As is anything written or said on topic by Mike Acton, whose ramblings de-facto brought DOD into the mainstream [2][3]. Regarding good old days, remember Flipcode? ;) [4]

[1] https://blog.molecular-matters.com/
[2] https://macton.smugmug.com/Other/2008-07-15-by-Eye-Fi/n-xmKDH#!i=593426709&k=ZX4pZ
[3] https://www.youtube.com/watch?v=rX0ItVEVjHc
[4] https://flipcode.com/archives/articles.shtml

The home page describes it as "the foundation for all our tools, with parts of the engine being available to licensees as stand-alone game engine bits."

This post suggests that it is intended to compete with Unreal and CryEngine:

http://blog.molecular-matters.com/2015/08/12/what-happened-to-the-molecule-engine/

One of the posts about runtime-compiled C++ states that iOS is not a target platform.