Re: Dragging Gunroar into 2014

[Ben Boeckel]

On Tue, Mar 25, 2014 at 12:53:11 +, 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

Re: Dragging Gunroar into 2014

[Atila Neves]

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


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

Re: Dragging Gunroar into 2014

[Ben Boeckel]

On Mon, Mar 24, 2014 at 21:42:13 +, 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

Re: Dragging Gunroar into 2014

[Ben Boeckel]

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

Re: Dragging Gunroar into 2014

[Iain Buclaw]

On 24 March 2014 18:35, Ben Boeckel  wrote:
> [ Originally posted to Reddit:
> .
> ]
>
> 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

Dragging Gunroar into 2014

[Ben Boeckel]

[ Originally posted to Reddit: 
. 
]


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