The developers at Antix Labs* had an innovative idea: What if people could enjoy high-performance games across all of their devices, just like they’re used to doing with music, photos, videos, and documents? The Antix Game Player* (AGP) is a middleware layer that allows users to do exactly this. AGP abstracts the operating system, chipset, screen size, and orientation and input device, providing an on-device, software-based game client. From the developer or publisher’s point of view, AGP bootstraps rapid cross-platform deployments of game content and services and provides built-in protection for the revenue and intellectual property rights of publishers and operators.
From the consumer’s point of view, AGP provides a means by which a user can install, manage, and play games distributed in the Antix ATX format. ATX offers a single, portable executable format for use on all of the devices on which a user might want to play a game. Consumers can enjoy and share high-quality games online or offline as well as on phones, personal computers, TVs, and other connected devices. AGP allows users to play high-performance content across a broad variety of devices and to copy their games from one machine to another, share those games with their friends, and connect using the Internet or short-distance networking technologies.
Streamlining the Mobile Development Process
Historically, multiplatform, mobile-targeted game development has been a costly and time-consuming affair—not least because of multiple tiers of fragmentation. Devices, operating systems, and market barriers imposed by carriers have had a track record of bedeviling game developers trying to break into the platform-neutral mobile gaming space. Recently, however, the combination of netbooks and open source technology has done a lot to change this landscape, allowing developers to take advantage of familiar tools, targets, and legacy code bases for both Windows* and Linux*. The Antix developers’ experience in moving their product from Moblin™ v1.0 (the first Intel release of Moblin back in 2008) to MeeGo* provides some worthwhile reflections on how to make the hop. Here’s why: As of today, AGP runs on mobile devices, including Android*, Linux (Nokia Maemo*, Moblin, and MeeGo), Symbian* OS S60, Windows, and Windows Mobile* as well as diverse processor architectures designed by ARM*, Intel, and MIPS.
Maemo* + Moblin™ = MeeGo*’s Heritage
Nokia Maemo and Moblin are the progenitors of MeeGo, and each brings strengths and advantages to mobile developers. Maemo offered a Linux-based software stack for use on mobile devices. Obviously, taking its source into account, it had a considerable smart phone bias. However, it was also used in devices like tablet computers. In contrast, Moblin was the Intel entry in the mobile Linux space, but it was a good deal more device-agnostic, being widely deployed to mobile Internet-based devices, netbooks, and in-vehicle systems. One of greatest strengths of Moblin was that it could wake up a device very rapidly and be available for connected use in seconds.
As a hybrid of these two systems, MeeGo incorporates many of the best features of its ancestors: MeeGo runs on many types of computing devices, including handsets, netbooks, tablets, connected TVs, and in-vehicle systems. It gives developers a larger market by aggregating device types, and it benefits from the combined efforts and resources of the two teams that worked on its predecessors.
Moving to MeeGo* vs. Previous Ports
For Antix lead developer Kevin Digweed, one of the best surprises about working with MeeGo was that he got to use tools he already knew and preferred. “For me, porting from Moblin v1.0 to MeeGo was a relatively painless experience. I was able to do some development work on-device, using a netbook. On my Ubuntu desktop, I set up an environment where I could run my MeeGo binary builds natively. This had two main benefits: First, all of my favorite Linux command-line and GUI [graphical user interface] tools—as well as some in-house tools—ran just as I am used to seeing them do. This meant the tools with which I am experienced and comfortable were available to write, analyze, and debug the code. My MeeGo development environment was immediately familiar, with very close to zero learning curve.” Digweed felt that he received a significant productivity boost, because the binaries for his port ran natively on the desktop. “It was a painless process to iterate over the development cycle,” said Digweed. He was able to do preliminary testing on the desktop; then, using a simple Copy operation between his computer working directory and the netbook, he could run and test on the target device. “I didn’t have to waste my time setting up and configuring VMs [virtual machines], emulators, or cross-compilers,” said Digweed.
The Antix Toolchain for the MeeGo* Move
In this port of AGP, Digweed and his team members worked on code that was written in about 90% C, with most of the rest in C++. “I used Ubuntu 9.10 exclusively for the desktop environment. One big productivity boost came from the fact that I was able to set up a chroot environment on my development workstation,” said Digweed. The chroot technique is powerful for sandboxing an application that is in the early stages of development and may not be entirely stable. It works like this: On a Linux- or UNIX*-like operating system, chroot changes the effective root directory for a specific process and any child processes it spawns. Doing this essentially defines a limited execution environment for the process. This technique allowed Digweed and his collaborators to create a runtime environment on the desktop that was more or less identical to the one the AGP would see on an actual target MeeGo device.
When it came time to begin debugging, Digweed and his colleagues began working natively—on the target device—as early as possible. “I did my initial assessments using the chroot environment, but if there is one recommendation I can make to other developers, it’s this: Always do your final debugging and QA [quality assurance] passes on the device, because in terms of behavior and performance, that way you’ll see the same things that your users do,” says Digweed.
Most developers who have had small device experience expect to encounter at least some difficulties setting up remote debugging. Many issues can be involved in connecting two devices over a cable or network connection and getting them both to agree on the details of communication and process control. Here again, the Antix team was happily surprised by the efficiency and lack of complexity involved. They used the GNU Debugger (GDB) on both the desktop environment and the target device. GDB runs on most UNIX-like systems and works for a variety of development languages. Of the Antix project’s experience, Digweed said: “It is a good choice in a mixed-language development effort, and many developers are familiar with it. Because the target device was a relatively powerful netbook, I was able to simply install and run the debugger locally on both systems. If I had to debug on a more restricted device such as a smart phone, I would have investigated running gdbserver on the device, communicating with my desktop over TCP/IP.”
If you aren’t familiar with gdbserver setup, here’s how this works:
1. On the netbook side of the connection, make a copy of the executable you are debugging and the gdbserver application.
2. Launch gdbserver on the netbook, providing as arguments the fully qualified path of the debugging target and a port number, which can be either TCP/IP or Universal Datagram Protocol (UDP).
3. When gdbserver starts the application on the target device, a status message shows the process ID (PID). Note of ID: You need it to connect the GDB on the host to the gdbserver session on the target device.
4. On the host side, you need both the executable and the source files for the debugging target.
5. Launch GDB on the host, specifying the application to be debugged as an argument.
Note: Typically, environment settings resolve the paths to source and .exe files, and you won’t have to supply full pathnames. (If this doesn’t reflect your situation, type gdb –help for more options.)
6. At the GDB command line, point GDB to the remote target as follows:
• target remote mylittlenetbook:1234 (where 1234 is the PID you got from the gdbserver launch and mylittlenetbook is the system alias )
–or–
• target remote 145.114.13.85:1234 (where 1234 is the PID you got from the gdbserver launch and 145.114.13.85 is the netbook IP address)
Ultimately, the Antix team made rapid progress moving AGP to MeeGo, because they were able to do a lot of on-device development using a netbook. On the order of 20–25 percent was handled this way, split across several development phases.
“The way I worked was to get each main development task functional on the desktop, and then to moved to the netbook for any fine-tuning that needed to be done, based on the results of on-device testing before returning to the desktop for the next main task. By moving between the two environments in this way, I knew I wasn’t potentially storing up a set of fine-tuning tasks by waiting until the port was largely finished, and then moving to the target device. This meant that I could be much more accurate in my planning and timescale estimations,” said Digweed.
Given that this was the team’s first experience with MeeGo and that they were working on a code base with which they were extremely conversant, the development group felt that they profited by being able to use familiar, favorite tools that were largely command-line based. However, Digweed observed that if starting a new project from scratch, they would certainly investigate using an integrated development environment (IDE) such as Eclipse for the main development environment on the desktop.
MeeGo* and the Open Source Community
By merging the Maemo and Moblin open source communities and technology bases, MeeGo has significantly expanded market size for developers of mobile apps. MeeGo runs on a wide range of devices and chip architectures, which makes moving to it a low-risk proposition. Keeping the platform open source maintains freedom for developer innovation and helps to secure the way forward by embracing the tradition of developer community involvement. “The point here is that this is a stable, mature, open source standards process but also one that has a vibrant and growing community participating in its advancement. The stated objective of the MeeGo group is to lay the foundations of an ecosystem that allows for applications to be both portable and accelerated on a variety of silicon platforms,” says Digweed.
Antix enables game developers and publishers to target devices as game platforms without doing a triage based on likely sales or device population trends. This means that Antix supports proprietary platforms as well as open source options. The key to their cross-platform strategy is leveraging open source tools and technologies for graphic rendering and acceleration. In pursuit of this goal, Antix is actively engaged with the larger open source community, including playing a central role as a contributing member of the Khronos Group. Founded in 2000, the Khronos Group is a member-funded, nonprofit industry consortium of media-focused technology companies whose mission is to create open-standard, royalty-free, platform-agnostic application programming interfaces (APIs) for content development and accelerated playback. Today, there are better than a dozen significant sets of Khronos APIs that are used to target a broad array of devices. More than 100 Khronos Group company members, including Intel, contribute to the projects.
Antix Labs takes particular interest in Khronos working groups that define specifications for dynamic media APIs, serving as specification editor for the OpenKODE APIs. OpenKODE is an abstraction layer for operating system resources like file systems and networks, with a particular emphasis on media, graphics, and parallel computing acceleration. It provides a standard for a comprehensive media stack specification based on a set of native APIs. Says Digweed of the OpenKODE toolset’s advantages to his project: “It makes high-end media capabilities available in a consistent way, across all platforms that implement it, by accelerating media and graphics processing. One of OpenKODE’s big benefits to the Antix Game Player is that the Khronos Media APIs offer state-of-the-art acceleration for rendering 2D and 3D graphics whether we are running on Linux, Brew, Symbian, Windows Mobile, WIPI, or RTOS-based platforms.” By contributing back to the OpenKODE community, the company is able to influence the evolutionary direction of APIs and components in ways that allow its AGP product to rapidly and gracefully migrate across new platforms and stay in front of device evolution.
The Take-home Lessons of the Antix Move to MeeGo*
When asked to sum up the porting experience, Digweed framed his thoughts in terms of the overall business environment for mobile gaming. “Increasingly, consumers want to move their content across a lot of devices and do it quickly and conveniently. They want to access services like game scoreboards and multiplayer environments from laptops and desktops but also from smart phones, netbooks, and TVs. Open source technologies like MeeGo and OpenKODE support rapid, cost-effective delivery of products that meet consumer demands for features like 3D graphics acceleration, high-quality vector-based fonts, 3D interprocess navigation, and advanced user interfaces. Having key players like Intel and Nokia behind MeeGo is an open source community win for everybody.”
Source Intel AppUp Developer Program
Related News
