Another fluxbox user here. I've basically ran the same configuration for nearly 15 years now. Everything is in muscle memory and never changes. Totally the best UX
And the sunset calculator doesn't need a location provider. All it needs are location coordinates which can be given to the calculate function.
In fact the whole thing then becomes a standalone function which takes Location and other relevant parameters and returns the computer sunrise/sunset values. Pure function and super easy to unit test.
If one needs to do a lot of "mockups" for your unit tests then maybe one needs to consider the API and class design. Removing needless coupling helps testability by removing the need to use mocks in the first place.
In design terms, I would claim that Sunset Calculator is a "component" (an integration of units), with a "required interface" (i.e. abstracted) that provides the coordinates.
A role of one unit inside this component is to use the provided coordinates and only perform the calculation.
I never really used GLM, but Eigen was substantially slower than DirectXMath https://github.com/microsoft/DirectXMath for these things. Despite the name, 99% of that library is OS agnostic, only a few small pieces (like perspective projection matrix formula) are specific to Direct3D. When enabled with corresponding macros, inline functions from that library normally compile into pretty efficient manually vectorized SSE, AVX or NEON code.
The only major issue, DirectXMath doesn’t support FP64 precision.
But you can already do this with DLLs or with SOs files. You can keep your network logic for example inside another module (perhaps the host app) and then load the logic that acts on the received data as a dll.
Process separation and IPC natively using a library such as Qt is literally a few hundred lines of code.
But that's sort of moving the goal posts now. Original claim for WASM was that it allows hot reloading. Which is a thing you can do with DLLs just fine.
No, the original claim of Wasm definitely isn't only one side point about development. The original claim of Wasm is that all of these features are packaged in a well thought out whole + the success of this platform (thanks to browsers mostly) is what's so interesting about it.
It is also hard to contain the DLL/SO, every system has different mechanisms to ensure it can not access 'everything'. Wasm, as build for the browser, has it in its DNA.
Yeah this is impossible because code that isn't written cannot document itself and then the only option is to have a comment. And sometimes the meaningful thing is exactly what doesn't exist. For example here we're not doing X because of Y.
Hi, thanks. Honestly.. I haven't compared. I've built this as a passion project not as a "product" with a product/market fit or competitive landscape in mind. I mean there are already so many engines out there that you can't even give them away for free. So i built it with the features that i had in mind and what i have needed for my demos and what i need for my games.
The demo games have Emscripten filesystem images that vary from 6mb to 100mb. These sizes reflect the combined size of the raw game resources (i.e. fonts, textures, audio files etc)
