I’ve spent the past couple of weeks experimenting with an iOS port of Doomsday. This is now at a proof-of-concept level and not playable yet. It isn’t quite the right time to continue much further along this path, but read on for my findings!
OpenGL migration
During May, I’ve been migrating Doomsday’s OpenGL code to version 3.3 of the API. This is quite significant because many of the deprecated legacy OpenGL features are no longer available in this version, and thus Doomsday’s existing code needs a few important adaptations. This version of OpenGL is also well-aligned with OpenGL ES 3, the API that is offered on modern iOS and Android devices.
The long-term goal is to revise the renderer to work in line with the expectations of present-day OpenGL. In the short-term, though, adaptations for old code are important because they at least provide functionally correct rendering even though the performance is nowhere near optimal levels.
These OpenGL 3.3 adaptations are already working quite well. The big upside is that all rendering is finally going through shaders rather than relying on the old fixed-function pipeline.
Mobile platforms
I’ve long been wanting to port Doomsday to iOS and Android. This is one of the reasons why Qt was chosen as the underlying software framework (due to its wide platform support). While mobile devices may not exactly be the optimal way to play a game like Doom, they are also great because they force you to really think about performance optimizations and utilizing the hardware to its fullest. This kind of work will benefit Doomsday on all platforms. There is also something really attractive about having the game in your pocket at all times.
The great thing about OpenGL 3.3 is that it is largely compatible with OpenGL ES 3, the current version of OpenGL available on iOS and Android. This means that as far as the rendering is concerned, most of the code should just work on mobile.
With this in mind, I have been putting together a proof-of-concept build of Doomsday for iOS. From a technical perspective, this actually entails incorporating Doomsday’s rendering and input under a very thin Qt Quick (QML) wrapper. The benefit of this approach, instead of using native software components directly, is that the same setup will work on Android in addition to iOS. In fact, it would also work on the desktop but the environment there is different enough to warrant using the traditional window-based approach.
While the progress so far is quite promising, there are still a couple of big hurdles to overcome. Doing a full-fledged mobile port is plenty of work:
- The game input mechanisms need rethinking. On the desktop, Doomsday relies heavily on mouse and keyboard input, neither of which are available on a mobile device. The common approaches here are virtual D-pads/buttons and tilt controls, and of course using supported physical gamepads.
- There are various OS/third-party integrations needed for accessing your IWAD files and add-ons. For instance, one might like to load the IWADs from Dropbox or another cloud storage.
- The UI needs to be tweaked for small screen touch-only interaction. Doomsday’s UI widgets are already quite flexible when it comes to resizing, but things like scrolling by dragging with your finger need to be implemented separately.
- Optimizations of all kinds. It isn’t very nice if the device runs too hot and/or the frame rate is choppy.
- Qt 5.8 still uses only static libraries on mobile. I gather this will change in Qt 5.9, which would make it easier to deal with Doomsday’s plugins since they would not have to be statically linked into the executable any more.
The overall plan regarding mobile is that it will be a longer-term goal. The rendering enhancements planned for version 2.2 are quite essential for mobile, so an official release would occur in the 2.3/2.4 timeframe at the earliest. Nevertheless, doing an experimental port at this stage has clarified a number of things for me in terms of what is actually required. This should make it easier to continue making preparations in the future.
Raspberry Pi
In addition to mobile devices, Raspberry Pi is also quite an interesting development platform. The OpenGL situation there is a little bit more constrained, though, with only OpenGL ES 2 supported. Compared to ES 3, it lacks a couple of useful features, but none that are showstoppers for Doomsday.
At this time I would estimate that after the 2.2 renderer enhancements are done, it will be quite straightforward to make a Raspi port as well, but presently it’s a bit premature. It’s easier to develop the mobile support first on iOS/Android, largely due to how slow software compiling is on Raspi (without distributed builds, cross-compiling on Linux, or other such tricks).