Any thought given to an Android port?

computermouth · 2015-01-07 19:22:53

The mechanics would seem to suit an app well. Sure, you probably wouldn't get away with it on the store, but sideloading an .apk isn't too difficult for those interested.

I'd actually been trying to port it over myself, but hell if I can figure out the maze of makefiles (I've only just started using them myself).

I _have_ gotten a few of my SDL2 projects running on Android, and I believe 1.2 can as well. And it looks like everything else compiles statically to the executable? Sounds pretty NDK friendly to me!

jasonrohrer · 2015-01-07 19:29:11

Would be great if you wanted to tackle this!

I don't have any Android devices here, nor am I aware of policies that would or would not allow a game like this in the official store.

There's been some talk of an HTML5 version of the game that would then run on every device everywhere through a browser. Of course, that would require a complete rewrite in Javascript. Still, the client is pretty simple compared to the server.

computermouth · 2015-01-07 19:56:04

Well, ideally, the game wouldn't have to be reprogrammed. The NDK allows native code (c/cpp) to run inside a java wrapper. I think it's really just a matter of translating the makefile from the linux build to an android makefile.

The new Android Studio IDE(cuz terminal compilation/building for android is a nightmare) allows for emulator testing, and I have a few spare devices as well. If it wouldn't be too much of a hassle, getting a single (Linux-geared) makefile that would run from the location where runToBuild is in the source would definitely be useful.

As far as Google is concerned, the app store is mostly host-first-ask-questions-later. But I know that they refuse to host the Illinois Lotto app. Otherwise there are also GPL app-stores that would probably take it, so there are still platforms for distribution.

jasonrohrer · 2015-01-07 20:34:12

So... runToBuild generates the Linux makefile into:

gameSource/Makefile

That file pulls its .cpp and .tga file list from the platform-independent makeFileList

I wouldn't count on SDL 1.2 supporting Android---it's pretty old.

The game itself is SDL-independent except for the SDL implementation of the minorGems/game/game.h platform interface.

What you might want to do is look at game.h and simply rewrite those for Android however you want, using whatever library you want. You'd need to implement everything from here down:

int loadSoundSprite( const char *inAIFFFileName );

The stuff above that is implemented BY the game, not the platform.

Then, take a look at minorGems/game/gameGraphics.h Those are currently implemented by minorGems/game/platforms/openGL. I'm pretty sure that code will just work on Android, because I recently wrote GL-ES versions of all the functions with a macro that detects ES. I was getting the game working on Raspbian.

Anyway, beyond the game.h platform implementation, the game code doesn't rely on SDL or OpenGL. There are only a very few minorGems things that it depends on (like SettingsManager, SimpleVector, stringUtils, and logging), but they're all platform-independent and library independent. Thus, it should be pretty straight forward to gather the required .cpp and .h files into your project. Essentially, just keep building, looking for missing dependencies, adding those, repeat.

cullman · 2015-01-07 20:36:06

I'm working on a reboot of The Castle Doctrine that works on mobile, both Android and iOS. We were able to port the code over fairly easily by moving the code base from SDL 1.2 to SDL 2.0 and using the Android NDK. If you want I can put you in touch with the developer that did this for TCD to give you some tips.

zed · 2015-01-07 22:52:14

jasonrohrer:
> I don't have any Android devices here, nor am I aware of policies that would
> or would not allow a game like this in the official store.

Actually, I happened to notice this the other week:

http://play.google.com/about/developer- … olicy.html
> Gambling: We don't allow content or services that facilitate online
> gambling, including but not limited to, online casinos, sports betting and
> lotteries, or games of skill that offer prizes of cash or other value.

That last clause sounds like a problem, right?

jasonrohrer · 2015-01-08 03:36:41

Yep. Even if it's not illegal, we forbid it. Paypal is the same way.

Pox · 2015-01-08 04:52:22

HTML+Javascript would suit this game perfectly and run on pretty much anything with an updated compliant browser, which is a pretty huge audience these days. Obviously there's a considerable initial effort involved in such a port (and an on-going one if you want to maintain the native version). Personally, it's something I'd love to see.

You could perhaps consider a C++-to-javascript compiler like emscripten or cheerp - this could potentially reduce the required effort to writing browser-based implementations of your input/graphics/network interfaces. I haven't tried anything like this myself and I'm not sure how many changes might be required to the game code itself - given how simple the client-side logic is, this might end up being just as hard as a full rewrite. (Edit: apparently emscripten includes an SDL1.2 implementation - not sure how complete this is.)

Last edited by Pox (2015-01-08 04:57:26)

computermouth · 2015-01-08 09:19:36

Wow, super helpful jason! I'll keep you guys posted if I get anywhere.

Thanks to you too, cullman. If I get stumped I may have to take you up on that.

As far as emscripten goes, I'd looked into it before. I saw that they had made a loose translation of 1.2, but web languages have never really been my jam(aside from a few php/sql interfaces I've done in the past). But it does now look like there's a few github projects for SDL2 as well. And the if the main library and some minor code changes are all this needs, I'd be happy to try and get a web version running and hosted too!

Pox · 2015-01-08 09:48:11

Well it seems silly to rewrite the game in SDL2 just to then use an SDL2 compatibility layer. I guess if you can't get 1.2 running on android natively then it's a reasonable step.

I'd like to try writing a javascript client, but there's no way I'll have time to polish it (or likely to even get it working functionally) any time soon. I might have a fiddle with emscripten myself to see how many tweaks are necessary.

Edit: Porting might be more difficult than I thought - SDL is used to set up the window, but the graphics is all drawn with legacy OpenGL code.

After modifying the Makefile for emscripten and commenting out SDL_GL_SWAP_CONTROL, it compiles and successfully initializes the 666x666 webGL window along with the sound system. However, it doesn't like the legacy OpenGL methods at all - in emscripten's LEGACY_GL_EMULATION mode it can get as far as loading the textures only when the webGL inspector is enabled (yay heisenbugs), but fails upon trying to blit them. I'm guessing much of the graphics code will need to be rewritten if this is going to run on Android, whether it's via WebGL or OpenGL ES. @cullman: did the SDL1.2 -> 2.0 port for TCD also involve updating the OpenGL code?

Last edited by Pox (2015-01-08 14:03:48)

computermouth · 2015-01-08 16:07:19

Well, jason's basically written the code and makefiles to choose platform specific libraries at compile time. OpenGL does the draws and dumps them into SDL 1.2. With the included macro to use GL-ES(which is supported by android), I'd just have to convert the SDL 1.2 code to SDL2, then take care of little quirky things.

cullman · 2015-01-08 16:30:13

computermouth wrote:

Well, jason's basically written the code and makefiles to choose platform specific libraries at compile time. OpenGL does the draws and dumps them into SDL 1.2. With the included macro to use GL-ES(which is supported by android), I'd just have to convert the SDL 1.2 code to SDL2, then take care of little quirky things.

I didn't do the work myself, but yeah I am pretty sure we had to tweak few things to go from OpenGL to OpenGL-ES. It really wasn't that big of a deal, a few weeks of work, and I am pretty sure that Jason basically uses the same framework for CM that he did for TCD. I am in agreement with people that a HTML5 version if the way to go, especially since you can't put a gambling game in the apple or google store.

computermouth · 2015-01-08 17:02:53

Is an android port the most practical thing to put out there? Nah, of course not. But can I do an HTML5 remake? Also nah.

Will it be fun trying to make the android port nonetheless, and would it at least slightly contribute to the community? Double yes.

Pox · 2015-01-08 17:23:12

computermouth wrote:

Well, jason's basically written the code and makefiles to choose platform specific libraries at compile time. OpenGL does the draws and dumps them into SDL 1.2. With the included macro to use GL-ES(which is supported by android), I'd just have to convert the SDL 1.2 code to SDL2, then take care of little quirky things.

Ah, I assumed the GL ES code was incomplete since even with the GLES flag enabled it was making some calls that the linker was flagging as legacy GL; but it looks like those functions were valid GLES1.1, but were removed in version 2.0 of GLES. Thus you can probably get it compiling essentially unmodified using the android NDK, while the emscripten version would require updating the code that uses glMatrixMode/glLoadIdentity, glVertexPointer and glTexEnvf, since it seems that enscripten does not support GLES1.1 either.

.. · 2015-01-08 20:14:16

I've previously ported an SDL 1.2 game engine to Android by using the unofficial port of SDL 1.2. So I thought I'd see whether I could get Cordial Minuet running in one evening (conclusion: yes, by going to bed really late).

I encountered two main problems.

Firstly I realised, as Pox did, that Jason has only a partial GLES port; as far as I can tell he only has a trivial test program running on Raspbian, while various GUI functions like GUIPanelGL::fireRedraw still use OpenGL functions. I didn't encounter any problem with glMatrixMode, and I'm not familiar with the differences between OpenGL variants. No matter, CM only uses OpenGL 1.something, so I used jwz's handy wrapper (jwzgles) around OpenGL ES 1.x which provides an OpenGL 1.x interface. It was quite tricky to get this working with the right set of #defines, and it turns out I had to use Jason's GLES code anyway: he'd ported just enough for it to work.

Secondly, the build system is REALLY complicated. I still don't understand it, and I wish I hadn't tried. I spent nearly half my time just wrestling with it! (Turns out that I'd shot myself in the foot by trying to do things properly when adding a platform-specific C file to the build by adding it to Makefile.minorGems which caused it to think it was C++. There's no support for compiling C files in the build system, and I still don't understand how you're supposed to add platform-specific object files.)

Plus a bunch of other time consuming stuff.

This SDL port supports the native on-screen keyboard, but warns that invoking causes all OpenGL state and textures, etc, to need reloading. Indeed, I saw backgrounding the app and coming back does the same thing, replacing all text with white boxes. So I avoided it, and instead pushed my account key to the device. To my amusement, someone joined my 1c game immediately:

This is what it looks like while it's painting a stroke. Weird; it's actually the wrong colour. It's also really slow, but the android emulator is always slow on my system.

Afterwards, I ran it on my phone. My phone is a REALLY cheap and painfully slow Android phone with a 320x240 screen and no GPU. It did run, after taking forever to unzip the .tga files, but I didn't bother to try to get it working at that resolution.

I found that it doesn't play nice if the screen is less than 666x666. I expected it to scale down gracefully, but it didn't, even after I tried editing initDrawString and initFrameDrawer in game.cpp . Instead I just changed the resolution to 480x480 to match my emulator. There are lots of other issues I'll mention some other time. Much of my code can be contributed back to minorGems. I'll upload all my code and an .apk tomorrow, it's time I went to bed.

I know from experience that getting a ported game running on Android is the easiest part, after that you have to fix the game itself to work well on a phone. And just because I got this running doesn't mean that a HTML5 or SDL2 port isn't a better idea. The SDL 1.2 port I'm using is very messy, and designed to allow porting games from PCs with the minimum of effort, while also providing little ability to do things the proper way: it makes annoying decisions on your behalf.

jasonrohrer · 2015-01-08 22:23:59

minorGems contains a whole bunch of code from over the years. Not all of it is used in CM or the "game.h" game platform wrapper. In fact, there is a bunch of OpenGL stuff in minorGems/graphics that isn't used by this game.

Essentially, as far as OpenGL code goes, the game uses only stuff in minorGems/game, minorGems/graphics/openGL/ScreenGL_SDL.cpp and minorGems/graphics/openGL/SingleTextureGL.cpp

The other OpenGL code is not used.

I'm pretty sure that the code used by the game IS GL-ES compliant with the ES macro defined. I'm not sure which version of ES, except that it was the one on Raspbian.

That said, though the game RAN on Raspian (very slowly), I recall that there were some weird blending issues with the brush strokes as they were painting in. Pretty much like that screen shot there. Maybe the blending mode being used isn't ES compatible.

computermouth · 2015-01-08 23:54:19

.. wrote:

So I thought I'd see whether I could get Cordial Minuet running in one evening (conclusion: yes, by going to bed really late).
...
I'll upload all my code and an .apk tomorrow, it's time I went to bed.

Wow, nice work! I'd love a look at the code

.. · 2015-01-10 14:19:42

My error, you're quite right. It turns out that all of that OpenGL code was getting pulled in by demoCodePanel.h, which you don't include ifdef RASPBIAN. I didn't read the comment and mistook that for honestly Raspbian-specific stuff. Which games actually use that OpenGL GUI code?

I fixed the screen resolution issue, which was partially an issue with the SDL port. The game mostly looks fine scaled down to 320x200 aside from ugly font edges and aliasing on the score graph, and I played a couple games on my phone.

I've decided to make a few changes so that the game is actually reasonably playable; that's what's taken me so long (most of these fixes could be shared with other port efforts). The significant remaining problems are:
-the up/down buttons for selecting bet sizes, etc, are way too close together
-the distorted brush strokes
-loading times on my emulator and phone are reeealllly long. On my phone it takes something like 5 seconds just to show the 'Loading' screen (it has to load the font first) and 12 seconds to load all the other graphics. Even a typical cheap android phone would probably be several times faster than mine, so maybe this isn't a serious problem. And aside from load times and animations the game is still responsive, eg the score graph still updates in real time.
-textures aren't reloaded when resuming the game. I guess it would be best to handle this behind the scenes, eg by making SpriteGL store a copy of the input Image. That would add only 7MB to memory usage.
-twice, I received a "Game timed out" message at the end of a round, after the coins had finished moving. I'm wondering whether this is due to the long time it takes the pot coins to crawl across the screen. Jason, is there a short timeout there that I might be hitting?

Last edited by .. (2015-01-10 14:37:47)

jasonrohrer · 2015-01-10 18:47:01

Yeah, end of round, the timeout is shorter. I think maybe 15 seconds. If pot coins are slow to fly, you won't send the start_next_round request in time. Sounds like it's not running at 60fps. You might want to adjust the halfFrameRate.ini setting. Set it to run to clamp it at 30 fps.

Load time is strange... that font image isn't that big...

jasonrohrer · 2015-01-10 18:50:06

Oh, but there's quite a lot of processing done on the font. Kerning measurements per character pair and all that. The font engine has become pretty sophisticated over the years. But all of that work is done at load time, and those pairwise character separations are simply used at drawtime.

gmu3 · 2015-01-11 16:57:08

My guess is you're reading all the game's static stuff (fonts/images/settings/etc) directly from the apk, and those files are all compressed. It takes a long time to load because it takes a long time to calculate the offsets, seek, and extract each file individually.

cullman · 2015-01-11 18:21:50

gmu3 wrote:

My guess is you're reading all the game's static stuff (fonts/images/settings/etc) directly from the apk, and those files are all compressed. It takes a long time to load because it takes a long time to calculate the offsets, seek, and extract each file individually.

gmu3 is the guy who ported TCD (which uses the same framework as CM) to Android and iOS, so his theories are definitely worth considering.

.. · 2015-01-12 14:26:00

Hi. That's not it, because the assets are all unzipped on first run (this is handled by the SDL port, with progress shown over a splash screen) -- which takes over 40 seconds on my phone, for 8MB uncompressed! I assume this is CPU bound. Here are some timings for the part of the load time inside the native code:

Initial load time (to show 'Loading' screen): 6.3 sec
*To load font (variable width): 6.1 sec
Time spent 'Loading' (in initFrameDrawer): 11.7 sec
*Loading fixed width fonts: 3.6 sec
*Constructing PlayGamePage (includes loading all other graphics): 7.4 sec
Total: ~17 sec

Time to read TGA files from sdcard: 0.8 (warm start)
Time spent creating Images from TGA: 4.9 sec

I see that the colour channels in Image are stored as doubles. Just converting chars to doubles is taking 5 seconds. Unlike x86, doubles are often far slower than singles on ARM chips even if they are supported in hardware. As I'm targetting the older (roughly for devices 4+ years old?) 'androideabi' ABI (which is ARMv5TE) all floating point code is done by calls to a library, which on my device (an ARM6) uses hardware FP support.

I forgot about halfFrameRate. That works nicely. I notice that the framerate improves quite a lot by the end of the round, when there are fewer pips in the score graph. It would be ideal to adjust the target framerate automatically. Does changing halfFrameRate or the existing framerate throttling on the pause screen cause recorded games to break?

I also tried compiling TCD for Android (just a matter of copy-pasting and adjusting the build script), and there are even more graphical artifacts there. Looks like drawing with per-vertex alpha is quite broken.

Last edited by .. (2015-01-12 14:44:13)

jasonrohrer · 2015-01-12 15:28:44

Nothing about frame timing will break recording as long as you play the recording back on the same piece of code. I.e., if your code adjusts the frame timing at some point mid-game, then so will the playback code, using the same logic.

CORDIAL MINUET ENSEMBLE

#1 2015-01-07 19:22:53

Any thought given to an Android port?

#2 2015-01-07 19:29:11

Re: Any thought given to an Android port?

#3 2015-01-07 19:56:04

Re: Any thought given to an Android port?

#4 2015-01-07 20:34:12

Re: Any thought given to an Android port?

#5 2015-01-07 20:36:06

Re: Any thought given to an Android port?

#6 2015-01-07 22:52:14

Re: Any thought given to an Android port?

#7 2015-01-08 03:36:41

Re: Any thought given to an Android port?

#8 2015-01-08 04:52:22

Re: Any thought given to an Android port?

#9 2015-01-08 09:19:36

Re: Any thought given to an Android port?

#10 2015-01-08 09:48:11

Re: Any thought given to an Android port?

#11 2015-01-08 16:07:19

Re: Any thought given to an Android port?

#12 2015-01-08 16:30:13

Re: Any thought given to an Android port?

#13 2015-01-08 17:02:53

Re: Any thought given to an Android port?

#14 2015-01-08 17:23:12

Re: Any thought given to an Android port?

#15 2015-01-08 20:14:16

Re: Any thought given to an Android port?

#16 2015-01-08 22:23:59

Re: Any thought given to an Android port?

#17 2015-01-08 23:54:19

Re: Any thought given to an Android port?

#18 2015-01-10 14:19:42

Re: Any thought given to an Android port?

#19 2015-01-10 18:47:01

Re: Any thought given to an Android port?

#20 2015-01-10 18:50:06

Re: Any thought given to an Android port?

#21 2015-01-11 16:57:08

Re: Any thought given to an Android port?

#22 2015-01-11 18:21:50

Re: Any thought given to an Android port?

#23 2015-01-12 14:26:00

Re: Any thought given to an Android port?

#24 2015-01-12 15:28:44

Re: Any thought given to an Android port?

Board footer