Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bryan See on April 05, 2015, 05:47:25 am
-
Okay, I've been testing the hard-coded autopilot feature for some time. In particular, the flying beyond mission bounds at 512 kilometers from the origin resulting in the warnings of stray and eventual destruction of the player craft needs special attention, especially when the player completes all mission objectives.
Though it can be accomplished by either LUA scripting or modifications to the main FS2_Open code, flying beyond mission bounds will not result in the player's being destroyed. Depending on goals and events mission designer has to specify, it can be changed dynamically: for example, in a retreat scenario during some mission, flying towards the bounds as the mission objectives ordered.
As for the size of the mission bounds, the 512 km limit may be bumped (giving it unlimited range) or increased to at least 65536 km. I want the NAVs' placing to be similar to the Wing Commander games; below is the game from Wing Commander Prophecy showing the selected NAV point is 3776 kilometers away from the player. Also, the mission bounds can be specified by the mission designer rather than being hard-coded.
(http://lparchive.org/Wing-Commander-Prophecy/Update%201/img-1.jpg)
I think it's neccessary, because high-maneuverability mods require tremendous distances to travel and that will take a longer time even on max speed (500 m/s for fighters and bombers and 350 m/s for capships). I am making one such mod, called Shattered Stars (http://www.hard-light.net/forums/index.php?topic=88909.0).
Included here is the FS2 mission file.
[attachment deleted by nobody]
-
One very good reason for keeping the mission area bounded is floating point number representation errors. Specifically, when you move too far from the origin of the mission space floating point numbers (which are used for all distances in FSO) have greater and greater discontinuities between (https://support.microsoft.com/en-us/kb/42980) consecutive representable numbers (https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems). i.e. the gaps between representable numbers may be 10's of metres away. I believe a number of HLP'ers in the past have experimented with this and (in a humorous fashion) reported their experiences.
You could have a look at how WCS:DD worked around this issue. I think there is a setting somewhere that allows scaling of reported distances, so that it will *look* like the waypoints are 3776 kms away from the player, but in reality they are far closer. Ship speeds would also be adjusted by the same amount which would work around your issues with the AI being unable to handle high speeds.
Oh... and before you suggest replacing all the floats in FSO with integers, note that this would be a massive change to the engine. Also, AFAIK graphics cards *want* their data in float representation, which could possibly incur relatively expensive conversions all over the place.
-
Also, AFAIK graphics cards *want* their data in float representation, which could possibly incur relatively expensive conversions all over the place.
I wonder how other engines handle this situation. I'm not asking for this, but would it be plausible to treat the player's ship as an origin and have all other objects be moved relative to it?
-
Sure. UE4, for example, has modes where it does just that (and I believe that to be the default thing to do when you stream in assets as the player moves through the world). But it's something that the engine has to be engineered to do from the start; I don't think it's easy to retrofit this sort of behaviour.
-
Sure. UE4, for example, has modes where it does just that (and I believe that to be the default thing to do when you stream in assets as the player moves through the world). But it's something that the engine has to be engineered to do from the start; I don't think it's easy to retrofit this sort of behaviour.
Agreed.
-
What if you just made everything smaller?
-
I think we ended up doing that for Beyond The Red Line and used HUD scale distance.
-
I did not plan to change from float to integer which is more work to FS2_Open's code, nor work around the limit as WCS:DD. I want to bump the mission bounds limit from around 512,000 to about 65,536,000 or possibly larger (4,294,967,296,000 or unlimited theoratically).
I reminded earlier that it was initially planned that the speeds will be higher (fighters and bombers move at 500 m/s, and capships move about 350 m/s), and the distances will be the same as ships travel from one point to another in FreeSpace, even in autopilot mode (particularly when in autopilot cinematics).
-
I did not plan to change from float to integer which is more work to FS2_Open's code, nor work around the limit as WCS:DD. I want to bump the mission bounds limit from around 512,000 to about 65,536,000 or possibly larger (4,294,967,296,000 or unlimited theoratically).
Then how exactly do you plan to circumvent the floating point inaccuracy issue? You're going to run into it eventually at those ranges and speeds.
-
I did not plan to change from float to integer which is more work to FS2_Open's code, nor work around the limit as WCS:DD. I want to bump the mission bounds limit from around 512,000 to about 65,536,000 or possibly larger (4,294,967,296,000 or unlimited theoratically).
I reminded earlier that it was initially planned that the speeds will be higher (fighters and bombers move at 500 m/s, and capships move about 350 m/s), and the distances will be the same as ships travel from one point to another in FreeSpace, even in autopilot mode (particularly when in autopilot cinematics).
If you have autopilot cinematics, then your problem's solution is right in front of you. Make a series of sexps that moves all relevant ships to the map origin when the autopilot cinematic ends. This way, you will not likely need to hit the maximum.
-
If you like using cockpit models (or "show ship" flag), floating point inaccuracy issues are quite important, it turns out. I've tried that, even at with WCS-style workaround, there is a noticeable shuddering of the model.
Using the player's ship as origin would be a good idea (KSP does pretty much that), but would likely require a huge rework to the game engine. I think that it'd be great if someone eliminated mission size restriction (and the cockpit shudder bug), but the amount of work required for that will be rather large.
-
We can explore raising the size of the mission box, but unless we get a good solution to the floating point inaccuracy issue, we will not be removing it. There's no point in letting players or mission designers get so far away from the origin that the simulation breaks down.
-
BTW, what kind of floats does that system use? Singles or doubles? I have a feeling that converting from singles to doubles would be easier than converting from floats to ints. I'm probably wrong (I've never worked with the likes of Codethluthu :) ), but it's a thought. There are also quads, but IIRC, they're slow.
-
Moving to doubles would slow the game down plus GPUs are expecting 32-bit floats.
-
Besides changing every single float to an int, would another option potentially be creating some sort of overlying relative coordinate system, in which you could split the mission space up into separate integer regions? Though that'd no doubt be hideously complex and/or utterly unworkable with the current codebase.
-
It'd very possibly be an order of magnitude slower.
-
It'd very possibly be an order of magnitude slower.
Far from it. Hundreds of coordinate operations occur every frame, only a few of which rely on the absolute coordinate location. Dividing up the game space into "zones" as Mongoose suggests is not only possible, it has been done successfully in many games for many years. The problem is not the speed impact (which is minimal), it is the increase in code complexity.
-
Moving to doubles would slow the game down plus GPUs are expecting 32-bit floats.
Would the slowdown be significant? From what I recall, the big deal with doubles is that trigonometric functions are slow with them. Does FSO use a lot of these? IIRC, KSP uses doubles for at least some coordinate-related calculations.
-
Doubles are twice as big as floats. We use floats everywhere. That basically means our memory requirements have doubled. Doubling the amount of space our basic data type uses basically means we can only fit half as much discrete data into cache. Less elements we can fit into CPU cache equates to a significant performance hit.
-
Would the slowdown be significant? From what I recall, the big deal with doubles is that trigonometric functions are slow with them. Does FSO use a lot of these? IIRC, KSP uses doubles for at least some coordinate-related calculations.
Afaik modern CPU's calculate internally in double-precision anyway, so doubles will be as fast or marginally faster than floats as far as CPU is concerned, but that ignores cache issues Swifty mentions, which is something you'd probably need to benchmark to assess reliably.
The biggest performance hit you'd get would be if SIMD instructions are heavily involved, because they naturally work with twice as many floats at the same time.
Of course if there's a real need for larger mission areas in some mods, you could maintain different single- and double-precision exes, but is there really?
btw. a totally wild guess is that, considering how messy floating point arithmetic is, some rearrangements of operations could improve precision, but that would take a lot of time and specific knowledge to do and with likely no significant results, so it's hardly the most exciting of prospects.