There comes a big list:
- Doing my own stdlib for reducing compilation time proved its worth beyond that, it greatly increased the portability on my engine while not being full generalist as the language tries to provide.
- For implementing a game engine stdlib, libc functions most of the time are enough, one time or another you'll need OS specific functions.
- When doing traditional iterations on array or dealing with its length,
size_tinstead of "int", "ulong" or "uint". It made me realize that even D having its fixed type sizes, we will always be stuck to this type.
- Dub's optional dependencies. They basically needs to be added to the main project for being included. After doing my project for so long and reducing a lot of dependencies, I found many uses to that. I can guarantee that you will almost always need a
versionstatement together with this optional though.
- Even more separated modules. When building for an obscure environment, you'll need to break into pieces even more. Using a custom druntime which was crashing for unknown reasons were really easier to debug by deactivating each module separately.
- The druntime is an obscure monster in which only those which have been fighting against it for years can understand it. Simply hard to know what each function does, hard to find function signatures, even its definitions. There is
mixinstatements generating core functions which does not even have a comment saying
//Generates _d_somefunction. A comment showing which kind of syntax triggers that function would be really helpful.
- Druntime is more obscure than I just described. It crashes a lot on undefined druntime functions which could be simply avoided as from a null check. TypeInfo is really a hell to understand and modifying it anyway to support one feature or another can break other things that seems totally unrelated.
- LWDR is really a nice project! You guys could check it https://github.com/hmmdyl/LWDR. Although it does not ambitions itself with bringing a fully featured GC, it at least compromises itself to make the language work on foreign platforms. Just by adding it from my dub project and configuring my dflags to the correct float abi, correct cpu and triple, I was able to build my project, made array operations work, classes, interfaces, dynamic casts and a lot of things that makes D nice.
- If you're still converting your C files by hand, you should really try dstep. Comparing dstep with dpp source generation, I could check that dstep generated a much smaller file without mixin statements which helps a lot on build speed.
- GLES 2 to GLES 3 is most of time compatible with each other, I could only check the great difference being no VertexArrayObject and no Uniform Buffer Object. Which were really simple to solve as I've done an abstraction over those 2 concepts.
- I feel a lot more conscious before using a feature that could not be supported in future platforms, like, if I wish to someday support WASM and even PS5, I would understand which features is really harder to support as we can't guarantee there will always be someone implementing cross platform features (thanks a lot Kinkelin)
- Null implementation can be really helpful, some dependencies may be using another dependencies which could not be supported in your target platform, the best thing is to deactivate and use the specific thing.
- I've already done a betterC String, Array and Map implementation. When I tried testing on that platform, it didn't work because the destructor depends on the
try/catchfunctionality being implemented. I really feel that this was a lost time specially because on how hard it seems to implement exceptions.
- Adding dependencies when compiling a staticLibrary from dub does nothing. If you want to build a staticLibrary, one should use it as a sourceLibrary.
As a result of all that, I was almost able to port my entire engine to it! Which is pretty exciting. But that arises some questions:
Every custom druntime I've seen has a real problem when trying to implement associative arrays. Why they are so hard to implement when it is so simple to make a reusable code for them?
I really tried my best trying to help or understanding custom runtimes, but they are really hard for amateurs to touch their hand on it while even trying to do the basic. They should be documented, because there's a lot of code that feels manually written to feel obscured for no one understanding it, the variables names, the lack of comments on the hook functions, its simply bizarre.