Splash Screens: aka Don't mix your Drawing APIs

This is a retrospective post on the work done on Salvager from the 21st to 28th of September. This was the first week of Month4, the last month of development for the Project but there were still a lot of core features that were pending from the previous build at this time. Therefore, a big focus of this week was catching up by completing some of these features before transitioning into tasks that prepare the Game for its final release state. But among the few new features I worked on during this week was the task of Implementing Splash Screens during the Game's startup. In this post, I'll talk briefly about the issues I faced while completing this task and also how I ended up resolving it in the end.

The Game currently is fully rendered by DirectX 12 with Nuklear sitting on top of the Graphics API Layer to support UI Rendering specifically. If you're familiar with Modern Graphics APIs, implementing new passes in DirectX 12 incurs a lot of overhead with boilerplate code and resource management if you don't have a sufficiently competent system already in place to make these things a little easier. With this in mind, I decided to try a different approach for rendering Splash Images with the hope of putting together something faster than I would have to with DirectX while also not modifying any of the existing Rendering code and possibly creating new bugs.

The Splash Screens are simple images that ideally fade in and out and stay on screen for a second at most. It didn't need the feature set offered by DirectX and could possibly be done before initializing the other Rendering systems. To this end, I decided to use GDI to handle the Splash Images. GDI is a native API provided by Windows that lets you perform simple Bitmap drawing in a Win32 window. It is a somewhat antiquated API, replaced these days by Direct2D or hardware-accelerated libraries built on a Graphics API, but being part of the core Windows API meant that I wouldn't have to go through a ton of setup to have something drawn to the screen, making it seem perfect for my use case. But issues quickly cropped up with supporting Transparency in the composite image and also in getting GDI to coexist with DirectX through some obtuse errors that resulted in the window not being drawn to by GDI.

In the end, a  lot of these issues proved too time-costly to debug and track down and I ended up biting the bullet and implementing the Splash Screens in DirectX. This was accompanied by a refactor of the Rendering code which reduced its complexity and coupling and helped integrate the new code without too many issues. After adding in support for loading in Image data from the Targa File Format and some timers to update the Splash screens and their opacity, I was able to have something that met the requirements without overcomplicating existing code or adding in new bugs. While it looks very ad-hoc in its implementation, using DirectX meant that I was fitting the new code into patterns previously established for other Rendering which helped with quick implementation the second time around.