I finally finished the new WordMix result screen for Android, written in Jetpack Compose. This has been long overdue and gives the game a whole new modern look and feel. What do you think?


I finally finished the new WordMix result screen for Android, written in Jetpack Compose. This has been long overdue and gives the game a whole new modern look and feel. What do you think?


WordMix 2.0 is out! This is a due major update to my little word game for Android and includes a major face lift by bringing the game into the world of Material Design. To keep this simple, I dropped support for Android lower than 5, with a version supporting Android 4 still being available via Google Play Store. However to get the newest features you need to upgrade your device to Android 5.
Of course this update includes a number of bug fixes and general improvements, but here the major changes:
Isn’t it pretty? The first thing you may notice is the immersive full screen mode, now spanning the status bar and extending over the navigation buttons, if present.
The action bar has been replaced with on screen controls to give more space to the background pictures and the board. So has the time progress bar given way to a simple timer. A dark button theme is easy on the eye and yet leaves focus on the game itself.
The game contains more background images and some of the old images have been replaced with new ones. All backgrounds are included in the free version, there are no more “premium” backgrounds.
This is just the first step, other screens will follow.
Tapping a word will now reveal a contextual bottom sheet with information about the word. This for example shows the number of points for this word, whether the word is valid and has been played before and it may include actions of other apps.
If for exampe Google Translate or Wikipedia apps are installed, they appear as actions that allow the player to quickly look up or translate a played word.
Under the hood this will simply show any app that implements ACTION_PROCESS_TEXT, the same way this is integrated into Chrome.

The word suggestion feature now shows a list of possible words, their points, and allows the user to choose, with of course the option to first translate or look up the word to play. It allows to immediately set the word from the bottom sheet, which is very convenient.

Two new languages and dictionaries are now supported. Any feedback or suggestions for new languages is always welcome!
WordMix is (c) Sascha Hlusiak 2012-2019.
Chicken Tournament for Android received some updates recently, with some great improvements. Chicken can now fly!! This took a while to get right and I have replaced the very complex and realistic approach with much simplified mechanics (on the cost of loopings or barrel rolls).
Use either the on-screen D-Pad or fly using the device sensors.
Now I just need to teach the Computer chicken how to fly. 🙂
As always only available in the Google Play Store:
Freebloks 3D is now also available on F-Droid, an alternative app store for Android containing only completely free and open source software. This version is free of any non-free dependencies or libraries.
Sometimes tiny little details can make all the difference. If an egg in Chicken Tournament for Android hits the water, a watery particle system is spawned for the splash. This is just a modification of already existing particle systems but it feels super nice and looks flashy. Of course this is miles away from looking like real water but that’s not the goal and the pure reaction and feedback of an egg hitting the water does make all the difference.
Long time no post about the Android version of Chicken Tournament. But it’s doing very well, despite lack of time. 🙂 And the best, you can already check it out in Google Play!
A couple of updates later, the completely rewritten game now features improved particle systems like blood, feathers and fire and comes with limited keyboard support. Especially the new feathers took careful design and tuning to get the physics right but I’m very pleased with the optic result and performance. Of course, cranking up the amount of effects, I’m sure it can bring every device down.
UI sound effects improve overall feeling and experience. Having in mind that this game was completely written from scratch using a self written engine and pretty much not reusing any code, I am extremely proud of the result.
The new career mode features an experience and skill system for your hero, level by level. You can collect different hats that will further improve your skills and stats.

The demo version can be downloaded free of charge, it’s ad-free but has a limited feature set. Those features are without limitations tough, like pay-2-win or In-App-Purchases. There is a fully featured full version, meant to support me and my work.
But some important features are still missing though, like:
I’m just one man, please be patient. If you find bugs of have suggestions, please email me at ct@saschahlusiak.de.
I published a short demo video of the upcoming Android version of Chicken Tournament. The video has no sound and shows the game as of today.
Enjoy:
After more than 10 years I decided to port Chicken Tournament to current Android smartphones. Due to the differences between the platforms, this will result in a new game and a new engine, but because of lack of time and resources, I will reuse the models and most of the textures. OpenGLES 2.0 though allows me to massively improve the quality of the graphics.
The PC version and the android version will not be compatible.
Please follow the official Chicken Tournament facebook page to receive more information and updates. A very early development version allows driving the harvester over a plain using the accelerometer to steer. The chicken are nicely animated using vertex shader.

For the port of Freebloks 3D to Android I rewrote all code from C to Java. While that was working fine and resulted in greatly simplified networking code, the speed of the AI was not so great. It took up to 10 seconds on a fairly powerful SGS 2 for the computer to find a good move.
I was trying to move the CPU intense routines of the AI to C again, using jni as a bridge between Java and C. The simple network routines should stay in Java.
But the transfer of relevant game data to C and back to Java turned out to be very ugly, yet the solution was incredibly simple:
The Freebloks code was always split in two parts, the GUI/client part and the AI/server part, with the client and server always communicating using network sockets. Yes, even the single player version starts a network server and connects to localhost. The original source code always contained a package for running a dedicated server.
It was incredibly easy to copy the dedicated server code into my project, compile the C code with the NDK and connect it to Java with only a single jni call. It was running out of the box, with almost no change of the original C code at all! Since the server is running in a thread started from the native C code, there is no additional jni call neccessary and no data transfers except for the sockets.
The average duration for the AI to calculate a complete game dropped from 87 sec to 28 sec on my SGS 2. The version 0.0.2 in the Google Play Store supports ARMv5, ARMv7 and x86. Grab it now! You may also download a free apk file here.
And please don’t forget to give feedback.
After publishing WordMix with the OpenGL accelerated 2D game view (using GLSurfaceView), I received weird crash reports from some devices, mostly out of memory from within the GL context:
android.opengl.GLException: out of memory at android.opengl.GLErrorWrapper.checkError(GLErrorWrapper.java:62) at android.opengl.GLErrorWrapper.glGenTextures(GLErrorWrapper.java:350) at [...]
From the very limited information the Google Play Developer Console gives me about crash reports, I assumed it only affects devices running Android version 3. Modifying the code only caused the out of memory exception to be thrown at random other places, even at GL10.glClear(…)!
I also found out, the crash only happens when the user finishes a subactivity that would leave to the activity containing the GLSurfaceView. Users were complaining about the crash happening before starting a second game, which puzzled me, because all my rendering code seemed to be working fine on all devices running Android 4. Everything worked fine without the GLSurfaceView as well.
Looking that the source code for GLSurfaceView, nothing interesting was changed between Android 3.2 to Android 4, so the GLSurfaceView was hardly to blame, but more the hardware, drivers or specific OpenGL implementation.
The actual problem was very hard to track down and took me several hours and was particularly hard because I did not have an Android 3 tablet for debugging:
Up to Android 2.3, views were drawn in software and later composited using the hardware. Android 3 introduced an alternative hardware accelerated drawing engine for everything that uses Canvas classes. This alternative render path is disabled by default in Android 3 and supposedly enabled by default in Android 4 (previous blog post).
When I found out, that the Samsung Galaxy S2 does not enable hardware acceleration by default, I did set
<application android:hardwareAccelerated="true" ...>
in the AndroidManifest.xml for all activities that should support hardware acceleration. Using hardware acceleration for the activity with the anyway hardware accelerated GLSurfaceView did not make much of a difference. But accelerating the results or preferences activity, for example, gave a nice performance boost on my SGS2.
It turns out that the crash happens in Android, when an activity, that contains a GLSurfaceView, is paused for a fullscreen activity, that is hardware accelerated. When that hardware accelerated activity is finished, the underlying GLSurfaceView is screwed up, throwing out of memory exceptions, even though the GL context is completely reinitialized correctly.
Yes, I should have tested more the effects of hardwareAccelerated=”true”.
Leaving that attribute entirely unset is recommended for Android 3, especially when you use a GLSurfaceView, and should not hurt Android 4 devices as well. Setting a reasonable default value is then up to the manufacturers.
Welcome to fragmentation. Just let hardwareAccelerated be unset.
I tried to replace the legacy 2D rendering code of WordMix, which uses the native Android canvas methods, with an OpenGL renderer to allow for fancy effects and animations.

Because the tiles are simple rectangles with round corners, I created a texture with gimp and rendered a quad in OpenGL. The texture had no mipmaps and was filtered linear for both, minimizing and magnifying. When rotating that quad, I got the typical “staircase” lines, because I did not use anti-aliasing / multisampling. The result looks rather horrible:

You can see two effects, one if it being the clear staircase borders, where the texture is not linear filtered, and you see the round corners of the texture with a grayish border, I’ll explain in the next paragraphs.
So how to achieve multisampling in OpenGL ES 1.1? The answer I found is quite simple and easy on the hardware: use a texture with a transparent border and linear texture interpolation will do the rest. So I modified the texture to include a transparent border and rendered the quads slightly bigger to fill the same amount of pixels.

The result looked better but I was not satisfied with the borders. I saw the interpolations but there is still a very visible “staircase”. Plus it seems, that the borders are blended with a black color, which can be seen on the overlapping tiles:

This is in fact due to my texture, which had the transparent pixels assigned the color black. The OpenGL interpolation would just average two neighbour pixels, which would calculate like
(argb(1, 1, 1, 1) + argb(0, 0, 0, 0)) / 2 = argb(0.5, 0.5, 0.5, 0.5)
which is a semi transparent gray color tone.
So how to create a texture, where the transparent pixels have the color white? Gimp seemed to screw up the color of transparent pixels even though when exporting my work as png file, it offers to keep the color of transparent pixels.
The trick: combine all visible planes, create an alpha channel and change the color layer. If you have uncombined planes, the result is unpredictable and the colors are screwed up.
So now I had a texture with a white but fully transparent border (value 0x00FFFFFF) and I’d expect the calculation to be
(argb(1, 1, 1, 1) + argb(0, 1, 1, 1)) / 2 = argb(0.5, 1, 1, 1)
But I still got the same result:

So why is my border still black, while the texture has white transparent regions? I checked the loaded Bitmap with this code after loading the png resource:
Bitmap bmp = BitmapFactory.decodeResource(getResources(), R.drawable.stone);
Log.d("texture", bmp.getPixel(0, 0)); /* result: 0 */
Why is the result 0?? I’d expect a 0x00FFFFFF, but either Androids Bitmap loader premultiplies the alpha or recompresses the image file on compile, although I did place the image in the res/drawable-nodpi folder.
But apparently Bitmap and Canvas throw away all color information, when drawing with an alpha value of 0. This results in a fully transparent, but black canvas:
canvas.drawColor(Color.argb(0, 255, 255, 255), Mode.SRC);
Log.d("texture", bmp.getPixel(0, 0)); /* result: 0 */
while the following results in a white canvas, which is almost transparent (1/256):
canvas.drawColor(Color.argb(1, 255, 255, 255), Mode.SRC);
Log.d("texture", bmp.getPixel(0, 0)); /* result: 0x01FFFFFF */
Good to know, so now I create my texture with a border that is almost transparent, but not completely (alpha value 1/256) and the color white, which should be hardly visible, calculating like:
(argb(1, 1, 1, 1) + argb(0.01, 1, 1, 1)) / 2 = argb(0.505, 1, 1, 1)
I checked with above Log code and indeed got the value 0x01FFFFFF. So at least the Bitmap was loaded correctly now. But I still get a black border and the result looks the same. Why?
I found a post and bug report that apparently the GLUtils.glTexImage2D() screws with the alpha and colors too, creating texture values of 0x01010101, which gets blended with the nearby white pixels on linear filtering. What the…?
The post suggests a workaround to not use GLUtils to load the Bitmap into an OpenGL texture but use the original GL10.glTexImage2D(). While the code in that post is not very efficient, it does result in nice and smooth blended borders. Of course the use of mipmaps helps too to make the texture smooth when minified:

Several culprits were found to make antialiasing work with an Android App using OpenGL ES 1.1:
Using mipmaps and adding a nice shadow texture results in a screen, that looks very similar to the original, but which is much faster:


WordMix Pro arrived in the Google Play Store. While WordMix will stay free of charge, selling a pro-version will support the developing of the game and helpkeeping the free version adfree. So far the Pro version does not have much to offer but some more background images for the game. I do not intend to make the gameplay differ between the free and the payed version.
A 3D OpenGL interface for the game is under development and will be available in the pro-version soon.
Check out the first screenshot:
