Last time, I talked about Linux-specific issues to fix before my game’s release.
This time, I’ll address the issues I’m seeing on Android and Windows platforms.
Android: manual code signing
Quite frankly, between running the game on my phone and on my tablet, I haven’t seen any issues since I first tried to get my game built and installed on this platform. The main issue I had was figuring out which directory to save to, and I solved that issue.
Oh, and code signing was another solved issue. I can build and deploy debug builds by turning on developer mode on my devices, but the release build needed to be signed. As I am not using amazing IDEs that have one-touch buttons that do all sorts of fanciness, I had to figure it out myself from the documentation.
Luckily, the Android developer documentation for signing manually was fairly straightforward in this regard. In my CMakeLists.txt, I added a custom target called sign, which requires the location of my keystore and its alias. I created a few environment variables that I pass into my build, and the following is basically what’s needed as per the documentation:
ADD_CUSTOM_TARGET(sign
"echo" "================ SIGNING WITH KEY ================="
COMMAND "jarsigner" "-verbose" "-sigalg" "SHA1withRSA" "-digestalg" "SHA1" "-keystore" "${GB_KEYSTORE}" "bin/${ANDROID_APP_NAME}-release-unsigned.apk" "${GB_KEYSTORE_ALIAS}"
COMMAND "echo" "================ VERIFYING WITH JARSIGNER ================="
COMMAND "jarsigner" "-verify" "-verbose" "-certs" "bin/${ANDROID_APP_NAME}-release-unsigned.apk"
COMMAND "echo" "================ USING ZIPALIGN ================="
COMMAND "zipalign" "-v" "4" "bin/${ANDROID_APP_NAME}-release-unsigned.apk" "${ANDROID_APP_NAME}-release.apk"
WORKING_DIRECTORY "${PROJECT_BINARY_DIR}/android-project/")
Otherwise, I found porting to Android be very straightforward thanks to using the NDK and libSDL2-based libraries. If anything, I worry about scaling to different screen resolutions and device-specific compatibility problems due to the lack of devices I have to test on.
I’ve already signed up for the Google Play developer program, so the main piece to worry about is actually submitting my app to their store. How hard could it be?
Windows: persistence and font rendering
While GNU/Linux and Android are more or less the same, Windows is the odd duck.
I can easily cross-compile to create a Win32 build, and with my limited testing I found that the 32-bit version runs smoothly on a 64-bit system, so that’s good.
Since I don’t need to use a lot of memory, there’s no real advantage I can see to building a 64-bit version of my Windows port. The main downside would be an inability to support people on 32-bit systems, requiring that I provide both 32-bit and 64-bit binaries as I might need to do for the Linux-based package.
However, I did have to fix a few issues this past week that I didn’t know were there until someone tested it for me. Thanks, Rick!
I knew of an issue with using MinGW to cross-compile to Windows in which using std::cout would result in a crash. I never looked too hard into it because I only used cout for my own logging in order to find out what is happening, so I just commented them out when I released for Windows, usually for a Ludum Dare game.
Well, it turns out that there was still a crash, and I found that if I commented out the code that saved the current game state to a file, it would run just fine.
Was the known issue applicable to file stream operations, too? Luckily, gdb can be downloaded and run as a standalone applications on Windows, so I ran my game on Windows through gdb and read through the stack trace. It pointed to yaml-cpp.
I use yaml-cpp to save and load my game data, and it works very well. But why does it crash on Windows?
I found this thread on GitHub that mentioned a similar stack trace: Crashy shared object
It was closed without really being addressed, as the original poster gave up after seeing the issue disappear when using a later version of gcc.
Luckily, someone else found a different solution involving a change to a few lines in yaml-cpp’s code, although they said more tests are needed. I tried it, and it seemed to solve the problem for me, although I am a bit wary about not knowing what the change does or how it solves it. B-(
The other issue I found on Windows was that resizing the window results in the text looking completely wrong:
All the other graphics look fine. Under the hood I am using SDL2_ttf, but using it directly isn’t showing this problem. I am using NFont, which does some caching, and I wonder if it is somehow being corrupted. I need to do some more tests, but this issue does not occur on my Ubuntu system, and Android doesn’t allow you to resize the screen dynamically at runtime, so it’s a Windows-specific issue so far.
I’ll continue looking into it, but updating to the latest version of NFont didn’t help. I tried updating my SDL2-related libaries next since some Windows 10-specific updates were made between the initial Windows runtime binaries and the latest release.
NFont’s creator Jonathan Dearborn has been running test apps I’ve sent him and sending back updates to try, and so far it seems we’re nearing a solution. Thanks for being so responsive, Jonny D!
The main major issue is signing my game’s binary. Windows 10’s SmartScreen puts up a warning about how they have protected your PC because they prevented the app from starting. It shows the binary as coming from Unknown Publisher.
That’s scary. I need to look into how to make it less scary. Does it require buying a code signing certificate, or is it similar to how Android’s code signing works? I don’t know yet, but I’m looking into it.
The other issue with Windows is that saving the game is sloooooow. In my game, I persist changes each time the player makes a major decision. Basically, if you click a button that switches to a different screen or causes something to happen in-game, I save so that if you shut the game down and reload it, it takes you back to where you were.
My Linux-based and Android-based builds are zippy. I can click, click, click, and any changes are instant. As a result, the game has been feeling very responsive despite the lack of a real-time need for it.
My Linux-based system does not have an SSD drive, and my wife’s Surface Pro does, and yet her system takes forever to save a file.
So on Windows, it feels less like click, click, click and more like click, wait, see screen update, then click. Because of the delay, sound effects are playing too early as well. It’s a lesser experience on Windows.
I haven’t ever needed to do multithreaded programming before as a single thread was usually plenty for the work I’ve ever done, but now I am wondering if I should spin of a thread specifically for writing to a file due to this issue that seems to be Windows-specific.
How Much Longer?
Ok, so there’s some technical issues, and some are easily surmountable, and some require some more investigation, and it’s possible there are some I haven’t run into yet.
Since Android seems the simplest to release, perhaps it goes into the Google Play store first, and I worry about the Linux and Windows versions later.
But I do not want this three month project to get to the ninth month before its first release.
The good news is that the next project will have a much clearer release plan, and many of these issues will be already solved. B-)