[ Originally posted to Reddit: <https://pay.reddit.com/r/d_language/comments/217fas/dragging_gunroar_into_2014/>. ]

I got an itch recently and started to port my favorite game from ABA Games[1] to 2014: gunroar[1]. Currently, it has been ported to using Derelict3 rather than Kenta Cho's manual wrapping of SDL and OpenGL. It now uses SDL2 and D2 rather than the (apparently) very ancient dialect of D it used back in 2005.

When first starting out, the first problem was getting the code to build. I'm a CMake guy, and after looking around, I was…unsatisfied with the D support files I found (for various reasons). They all seemed to copy the C++ support files too closely which seemed unnecessary since dmd, ldc, and gdc are much closer to each other than many of the C++ compilers. They also all seem to have come from the scream make era when commands were in all caps, copied things around without realizing what they're there for (e.g., CMakeCompilerId.d.in is copied by most of them, but used by none and CMakeDCompilerABI.d is useless since what CMake looks for (compiled-in strings) isn't in the file), and were missing support for things like DEPFILE and such for proper dependency resolution. In this process, two patches were made that should help: one for Ninja[3] if LDC is used and one for CMake[4] so that you get proper recompilation when files change (other generators are not supported yet since I don't think anything else reads the -deps file format of LDC; GDC will work as-is since it's GCC-compatible here). Even without these patches, one-off builds will be correct, but incremental builds are not guaranteed.

After that was the fun of getting LDC to actually accept the code. Luckily its errors are helpful even for initiates to D (the only other time I've done things with D is poking the source of various ABA Games years ago also trying to get them to compile on Linux with mixed results). Other than issues with replacing the deprecated glu* function usages, (most) things work on my machine (Fedora x86_64). I'd be interested to know how things work on other platforms and setups.

Ultimately, I'd like to get some of these games on my tablet, so Android support is on the table (though help would be appreciated!). I've opened some issues for things on the repository already.

(The other ABA Games I'm interested in are Mu-cade and Torus Troopers, so those are on my list as well.)

[1]http://www.asahi-net.or.jp/~cs8k-cyu/games/index.html#windows
[2]https://github.com/mathstuf/abagames-gunroar
[3]https://github.com/martine/ninja/pull/721
[4]https://github.com/mathstuf/CMake/commit/9523d2a55c99fb0910531ae7160b099faeab6638

On 24 March 2014 18:35, Ben Boeckel <mathstuf+dlang@gmail.com> wrote:
> [ Originally posted to Reddit: <https://pay.reddit.com/r/d_language/comments/217fas/dragging_gunroar_into_2014/>. ]
>
> I got an itch recently and started to port my favorite game from ABA Games[1] to 2014: gunroar[1]. Currently, it has been ported to using Derelict3 rather than Kenta Cho's manual wrapping of SDL and OpenGL. It now uses SDL2 and D2 rather than the (apparently) very ancient dialect of D it used back in 2005.
>
> When first starting out, the first problem was getting the code to build. I'm a CMake guy, and after looking around, I was...unsatisfied with the D support files I found (for various reasons). They all seemed to copy the C++ support files too closely which seemed unnecessary since dmd, ldc, and gdc are much closer to each other than many of the C++ compilers. They also all seem to have come from the scream make era when commands were in all caps, copied things around without realizing what they're there for (e.g., CMakeCompilerId.d.in is copied by most of them, but used by none and CMakeDCompilerABI.d is useless since what CMake looks for (compiled-in strings) isn't in the file), and were missing support for things like DEPFILE and such for proper dependency resolution. In this process, two patches were made that should help: one for Ninja[3] if LDC is used and one for CMake[4] so that you get proper recompilation when files change (other generators are not supported yet since I don't think anything else reads the -deps file format of LDC; GDC will work as-is since it's GCC-compatible here). Even without these patches, one-off builds will be correct, but incremental builds are not guaranteed.
>

GDC can also output dependencies in GNU/Make format, which is useful for incremental builds.  :-)


> After that was the fun of getting LDC to actually accept the code. Luckily its errors are helpful even for initiates to D (the only other time I've done things with D is poking the source of various ABA Games years ago also trying to get them to compile on Linux with mixed results). Other than issues with replacing the deprecated glu* function usages, (most) things work on my machine (Fedora x86_64). I'd be interested to know how things work on other platforms and setups.
>

There are about a dozen D games in Debian that all use gdc to build then, gunroar included in that list.  Originally they were packaged on all supported platforms Debian provides repositories for (ARM, PPC, SPARC, MIPS, Hurd, BSD/Debian, etc).  Switching to D2 meant loosing support because the library lacked it  (needless to say, the game maintainers were a bit grumpy, but mostly enjoyed the banter whilst I helped them learn D and port the to D2 at the same time. :)

Compare the arch package list at the bottom of these pages:

D1:  https://packages.debian.org/wheezy/gunroar
D2:  https://packages.debian.org/jessie/gunroar

I would like to tell them that this is going to be fixed before the next release.

Regards
Iain

On Monday, 24 March 2014 at 21:16:22 UTC, Iain Buclaw wrote:
>> GDC will work as-is since it's GCC-compatible here).
>
> GDC can also output dependencies in GNU/Make format, which is useful for incremental builds.  :-)

Yep ;) . The thing that is broken is Ninja + LDC without patches
and Make + LDC is broken even with patches unless Make or CMake
learns how to read its files (or LDC writes Make-like depfiles).

> There are about a dozen D games in Debian that all use gdc to build then, gunroar included in that list.  Originally they
> were packaged on all supported platforms Debian provides
> repositories for (ARM, PPC, SPARC, MIPS, Hurd, BSD/Debian,
> etc).  Switching to D2 meant loosing support because the
> library lacked it  (needless to say, the game maintainers
> were a bit grumpy, but mostly enjoyed the banter whilst I
> helped them learn D and port the to D2 at the same time. :)

Yeah, it seems like no one has actually tried to modernize the games,
instead doing the minimum amount of work needed to get them to compile.
SDL2 support and binding wrappers actually maintained are worth the
migration, IMO. Plus an actual build system rather than a hacky ant
build file ;) . I also wouldn't say I "know" D still; it's close
enough to C++ to be able to divine what's going on, but I still have
the standard library reference open all the time :) .

> Compare the arch package list at the bottom of these pages:
>
> D1:  https://packages.debian.org/wheezy/gunroar
> D2:  https://packages.debian.org/jessie/gunroar
>
> I would like to tell them that this is going to be fixed before the next release.

This is beyond my scope right now, but it's nice to know that other
arch support (namely ARM) is in the works.

--Ben

On Mon, Mar 24, 2014 at 21:42:13 +0000, Ben Boeckel wrote:
> This is beyond my scope right now, but it's nice to know that other arch support (namely ARM) is in the works.

As incentive for this, I've implemented 3 new modes tonight (though
they're all untested, they at least compile ;) ):

  - TOUCH: virtual thumbsticks;
  - DOUBLE_PLAY_TOUCH: move the two ships in DOUBLE_PLAY with your
    thumbs; and
  - TILT: accelerometer and virtual thumbstick

Modes will be available if you have the appropriate hardware (though a keyboard is always assumed at the moment).

How hard is getting D code running Android in general? It seems that there are GDC builds available for it; is that "all" that is needed?

--Ben

I've had problems with the old CMake extensions for D as well. Are you planning on posting what you've done to make it work? I think I used the old CMakeD project and had to edit and delete a few files to get it to work, but I'm not sure how much functionality I'm missing because of that.

Atila

On Monday, 24 March 2014 at 18:35:47 UTC, Ben Boeckel wrote:
> [ Originally posted to Reddit: <https://pay.reddit.com/r/d_language/comments/217fas/dragging_gunroar_into_2014/>. ]
>
> I got an itch recently and started to port my favorite game from ABA Games[1] to 2014: gunroar[1]. Currently, it has been ported to using Derelict3 rather than Kenta Cho's manual wrapping of SDL and OpenGL. It now uses SDL2 and D2 rather than the (apparently) very ancient dialect of D it used back in 2005.
>
> When first starting out, the first problem was getting the code to build. I'm a CMake guy, and after looking around, I was…unsatisfied with the D support files I found (for various reasons). They all seemed to copy the C++ support files too closely which seemed unnecessary since dmd, ldc, and gdc are much closer to each other than many of the C++ compilers. They also all seem to have come from the scream make era when commands were in all caps, copied things around without realizing what they're there for (e.g., CMakeCompilerId.d.in is copied by most of them, but used by none and CMakeDCompilerABI.d is useless since what CMake looks for (compiled-in strings) isn't in the file), and were missing support for things like DEPFILE and such for proper dependency resolution. In this process, two patches were made that should help: one for Ninja[3] if LDC is used and one for CMake[4] so that you get proper recompilation when files change (other generators are not supported yet since I don't think anything else reads the -deps file format of LDC; GDC will work as-is since it's GCC-compatible here). Even without these patches, one-off builds will be correct, but incremental builds are not guaranteed.
>
> After that was the fun of getting LDC to actually accept the code. Luckily its errors are helpful even for initiates to D (the only other time I've done things with D is poking the source of various ABA Games years ago also trying to get them to compile on Linux with mixed results). Other than issues with replacing the deprecated glu* function usages, (most) things work on my machine (Fedora x86_64). I'd be interested to know how things work on other platforms and setups.
>
> Ultimately, I'd like to get some of these games on my tablet, so Android support is on the table (though help would be appreciated!). I've opened some issues for things on the repository already.
>
> (The other ABA Games I'm interested in are Mu-cade and Torus Troopers, so those are on my list as well.)
>
> [1]http://www.asahi-net.or.jp/~cs8k-cyu/games/index.html#windows
> [2]https://github.com/mathstuf/abagames-gunroar
> [3]https://github.com/martine/ninja/pull/721
> [4]https://github.com/mathstuf/CMake/commit/9523d2a55c99fb0910531ae7160b099faeab6638

On Tue, Mar 25, 2014 at 12:53:11 +0000, Atila Neves wrote:
> I've had problems with the old CMake extensions for D as well. Are you planning on posting what you've done to make it work? I think I used the old CMakeD project and had to edit and delete a few files to get it to work, but I'm not sure how much functionality I'm missing because of that.

The stuff I'm using is in the repo[1]. The things that it doesn't do that it should so far:

  - support for anything other than Linux/{ldc,gdc};
  - cross-compiling support;
  - detecting the compiler architecture; and
  - compiler version detection.

Other than that, the things it has over the CMakeD* projects I saw:

  - proper dependencies based on import statements;
  - gdc support;
  - more modern CMake style; and
  - unused/unnecessary code removed.

The problem with the compiler version and architecture detection is that the way CMake currently does it for C/C++ is to compile a source file with preprocessor-built strings and then greps the resulting binary for ASCII strings and regex matches them to extract the information. Since D doesn't have a preprocessor and I didn't see a way to find out the compiler version or target architecture through built-in variables, this support won't work without either CMake just asking the compiler (requires CMake to know how to run the compiler to ask it...which may depend on knowing the version), or to have some way of guaranteeing a single, unbroken string that depends on the compiler show up in a D executable.

I do plan on splitting it out at some point, but without a project attached to it, testing is hard, so it's living in gunroar for now.

--Ben

[1]https://github.com/mathstuf/abagames-gunroar/tree/master/cmake