31–40 of 88 posts
Insanity. The values were just right. Just wow.
It's a goal of mine to get Valve using Nix. (I hope our in-progress Windows support would make this especially compelling.) One advantage of this is that it will become very easy to not only build the original source of the game, but also build it with the original toolchain and dependencies, the toolchains for those dependencies, etc. etc., all the way down. Hopefully something like that at your finger trips would h…
They’re using Arch Linux. Let’s call it a win and move on lol.
>a big innovation of HL2 was the extensive use of a real physics engine. The door and the guard are both physical objects, both have momentum, they impart an impulse on each other, and although the door hinge is frictionless, the guard's boots have some amount of friction with the floor. It's been a while since I've played HL2 but this isn't exactly how I remember it. While a lot of things were physics objects I thou…
I stuck a tire in a door frame and tried to close it, the tire emitted a bunch of dust clouds as the two objects fought before the door finally ejected the tire at high speed.
I wonder how on earth stuff like x86->ARM translation works so well if games break even after switching from x87 registers to SSE preserving all the logic otherwise...
Rosetta uses software emulation for x87 floating point. That's slow, but in practice that doesn't matter much. Mac software never had a reason to use x87 FP, every Intel Mac had at least SSE3 support.
long double x87me(long double a, long double b) {
return a+b;
}
pushq %rbp
movq %rsp, %rbp
fldt 32(%rbp)
fldt 16(%rbp)
faddp %st(1)
popq %rbp
retq> The door and the guard are both physical objects, both have momentum, they impart an impulse on each other I wonder if the term "impulse" here has any connection to the various impulse commands available in the source engine. I remember using "impulse 101" and causing havok in the opening plaza area. Spawning zombies on the roofs, sending them after the combine, etc. https://developer.valvesoftware.com/wiki/Impulse
This reminds me of an old bug in simdjson - any usage of it breaks std::unordered_map in unrelated parts of the code due to an unintentional modification of FPU flags: https://github.com/simdjson/simdjson/issues/169
It seems to be typical - some calculations break while switching from x87 to SSE. The same happened with TF2 too - it's ammo calculation code worked slightly differently on GNU/Linux build of the game, because it was built with SSE instructions (Windows version still used x87).
I’m surprised to hear the ammo calculation code would use floats.
Earlier quoted context omitted.
I’m surprised to hear the ammo calculation code would use floats.
The game has ammo pickups that refill 20% and 50% of whatever your max ammo is, so floats have to be involved in there somewhere.
I wonder how on earth stuff like x86->ARM translation works so well if games break even after switching from x87 registers to SSE preserving all the logic otherwise...
I think x87 fpu is the only 'weird' floating point units left. I think if you stick with 64-bit double precision floats or 32-bit single precision floats, where the registers are also 64 or 32 bits, all the modern stuff behaves the same. x87 is just weird because registers are 80-bits ... the idea was to have more accurate results from more precision, but it ends up weird because if you run out of registers and have…