Android and iOS tests

[Jebbs]

LDC is getting pretty close with being able to build for Android. I think that for the most part it works.

I'm REALLY curious if I can get DSFML running on Android. That would be pretty damn amazing.

[aubade]

For what it's worth? I've gotten SFML building and working on ARM Linux with OpenGL ES (which isn't android but is a step closer than the desktop), so we won't be too far off once the D compilers catch up.

It does unfortunately need a newer SFML than what DSFML can interface with at the moment, so I have'nt been able to test that yet.

[luke5542]

I think this would be a great step for the library! If LDC is so close, is it simply the DSFMLC side of things that's holding everything back?

@aubade Which version of SFML is the earliest that has support for Android (or at least the ARM/GLES)? I'm wondering how long it might take to make the upgrade, if only for a POC test.

[aubade]

I believe it's SFML 2.2--This also has the changes to BlendMode, so it'll be a bit of work to get DSFML updated to it.

[Jebbs]

Yes, BlendMode will need to be updated, but it shouldn't be too hard to throw something together that compiles. I have other things to do first, but I just thought this would be really neat to see if I could get it working.

It's cheating because of the C++ code base, but DSFML could be the first D game dev library that you can use on Android if it works. We would just have to avoid a few modules in the standard library.

[luke5542]

Even if it is cheating, I still think it would be a worthy accomplishment for both the library and the D language.

[Jebbs]

Not sure if I should open a new issue for this, but iOS support will probably be finished way before Android support. In fact, it is mostly finished as you can see from some recent posts on the forums.

[Jebbs]

I've started working on updating the backend to 2.3, so hopefully we can see what it takes to get an android and iOS DSFML program running soon!

[dmi7ry]

Great! I'm looking forward to try it!

[aubade]

So it's not quite Android yet, and I'm using an unofficial fork of SFML (https://github.com/mickelson/sfml-pi) to do it, so it's not in committable shape, but here's DSFML's hello world and my little engine project running on the ARM/GLES based Raspberry Pi (being piped to an old CRT SDTV, hence the low image quality), but performance is great.

[aubade]

This did bring out a couple issues in DSFML; one's easy to fix (GLES doesn't provide Quad primitives, so Sprite and Text need some reworking), and one not so easy (Raspbian registers as Linux but doesn't use X11 so I need to figure out a good way to version out the XInitThreads())

I'll try and get a couple pull requests out in the next week or so for these, and put up a RasPI-compatible branch on my DSFMLC fork. In the coming weeks I'll see if I can't set up an Android NDK environment and move in that direction. I don't have access to an iOS device, however.

[Jebbs]

Holy shit, that is awesome!

How similar are SFML-Pi and the official Android toolchain? I wonder if it would be better(or possible) to use SFML-Pi just for Raspberry Pi, the official Android toolchain just for Android.

As far as versioning goes, I would assume for now that if Raspberry Pi was going to be officially targeted by DSFML (which I want it to be), then it would be built into the build script and -version=RaspberryPi would be passed to the D compiler. The same things will happen for Android and iOS when those are added.

GLES doesn't provide Quad primitives, so Sprite and Text need some reworking

Weren't these changes were already made in SFML for exactly this reason? Should be easy enough to grab the new code they use and convert it to D.

[aubade]

How similar are SFML-Pi and the official Android toolchain? I wonder if it would be better(or possible) to use SFML-Pi just for Raspberry Pi, the official Android toolchain just for Android.

I'm not sure how similar these are; sfml-pi specifically is just a small (52kb) patch on top of SFML that adds specific support for Raspian's video and input architecture much like the vanilla build has for Android and iOS.

Compiler-wise, I'm under the impression that Android's NDK carries several compiler and library sets to handle the multiple possible CPU architectures that android supports (Mind, I have never actually set this up) whereas RasPI in this case is literally just running a modified Debian linux system capable of doing 3D graphics without X11, and could crosscompile with just Debian's generic armhf toolchain and a custom-built LDC.

So I haven't actually set it up yet, but I believe android will be a little bit more complicated.

Weren't these changes were already made in SFML for exactly this reason? Should be easy enough to grab the new code they use and convert it to D.

Fair enough! The fix for Sprite was thankfully trivial enough that I didn't even look to see how base SFML does it, and while Text will be more than one line of code, it won't be a lot of work.