What I've learned while trying to port my game engine to PS Vita

[Hipreme]

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, `always` use `size_t` instead 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 
`version` statement 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 `mixin` statements 
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/catch` 
functionality 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.