www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Dragging Gunroar into 2014

reply "Ben Boeckel" <mathstuf+dlang gmail.com> writes:
[ Originally posted to Reddit: 
<https://pay.reddit.com/r/d_language/comments/217fas/dragging_
unroar_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
Mar 24 2014
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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
Mar 24 2014
parent reply "Ben Boeckel" <mathstuf+dlang gmail.com> writes:
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
Mar 24 2014
parent Ben Boeckel <mathstuf gmail.com> writes:
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
Mar 24 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
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_
unroar_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
Mar 25 2014
parent Ben Boeckel <mathstuf gmail.com> writes:
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
Mar 25 2014