What I've learned while trying to port my game engine to PS Vita
Hipreme
msnmancini at hotmail.com
Thu Jun 23 03:12:30 UTC 2022
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.
More information about the Digitalmars-d
mailing list