LATEST: A Slight Delay

We are preparing to load the demo mission for you
We are preparing to load the demo mission for you

As the first quarter of 2021 starts to slip away it’s becoming clear we aren’t going to have the demo ready for the CIC’s birthday in August. It was always an ambitious date, born from a desire of releasing something tangible rather than a reflection of our progress.

One issue is that we still haven’t found extra help in the roles of 3D art or programming. If you have the time and skills to contribute please let us know; it really will speed up development.

We are still aiming for 2021 but we won’t be announcing a new date until we are closer to release.

The completed Lexington model
The completed Lexington model

A new carrier

In order to minimize the delay one change we’re looking at is replacing the Intrepid model from the demo with the Lexington, which is already complete. The choice to use the Intrepid was always odd anyway as the gameflow in the demo is from the Lexington. This should free up Defiance to focus on other work that needs to be completed.

Pause menu with options selected
Pause menu with options selected

Recent Progress

We have still made progress, and we now know what we need to for the demo – however we want to take extra time to add polish to ensure our first impression is a good one.

One piece of such progress is the UI, you can see the UI is now running in game, fully animated and with audio. The options are saved and loaded and the game respects all options in flight. The pause menu is rendered onto a 3D object rather than done in 2D so that it will play nicely with VR.

While we’re at it we’ve spruced up the briefing screen and the splash screen. Truth be told we are *just* about on schedule.

But a tight schedule doesn’t give us time to polish, to deal with hardware specific issues – and even if we were were prepared to let quality slide the next task to be tackled is probably going to take even longer than the UI.

32-bit number representation
32-bit number representation

Our next technical challenge

“Space is big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space.” ― Douglas Adams, The Hitchhiker’s Guide to the Galaxy

This next task is a matter of scale, and interestingly 1996 had an advantage over 2021. Time for a little programmer 101.

Generally numbers are represented in one of two ways; a precise integer with no fractional part, or a real number (a floating point value). With a floating point number the range being represented is variable depending on the exponent.

Wing Commander IV however appears to use a hard coded exponent rather than floating point.

For positions it really makes no difference if an integer is treated as fixed point, it’s all just a matter of scale. The range of values you can represent is limited, but within that range those values have equal precision. Wherever in the play area you were in WCIV precision was identical.

Modern titles all use floating point; the downside of this is the larger the number you need to represent the fewer bits available for the fractional part.

Floating point uses 8 bits to encode the exponent, so when it is having to encode huge values at the edge of the world, small differences (like the difference between two vertices on your cockpit) become unreliable.

Prophecy: Coffee Jitter struts
Prophecy: Coffee Jitter struts

So what did Prophecy do? Surely that was using floating point math.

Seemingly they swept the issue under the rug. Keep an eye on your cockpit struts; in some areas they appear static, in others they bounce around; admittedly in a way that might lead you to think it was intentional. Some fan mods had extreme examples of this issue at times because we put the navpoints too far from world origin.

Prophecy got away with it at 640*480 with no panels on the cockpit, but we can’t.

I know what you’re thinking: “why aren’t you using a 64bit precision floats?”

The truth is it’s an option, but not a clean one. GPUs tend to use 32bit precision by default (on mobile you will often want to use 16-bit floats where possible and there is hardware on the market that doesn’t support anything higher than 24-bit). Even today the general recommendation is don’t do 64bit math on the GPU.

Even on the CPU 32bit floats are still the norm, SIMD (single instruction, multiple data) registers tend to 128bit, representing 4 32bit floating point numbers.

Instead we are going to periodically shift the scene closer to the origin so that we don’t experience these precision issues, this will touch on the physics and we’ll be doing some cleaning in that area while we are at it.