www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What I've learned while trying to port my game engine to PS Vita

reply Hipreme <msnmancini hotmail.com> writes:
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.
Jun 22 2022
next sibling parent reply TheGag96 <thegag96 gmail.com> writes:
On Thursday, 23 June 2022 at 03:12:30 UTC, Hipreme wrote:

 (snip)


It's cool to see another person use D on game consoles! Is this a 
homebrew game or one built with the real Vita SDK?
Jun 24 2022
parent Hipreme <msnmancini hotmail.com> writes:
On Saturday, 25 June 2022 at 04:04:53 UTC, TheGag96 wrote:

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

 (snip)


 It's cool to see another person use D on game consoles! Is this 
 a homebrew game or one built with the real Vita SDK?


Well Yea! As my engine supports Xbox, it would be nice to being 
able to expand and although 3DS and Wii U being easy to get hands 
on their SDK, I feel that Vita is more achievable.

This is using the homebrew vita sdk. I believe that no one can 
use the real vita sdk as its store has already been disabled for 
publishing.
Jun 25 2022
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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 ?
Jun 25 2022
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 25 June 2022 at 13:11:24 UTC, Nicholas Wilson wrote:

 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 ?


Nvm, https://issues.dlang.org/show_bug.cgi?id=23212
Jun 25 2022
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
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?
Jun 25 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 26/06/2022 5:53 AM, Guillaume Piolat wrote:

 Doesn't DUB produce a version=Have_flobber in case flobber is in the 
 project?


Yes it should.
Jun 25 2022
prev sibling parent Hipreme <msnmancini hotmail.com> writes:
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"]
}
```
Jun 25 2022
prev sibling parent reply Sergey <kornburn yandex.ru> writes:
On Thursday, 23 June 2022 at 03:12:30 UTC, Hipreme wrote:

 [...]


Really interesting story! Thank you for sharing it.
Is it possible to see some screenshots from the engine?
Jun 25 2022
parent Hipreme <msnmancini hotmail.com> writes:
On Saturday, 25 June 2022 at 20:36:52 UTC, Sergey wrote:

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

 [...]


 Really interesting story! Thank you for sharing it.
 Is it possible to see some screenshots from the engine?


Sorry! I'm working on it right now, some people said it is 
missing examples as they're the best documentation, so, that's 
priority N°1 right now.

The specific state right now is making easier for people (not me) 
integrating their code with the engine. As it has a D hotload 
system, it may not be so trivial for someone just entering the 
project. So the project generator and the run command line is 
what I'm finishing right now.
Jun 26 2022