The Star Citizen Thread v5

Status
Thread Closed: Not open for further replies.
There is the theory that the map size is still 8000x8000x500 m with just the ships and player characters being scaled down to millimeter sizes and that is the reason why everything glitches and breaks.

~relative distance between Earth and Venus = 261,000,000 km and c=299,792.458 km/s. That's about 870 seconds which equals roughly 14 minutes of flight time and that's at the speed of light. Lets see how long it would take at 20% the speed of light (QD speeds) if they modeled real solar system distances.

.2c = 2,997.92458 km/s

261,000,000 km/2,997.92458 km/s equals about 87,060.22885 second which is roughly 24 hours.

I think shrinking down the size is perfectly fine for game play purposes; you know rule of fun ;)

I know that one of Elite's bullet points is that it's fairly accurate in its milky way simulation but kind of ludicrous that you have to sit back and twiddle your thumbs when jumping to Alpha Centuari and having to cruise ~30-40 min to get to an outpost (this isn't the only system that does this). That's cool if you like that but generally speaking not a whole lot of gamers like that.

Still I commend Elite: Dangerous for sticking with relatively realistic distances.
 
~relative distance between Earth and Venus = 261,000,000 km and c=299,792.458 km/s. That's about 870 seconds which equals roughly 14 minutes of flight time and that's at the speed of light. Lets see how long it would take at 20% the speed of light (QD speeds) if they modeled real solar system distances.

.2c = 2,997.92458 km/s

261,000,000 km/2,997.92458 km/s equals about 87,060.22885 second which is roughly 24 hours.
Yeah, see… this is why you don't bother with km for interplanetary distances — too easy to get misplace a magnitude or five and get it wrong. Why bother with all that and end up with something silly when you can just go:

870 Ls / 0.2c = 4,350s, or if you like, even simpler: 14.5 minutes × 5 = 72.5 minutes. ;)
 
As much as some would like to see a divide, everyone should just take a step back and enjoy what both games are doing for the genre. Stop being so perturbed and follow the example set by both leaders in this video:

[video=youtube;NvPU8e2ezgo]https://www.youtube.com/watch?v=NvPU8e2ezgo[/video]
 
SC 3.0 looks amazing. I can't wait for it.

A proper live system with seamless transitions, awesome graphics, walking around and missions, trading, bounty hunting, planetary landings, pirating and more.

*Hair stands on end*
 
Last edited:
I'm pretty convinced, that this whole "64 bit" story never ever happened. Higher precision doesn't lead to more rounding error glitches. Quite the opposite, something like the Elite's Cobra engine runs smooth on a whole galaxy scale.

Additionally Roberts despite pretending to be a programmer, is incompetent enough, so he can't actually verify if he has a game engine with 64 bit precision. And with all the yes men he surrounded himself with no one will tell him the truth.

Now I know I cannot take you seriously.... You may want to read up on the difference between 32-bit (what Elite use to run on) and 64-bit floating point. Might also want to read up on system architecture and see how a CPU actually processes floating point calculations. Here are some helpful links (https://en.wikipedia.org/wiki/Single-precision_floating-point_format, https://en.wikipedia.org/wiki/Double-precision_floating-point_format, https://drive.google.com/file/d/0ByTCklEz_vkdcEtHdnBXVi1SaVU/view?usp=sharing)
 
Now I know I cannot take you seriously.... You may want to read up on the difference between 32-bit (what Elite use to run on) and 64-bit floating point. Might also want to read up on system architecture and see how a CPU actually processes floating point calculations.
Why can't you take him seriously? And why would he want to read up on floats and doubles? Nothing he said on that topic was in any way wrong, after all.

Oh, and let's not forget
Ben Parry said:
Added to that - regardless of 64 or 32 bit compilation, all the heavy vector maths work is done in 128-bit SIMD, so you get good performance on 2D vectors at either precision, and good performance on 3D and 4D vectors only at 32-bit.
 
It's not really destroyed, though. In part because it doesn't actually disprove or even dispute the theory, but mostly because that line of reasoning looks at the wrong end of the maths.

It's not the upper bound that is a problem if you scale things down, but the lower bound. Scaling your system down by a factor of 20 million means you've lost a whole lot of precision — and it's that lower-end precision that would come into play with many of the issues that we see with SC.
Sorry, the point I'm trying to make is that whichever end of the number range you're at, you get the same number of bits dedicated to relative precision. There are almost no numbers involved that go anywhere near the highest or lowest exponent, so adding a scale multiplier would not gain or lose you anything.

<cough> technically an FPU handles those - even though they are now baked into the same silicon.

I remember saving up for an i387 :D

<cough> technically it's the SIMD unit that does that these day, old man ;)
 
Sorry, the point I'm trying to make is that whichever end of the number range you're at, you get the same number of bits dedicated to relative precision. There are almost no numbers involved that go anywhere near the highest or lowest exponent, so adding a scale multiplier would not gain or lose you anything.

Was actually going to comment about something similar but you beat me to it [up]
 
Sorry, the point I'm trying to make is that whichever end of the number range you're at, you get the same number of bits dedicated to relative precision. There are almost no numbers involved that go anywhere near the highest or lowest exponent, so adding a scale multiplier would not gain or lose you anything.
Fair enough as far as the maths go, but you're still running the risk that something, somewhere, will do something stupid where that massively scaled-down number will start to chafe against the lower limits of precision. If you have full control of every part of the code, you can just avoid that or at least keep track of it, but that's pretty rare in this era of middleware and special-purpose hardware.

Regardless of the actual code and the myriad of more or less sensible solutions to the problem of having huge play areas, though, many of the more persistent and funny bugs in SC do curiously correspond to the kinds of issues you'd run into with bad world scaling.


Star Citizen: So Big it's Tiny
Nah. Just deliberately small. This isn't a bad thing, but it really annoys a lot of people when they're faced with the fact that SC somehow isn't “the X:est thing ever” in some particular era, irrespective of how well it works in the game's favour not to try to push that particular envelope. ;)
 
Last edited:
Status
Thread Closed: Not open for further replies.
Back
Top Bottom