About those Star Citizen 2.0 jittering & crashes...
This is no doubt going to upset a lot of people. But fuck it, I'm an engineer.
I was going to hold off until I finished my research, but the jittering people are seeing, are specifically the sort of problem that going to full bore 64-Bit addressing was supposed to solve.
The fact that it's [b]still[/b] happening, when you move too far from an origin (e.g. planet, base, any object) in this v2.0 release, leads me to believe that they've probably done what I did back in the day.
As I tweeted this morning, this is done by going the (32-bit * 2) route, whereby you use a 32-Bit positional reference for that fixed object, then treat the player position as a 32-Bit value by using that fixed object as a reference.
It's messy. It's rudimentary. OMG! And it can/will break [b]everything[/b]. And some of these out-of-nowhere-in-space crashes people are getting are the very symptoms you should expect.
That's why I abandoned it and went pure 64-Bit positional referencing. From my code review that I checked this morning, I did that back in 2000 for Battlecruiser Millennium which was the sequel to the original Battlecruiser 3000AD (two releases in 1996, 1999).
But it can work - depending on what you want to do. And if they had to do this, it all goes back to the core of the CryEngine3 code base because even with a custom engine, you are still at the mercy of the underlying architecture. And going as deep as I think they are doing now, you may as well just write your own engine from day one. That's how serious this problem is and is precisely what sparked my first blog back in July when I saw it mentioned in one of their dev updates.
A contact of mine was actually the first one to bring it to my attention this morning when he messaged me on Facebook. In our discussion, I refused to even believe that they would do that. Aside from the obvious implications (misleading the fan base, making false statements etc), it would most definitely mean that they simply - cannot - build the game at the world scope promised. I also told him that I can't imagine any of those engineers doing anything (lying intentionally) of the sort. That being, touting full bore 64-Bit addressing, then actually going with what amounts to a glorified (and expensive, complicated) hack.
I then checked their latest dev blogs, went back and re-read the previous ones; and didn't see any indication whereby they made any mention of doing this "hack".
And they MAY have done it if they felt that it would get them SOMETHING sooner, rather than later. Then maybe fix it down the road. In other words, it's a quick fix to a very serious problem. And it would make sense as long as SQ42 doesn't actually take place in the full game world that has this size/position problem. Since nobody (at least to my knowledge) yet knows what section of the game world SQ42 actually takes place in, it would stand to reason that if they are trying to get SQ42 out ahead of Star Citizen in 2016, then it would be in their best interest to do this hack in the short-term, get SQ42 out, then go back and do it properly.
Which goes back to what I said earlier that the v2.0 branch they are now merging from and which will ultimately deprecate the current v1.0x, is going to be in the same sordid state as that v1.0x, for months to come.
I will know more once I get to dig into the game files with the help of some people I know; but this is the sort of technical shit that interests me. And if it reveals - yet again - that we're dealing with a bunch of lying scumbags - nothing will give me more pleasure that to force them to come clean. Again. Bear in mind that I have nothing but the utmost respect for the truly talented engineers who are tasked with pulling off this "vision 2.0" pipe-dream. Sadly, they're caught in the middle of this shit and are the casualties of a war that's going to be waging until one of two things happens: 1) they fail and fold 2) they succeed and deliver the game Chris promised