Game Developer’s Perspective: Windows 8 and Windows Phone 8

A few days ago Microsoft confirmed some things that we’ve been hoping to be true for some time. First of all: Windows Phone 8 will indeed have support for C/C++! This is great news for a small studio like us who has a backlog of several awesome games coded mainly with C/C++. Windows Phone 7.x was lacking C/C++ support and porting our games there would have required a total code rewrite starting from the game engine itself. This isn’t a small task and would’ve probably taken months. Now we only need to do create some new graphic and audio implementations in addition to basic input handling.

It seems that the Windows Phone 8 won’t have OpenGL ES or OpenAL, but that’s ok since they should have support for DirectX 11. Windows 8 also supports DirectX 11, so in theory we might only have to create a Direct3D 11 renderer and implement audio support using XAudio2. We’re hoping that with these two components we can draw graphics and play sound both on Windows Phone 8 and Windows 8 devices. It’s exciting to see whether this will hold true, but we certainly hope it will and it seems quite likely.

So, Microsoft has a chance to make a developer’s life really really easy. We’re currently dreaming of a situation where we can run our games on Windows 8 and Windows Phone 8 with only tiny code differences. In real world this all means that the users of these operating systems will have quick access to all the most popular apps and a lot of variety to choose from. So, you can definitely expect 10tons games on your Windows Phone 8 device in addition to your Windows 8 tablets, laptops, and desktop computers!


Azkend 2 on Android ICS x86

It seems that there’s at least one x86 Android Phone available. That inspired us to try out our games on Android x86. This is something that won’t probably be relevant to mass audiences for a while if ever, but it was still interesting to see Android and Azkend 2 running on a x86 netbook. Most Java-based games work straight away and native apps like Azkend 2 need only to be recompiled.

However, with Medfield the situation is even better: It seems that Intel has integrated some kind of binary translation magic into the SOC which means that even native apps compiled to ARM will work without modifications. Many sites also report that the x86 battery hog myth was busted with Medfield and that devices can compete with the likes of SGS2 in terms of batter life.

So, from a game developer’s perspective supporting Android x86 shouldn’t be a problem if it becomes popular.

We used a live bootable usb stick created from a iso here on a HP Mini 100e. See Azkend 2 Lite running on an Intel Atom equipped HP Mini 100e here.

Android and the strange world of APK sizes

Google just upped the maximum single APK size to 50 MB. After this the developer needs to do some add-on package juggling up to 4 GB. This can be done with Google’s own tools or developers can roll their own. For us this small change meant that we could fit Azkend 2 in two single packages on Android: APK for phones and another for tablets. However, the reality of things proved to be a bit different.

We just released Azkend 2 Lite on Google Play and one of our own test devices is a HTC Wildfire S. It’s one of the cheaper Android 2.3 devices. After the release, we were baffled why we couldn’t find the game with that device. We saw no apparent reason why Azkend 2 Lite would filter out on a Wildfire S.

Turns out that the cache partition size where apps from Google Play are first downloaded varies from device to device. On the Wildfire S this size is 35 MB. On a Nexus S the size is 500MB. On a HTC Sensation the size was around 80MB. If the cache partition size is smaller than the app APK, the app will not be visible on the Google Play for the device. This is an interesting and unadvertised limitation that probably affects cheaper models more than expensive ones.

So, it seems that even the 50MB single download can’t be achieved on all devices. I’m not sure if there’s going to be a fix or if this is just a feature. From the little details we’ve learned, it would seem likely that this is something that could be fixed in Google Play. If there is a storage device with more capacity attached, why not use that for saving the apk? World of Goo by 2D Boy is also affected by this strange feature.

If you suspect that you aren’t seeing some apps with your device, you can check the cache size with a free tool called Cache Fixer. You can even move the cache on a rooted device. However, this moving fix isn’t an option for the majority of users.

The story of Mali-400 MP and GL_RGB

We’ve had our share of compatibility problems with Android but most of them were quite straightforward. That said, it has still taken a lot of time if you sum up all the little bits of work we’ve done to improve compatibility. Maybe this note will help some other developer solve this particular issue more quickly.

For some time we’ve received reports that some Galaxy Note devices and some Galaxy S II devices may have problems with our games. When we started investigating, we discovered that the trouble was with games that used frame buffer objects (FBOs) or render targets if you prefer that term. We already knew that despite the similar model names, there are several kinds of SGS2 and Galaxy Note devices.

Samsung Galaxy S2 has three possible SOCs (System On a Chip): Snapdragon S3, Samsung Exynos 4210, or a Texas Instruments OMAP4430. Galaxy Note has two possible SOCs: Exynos 4210 or Snapdragon 8255T. After some more research we discovered that the trouble occured on devices with the Mali-400 MP GPU which can be found from inside the Exynos 4210.

After we had narrowed down the suspects, some googling produced this. In the end it was all down to the following sentence.

You are trying to create a framebuffer object with RGB of 8-bits per channel. Mali doesn’t support this because of memory alignment issues that would impact performance.

We had used GL_RGB in our OpenGL ES implementation and it seems that Mali-400 MP doesn’t support this at all.  So, now we know that. All other devices we’ve encountered have supported it, so this was exceptional. The fix was obvious: use GL_RGBA. Further investigation also revealed that GL_RGB is an optional feature so our code was a bit too optimistic to begin with. Anyways, problem solved!

In the end, as a developer I’d really hope that manufacturers would use a different model name if they decide to use a completely different SOC. Even though your average user doesn’t mind what’s munching the bits, this situation makes a developer cry. Granted the manufacturers have used different technical model names, but our customer will say he has a Samsung Galaxy S2. Most don’t know that actually they might have a GT-I9100G instead.

You really can’t say that your app is tested to work on a SGS 2 if you don’t have all the three different devices. And that wouldn’t account for the operator tailoring which might also be a factor in some cases. With that you might have somewhere between one and two dozen different versions of SGS2. For most developers it’s impossible to acquire AND keep acquiring every possible common Android device so it would be great if the manufacturers wouldn’t make the situation even harder :)

Microsoft demos a touch screen with 1ms latency

I just came across and interesting demonstration by Microsoft. They have a touch screen setup with 1 ms latency which is could be around 100 times faster than the current commercial implementations. In many cases good is good enough, but in this case it might be that many games would really benefit from the lower latency.

For example our games Ironworm or Swingworm could probably become a bit more responsive and more intuitive to control with reduced lag. The games use something called a “mouse joint” from Box2D to attach a physics simulation object to the touch coordinates. This adds a certain “springyness” to the control mechanic. Without the touch input lag the controlling the worm might feel better as the “grip” would be a bit more firm and responsive. On the other hand the current lag could be beneficial as it puts some distance between the player’s finger and the controlled object and that improves visibility.

Low lag input is most likely something that touch device makers are trying to achieve in commercial devices all the time since in most cases input lag is a negative thing. 1ms latency is probably impossible in real world situations, but improvement from 100ms to 50ms would bring the control lag to par with consoles and PCs.

iPad Retina Display Becomes Official

Azkend 2 on iPad 3

Azkend 2 on iPad 3

It seems the rumoured display is official so here’s another screenshot of Azkend 2 running at 2048×1536 on PC. We hope we’ll be able to support the new resolution as soon as possible! Hopefully the A5X packs enough horsepower :) If not, we might have to opt for a drawing resolution somewhere between the 1024×768 and 2048×1536 and upscale it from there. But we’ll see soon, it seems the devices will be available here in Finland on March 23rd.

Check out also the first and the second post for more screenshots.

Azkend 2 High Resolution Musings

Azkend 2 at 2048x1536

Azkend 2 at 2048x1536

Tomorrow we’re going to know if the rumoured “retina display” on the “iPad 3” is a real thing or just a rumour. Be it as it may, we’re prepared to take advantage of the extra pixels now or later. As developers of fancy looking 2D games, we hope that there’s sufficient horsepower behind those pixels in the form of raw fill rate. This simply enables us to push more stuff on top of other stuff on the screen :) You can see the main menu of Azkend 2 running at 2048×1536 in the image.

Posted in iOS

Possible “iPad 3” Retina Display Support Plans

10tons Ltd  will support the possible retina resolution in the theoretical “iPad 3” in several games. The games include Azkend 2, Joining Hands, Ironworm, and Swingworm.

“We have plans to support the possible “retina resolution” if the performance and memory resources permit. If not, we’ll probably use a resolution as high as we can within the performance and memory constraints”, commented Tero Alatalo of 10tons.

Ironworm at 2048x1536

10tons’ recent games include a total resolution independency and therefore supporting higher resolutions with those games will be relatively easy. These games include Joining Hands, Swingworm, Ironworm, and the upcoming Azkend 2. The possible updates will be free of charge. 10tons has already experimented running Ironworm in the 2048×1536 resolution and it looks like the potential updates should be quite painless.

“I have to admit that I’m quite excited about the possibility of a extra high resolution update for Azkend 2. The full screen animated and hand painted sceneries look totally amazing already on the iPad. With four times more pixels they must look so good that you’d want to eat them. The only downside is that the upgraded graphics will make the downloads bigger.”, said Sampo Töyssy of 10tons.