Full UI Upscaling, Part 3: Dynamic Terminal Swapping

I was really happy to have come up with workable concept for a modal inventory, as well as producing a mass of mockups with proven solutions for all the potential hurdles on the road to dropping 15 rows from Cogmind’s interface. Or so I thought.

Suddenly at the end of that process, a review of remaining UI systems revealed an unexpected show-stopper: ending animations.

Cogmind has a lot of different endings (currently nine, with more to come), and all of them feature full-screen ASCII animations. While some of these are flexible enough to fit dynamically within any terminal dimensions, a good many were designed to assume a height of 60 rows. The only way to fit those into 45 rows would be a complete redesign…

I put a lot of time into the existing animations, and they make good use of their space, so one would hope there must be another way…

Terminal Swapping

What if… the terminal was still 60 rows during ending animations?

After all, there’s no strong need for the endings to be limited to only 45 rows--you’re essentially watching these animations for the overall visual effect rather than needing to interpret every little detail for gameplay purposes. As described at the beginning of this series, the reason for shrinking the base terminal dimensions is to enable larger fonts across the board, but the intent there is to facilitate reading and interpreting details, which we don’t need in this case.

So the theory is we use a 45-row terminal for normal play, but once we need to do an ending animation simply switch over to a 60-row terminal to display that, then switch back when done.

This reminds me of games that switch to a different display mode specifically for cut scenes, especially common (and noticeable) in early video games, and then later it became a big deal when those sorts of things could be done “in engine,” which is the norm nowadays. Cogmind has always been consistent about its display, but in this case I could ideally continue to make use of all the work that’s already gone into the animations.

Now come the important questions: Is the engine architecture capable of such a feature, and what other roadblocks might be in the way?

Technically the idea immediately showed some promise based on the fact that Cogmind already uses what I call “terminal swapping,” but only between frames and behind the scenes, specifically for special screenshotting purposes.

The main usage is for map output, or creating a composite PNG containing the entire current known map. This is useful for sharing interesting layouts with other players, or asking for advice about where to explore.

I also used it to produce an image marking the launch of Cogmind’s achievements, for which I wanted the background to be a matrix of many achievement icons.

Both of these use cases required generating an image larger than the screen, so a normal screenshot wouldn’t do.

Already armed with a built-in way to take a “screenshot” of the terminal contents (bypassing the screen itself entirely), if we build a larger terminal than the screen we can just as easily run the “screenshot” process on that to produce an even larger image.

With just a small bit of isolated code it’s pretty easy to temporarily replace the engine’s terminal with one of a different desired size, write to that, generate the image, then restore the original terminal as if nothing happened. We’re not actually rendering to the screen itself so resolution doesn’t matter, we don’t need to change the video mode, none of this is ever displayed, nor does any outside interaction occur.

This was a promising starting point, at least providing a theoretical approach for our ending animation management.

REX, Again

The above initial examples of basic terminal swapping are pretty much entirely Cogmind-side. As it’s happening between frames for the sole purpose of creating an image using the normal system, the engine doesn’t need to know or care about what’s going on. All that was needed was a simple function allowing the root terminal to be swapped out for another one.

Taking the next step and swapping the terminal with a new one that would exist for a longer duration, and even involve some level of player interaction, would be a much more complicated process, meaning it’s once again time to revisit the engine to expand its core capabilities, like I did not too long ago with the quads and octs powering the map zooming system.

Also once again, as an engine feature it makes more sense to head back to the simpler engine testing environment to build and debug it, rather than using Cogmind itself.

I was pleased, and surprised, to find that terminal swapping of an extended nature really wasn’t an incredibly complex operation with many repercussions. As far as the engine was concerned, it only required changing a handful of core variables, although beyond that I had to resolve some cursor-related issues, like crashiness related to its screen position and hover data, and the software cursor dirty rect status.

It took about a day to implement terminal swapping and work out all the kinks.

The next stage in building this feature would be to import it into Cogmind while changing as few variables as possible. It doesn’t have to be specifically for endings, and we don’t even need to start by actually changing the terminal dimensions--simply swapping from the default 60-row terminal to another 60-row terminal and back would be sufficient to weed out any issues with regard input or other basic functionality. One step closer to a real use case scenario. That went fine as well!

When and Where

Having passed a simpler test, it was time for the real thing, but exactly where is the best opportunity for a swap to take place? Swapping is a pretty significant cutoff, after all, forming a clear barrier between what is before and after, and there shouldn’t really be much talking between the two sides, at least not on an interface level.

As stated at the beginning, the goal here was to allow animated endings to use 60 rows instead of 45. Given the simplicity of terminal swapping at the engine level, it seems easy enough…

As so many things are, up close it no longer looked so easy.

I originally imagined just having the animation segment of the ending in a different terminal, and tried that for a bit, but the endings (there are so many xD) are a relatively complex collection of classes and processes since they mix and match different components, and it was really hard to untangle what needed to be untangled. Even before considering swapping needs, it turns out that in many cases the process involves multiple windows in varying states of visibility and overlap. While swapping right before an animation would be possible, it would likely be pretty tough to both implement and debug.

Then a new idea popped up: How about instead of focusing so tightly on the animations we move one level higher and handle the entire game over process in its own separate terminal interface? This would include the standard game over screen (losses as well), stats, and restart menu etc. This is a much cleaner break, far easier to pull off without worrying about any serious complications.

The only drawback is that said stats screen would then be in the 60-row terminal interface using the original font size. In other words, back to the smaller font. Still, this might be fine since it’s 1) just text, 2) not a lot of text, 3) only in that one spot, although if we wanted to we could perhaps use the new zoom text font size to display it. Doing so would require reducing the number of listed stats in order to fit in the available space, at least if trying to keep the vertical design. They’re only a tiny subset of those found in the massive scoresheet data, anyway, but I don’t like the idea of further slimming down the already short representative list, so it’s either accept a smaller font size for that particular screen, or eventually go as far as a more significant redesign that makes more use of horizontal space. I tried a few mockups but didn’t like any of them, so nothing will probably change with that at first.

While working on this whole terminal swapping business I also happened to discover that if you manage to close the game window during an ending animation (including the loss animation), it would not overlay the separate program close animation that I added some versions back. This is not an uncommon occurrence, inadvertently uncovering obscure bugs in old, or in some cases very old, parts of the source that were simply never encountered or noticed before. Always a good opportunity to stay alert and fix things :)

One final note: For an article about new tech to support ending animations, there is a curious absence of samples demonstrating the primary use case, but I figured I’d leave those out ;)

This is the third in a multi-part series about building Cogmind’s fully upscaled semi-modal interface layout:

• History and Theory
  
• Holy Mockups
• Dynamic Terminal Swapping
• Simpler Lightweight Fonts
• Completion and Demos