Recently I’ve been checking out game controllers (in a limited fashion), UI rendering performance (not great), and low-level OpenGL API usage (porting to Qt 5).
Game controllers
I have a bunch of gamepads lying around so I decided to check out how well they work with Doomsday (on the Mac). I already previously did this with a PS3 gamepad, but now I also tried PS4 and Xbox One controllers.
The current in-game UI for configuring input bindings is cumbersome and outdated, so I gave it a pass entirely. Instead, I used the game controller presets mechanism that I implemented a while ago. It uses Doomsday Script to configure reasonable input bindings for a particular type of game controller.
In the process of doing this I fixed a bug with binding joystick hat and gamepad D-pad controls.
The problem with doing presets like this is that the actual mapping of the device inputs may not be the same on every configuration, and almost certainly is different on Mac vs. Windows. Still, this work is valuable in that one can verify that it is at least possible to use a gamepad with Doomsday to play the game without any major capabilities missing. Implementing a new in-game control bindings UI remains pretty high on the priority list.
If you happen to have a PS3, PS4, Xbox 360 or Xbox One controller and wish to try out these presets, you can do the following:
- Plug in or otherwise connect the controller to your computer.
- Launch Doomsday and check the console log to see if the controller was detected.
- Go to the Input Settings dialog and make sure game controllers have been enabled.
- Select a suitable controller preset and click Apply. All your existing gamepad/joystick bindings will be replaced with the preset bindings and axis parameters.
- Enjoy (?) the game playing on a gamepad.
I’ll be interested to hear whether these presets are actually working for you. However, if you have remapped your gamepad controls on the system level in any way, don’t expect these to be very useful.
UI graphics performance
My work on the UI has thus far been largely focusing on making it feature-complete, and not that much attention has been paid to raw performance. I recently did a test run on Windows and noticed that the Qt-backed text rendering was blocking the UI thread in some cases, causing stuttering UI performance. (On the Mac I use native font rendering, which seems faster.) As a workaround, I moved the slow part of the text rendering to a background thread to avoid blocking the UI.
I’m still not happy with the general performance of the UI. I’m currently investigating two avenues: optimizing the OpenGL API usage (smaller number of draw calls) and thinking of ways to reduce overdraw/blits (removing unnecessary copies between framebuffers, for example).
Qt 5 OpenGL APIs
Looking at the OpenGL performance lead me to another long-neglected task: porting the low-level OpenGL code to use Qt 5’s OpenGL APIs. Thus far we’ve been relying on the older Qt 4 OpenGL classes that are not as flexible or modern. The new Qt APIs are platform-independent and support both full OpenGL and OpenGL ES and have clean API versioning. They provide portable access to OpenGL extensions, too.
For the past several days I’ve been refactoring and cleaning up the low-level window initialization and drawing code so that access to the OpenGL API occurs via Qt 5 instead of the old, custom code for this purpose. This has the benefit of making the code more robust and easier to maintain. The general idea is to switch to the new Qt APIs now and stay with OpenGL 2.1 until the renderer itself can be revised to work with OpenGL 3+. The new Qt APIs make it much easier to do this switch in the future.