Ok, disclaimer first: it's Friday, I've had a few, I'm going to try to minimise the drunken tangentrambles but who knows.
Rightso...
Right. However, I still stand by my original claim because i) you - or any dev - has yet to disprove, let alone explain it
And it's your gods-given right to claim it. No one can take that away from you. You're wrong, though. You seem hooked on this idea of maps, scenes, whatever you want to call them, with edges that a player has to cross. I feel like you keep trying to find ways I've said that's true, when I've said the opposite.
That's just the same nonsense that's going on whereby - for some reason - backers who are adept at theory-crafting dreams, can't tell the difference between 64-Bit sized scenes, 64-Bit programs, 64-Bit world positioning.
For (2) and (3), check my posting history on here before I became a Foundryman, ED fans had some inexplicable mental block on it too, I tried to explain them a thing, we end up with Adept thinking ED does things in 128-bit instead. For (1) vs (3),
I actually have no idea what your definition of a "64 bit sized scene" is, I can't understand how it's not the same as (3), but you keep not defining it. Your use of terminology is frequently non-standard, this might be why you keep accusing me of obfuscating when I'm trying to be as clear as possible.
Yet somehow, backers are sitting around thinking that at some moment in time, they're going to be flying around a game scene in space - with no restrictions - and be able to manually fly to, enter a planet, and do it all in reverse.
Yes. Right here.
This is the thing I'm saying is the case. If you're not talking about demand-loading, or network LoD stuff, this is absolutely the thing. Each star system will probably be its own world, obviously, but within the star system, the thing you said there is true.
The thing where you pick a specific target point is a design decision, I think. But to be totally clear, your destination point is just some coordinates (in 64 bit, yes) you just move over there really fast. I can't disprove this idea that there's a new "scene" or whatever, with words, how could I? Sufficiently advanced fakery is indistinguishable from just doing the thing. But really complicated fakery would have been exciting and AtV would have just done a show about
that instead.
Hi Ben
Please can you elaborate on what your mean by "fanatical devotion to the coding standard"? What does this refer to?
Thanks!
Too late. The very statement "
fanatical devotion to the coding standard" is already problematic because, by its very nature, SSE has absolutely
nothing to do with "coding standards". So I'm guessing that Ben probably meant something else. We just have to wait and see, when he comes back.
ps:
quick primer
Oh dang, you got me. I must have been obfuscating, to... say... positive things about Frontier? Let's see if I can unpack what I said to a level that you get it.
First off, just so I don't get some "aha! SSE only exists on PC" type gotcha-ing, I'm going to start saying SIMD (single instruction, multiple data). SSE is a kind of SIMD, there's a newer PC one called AVX, on the 360 it was Altivec... all variants of the same idea - several numbers side by side in one wide register, and you can do the same operation on all of them in a single instruction.
What Derek's link above doesn't mention is that you tend to wrap all these weird types and unpronouncable intrinsics into a more user friendly, multi-platform friendly container, so if you need to, say, get the Y component out of it, you call a thing called "GetY" and it gives you the right thing. What it's doing at a hardware level, though, is shuffling the components around so Y is at the start, or is all of them, and it's taken a whole operation that could have done four of something else.
So how does a coding standard matter for this? Well, take these two apparently identical operations (yeah someone probably wouldn't do exactly this, but hopefully you see the point):
Code:
1) Vec C = A + B
2) Vec C = Vec( A.GetX + B.GetX, A.GetY + B.GetY, A.GetZ + B.GetZ)
Option 1 is one operation. Option 2 takes six swizzles, three adds, and maybe some more swizzles and masks packing them together at the end. It's also the kind of code that's easier to write when you're trying to think about a problem rather than ideal vectorisation. This is where I talk about fanaticism, and where Frontier shines, IMO, because not only did they design a really idiot-proof vector library, but they have a general attitude that if you try to work around the interface design and start writing sloppy code, someone comes to your desk and kicks your butt for it. This kind of sloppiness naturally creeps in, but Frontier's general culture is one where you get called out even on apparently harmless deviations from the standard, so the standard stays strong. So there you go - fanatical cleanliness, miles of well-build explicitly 32-bit SIMD code, well worth sticking in 32-bit and working around the pain it causes.
So CryTek didn't do the things above. Obviously they've put out some groundbreaking tech over the years, but "fanatical cleanliness" isn't exactly their watchword. Watchphrase. I asked a guy who used to work there why there wasn't an explicit SIMD vector library like wot I was used to, and he said they'd trialled one, but because the original interface had funnelled people into Option 2 style code instead of Option 1, it actually ran much slower and they abandoned it. Modern compilers are still smart enough, though, that if it can work out what you're doing - do four adds in roughly the same place, say - it'll try to reorder the instructions so they were already side-by-side, and so on. In many cases it'll probably even out-perform because it saw stuff you didn't, and switching to 64-bit probably breaks a few less things.
Now for the hedge - this started as an off-the-cuff comment. I've not profiled either codebase at either precision, I'm not even sure
how you'd test them side by side. Don't trust anyone who claims to be certain when they don't have the profile data to back it up.
So yeah, Regel, I hope that answered your question. dsmart, I hope I've not walked into some quibble about your precise definition of "coding standard". Jools, I hope I didn't arm anyone. Frontier, you're only fanatics in a good way, mostly.
