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

Jun 23, 2022

Hipreme

Jun 25, 2022

TheGag96

Jun 25, 2022

Jun 25, 2022

Jun 25, 2022

Jun 25, 2022

Jun 25, 2022

Jun 25, 2022

Jun 25, 2022

Jun 26, 2022

June 23, 2022

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

Posted by Hipreme

Permalink

Hipreme

Permalink

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.

On Thursday, 23 June 2022 at 03:12:30 UTC, Hipreme wrote:

There comes a big list:

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.
...
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.

If you haven't already and one doesn't already exist, could you please add an issue regarding the documentation of this to issues.dlang.org ?

On Saturday, 25 June 2022 at 17:53:23 UTC, Guillaume Piolat wrote: > On Thursday, 23 June 2022 at 03:12:30 UTC, Hipreme wrote: >> There comes a big list: >> >> - 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. > > Interesting, I never really tried optional dependencies. > Doesn't DUB produce a version=Have_flobber in case flobber is in the project? Humm I have seen some strange behaviour though when using this kind of Have_dep. So I avoid using them. As my engine is a project really big by now, the consistent case I'm using is `Have_hipreme_engine`. In which case is currently used for generating release builds, so, the scripting functions won't be loaded using the shared library, they will actually be aliased to the functions which implement them. I done like that for reducing the dependency on the system library + optimization opportunities :D In the renderer case, it is being done like that: ```json { "bindbc-opengl": {"version": "~>1.0.0", "optional": true}, "directx-d": {"path": "../../dependencies/directx-d", "optional": true}, "gles" : {"path": "../../dependencies/gles", "optional": true} } ``` And in the main project, I just do configurations for that, like, Android: ``` { "name": "android", "dependencies" : { "gles" : {"path": "../../dependencies/gles", "optional": true} }, "versions" : ["GLES3"] } ```

Forums