HN user

mackman

917 karma
Posts0
Comments121
View on HN
No posts found.

The other interesting trick is you need a separate RNG for visual only affects such as particles than the one you use for the physics simulation. Depending on the game during replays, you could position the camera differently and then particle effects would render differently depend, depending on what’s on screen. Obviously that shouldn’t affect the way objects decide to break during the physics simulation.

One of the hardest determinism bugs I had to solve on the PlayStation three was that the PPU and the SPU actually used a different instruction set and had a different internal floating point register size. We had a multi threaded physics simulation, and during instant replay, we had to ensure that the job scheduler sent the exact same work to the correct cores or we got back subtly different floating point values, which of course, immediately caused major divergences.

Instant replays that require long-term deterministic behavior have to be bit perfect in a way that is dramatically hard harder to implement if trying to also do network synchronization. The hard parts of each of those is fundamentally different and trying to do them at the same time terrifies me. I have shipped console games doing both (independently) and was responsible for de-bugging determinism.

I was down there recently on a helicopter-based expedition and they set up a forward base of operations with a few days of emergency rations in case of unexpected weather that prevents you from returning to ship. I asked them what happens if the blizzard lasts more than a couple of days. Someone somewhere has a recipe book for penguins.

As best I can tell we've never sold the same product twice. Product roadmap is "whatever the last person I spoke to asked for." And tech debt maintaining a grab bag of 5,000 almost-but-not-quite-entirely-production-grade "must have" features that the customers rarely if ever use despite claiming that not having it was a deal breaker, is, well, debty.

It is possible to create threads by using the OS syscalls bypassing completely the requirement of pthead. (Un)fortunately, I couldn’t find any popular libraries that implement the functionality by using the syscall interface instead of relying on pthread.

I have tried and failed to do this for a C++ program because the amount of C++ runtime static init/shutdown stuff you would need to deal with isn't practical to implement yourself.

CORE only works on kernels that support BTF. This post introduces one workaround which is to generate BTF data for kernels without it. That's still only half the problem though. You also need to write your eBPF program so every kernel verifier passes it, even though every kernel's eBPF verifier has different bugs, capabilities, and complexity limits. I maintain a large eBPF program that supports 4.14 through 6.14. We implemented our own version of CORE before CORE really existed. In reality, it's a lot more work than "compile once run everywhere."

As someone who studied physics and electronics for many years, I still appreciate an article like this for reminding me how profoundly weird science is. Working day to day with the equations and practical applications of electricity gives you a false sense of confidence that we actually have any fucking clue what’s going on.

The physics game sim step had to be hardcoded but you could vary the graphics rendering independently. That did mean you needed to use a different RNG for sim objects and graphics-only particle effects.

I worked on the deterministic instant-replay system for a racing sim on PS3. The most interesting thing was that on PS3 we had main processor cores (PPU) and helper cores (SPU) which had their own instruction set. Our physics sim could distribute work across both, but the thread assignment had to be deterministic because PPU and SPU got marginally different floating point results for the same instructuion and inputs. That was a fun one to figure out!

I implemented a debug replay system for an American Football game when I worked at Sony. The AI hierarchy and all animation and physics state was recorded and game could be rewound to figure out why an NPC made a poor decision. Only needed to track state for the duration of a single play. This was on PS2 which I think had 32MB of memory but the dev systems had an extra 96MB which we could use for this sort of thing.

I loved working on the cell. I remember writing my first spu code when the ps3 dev kit was a huge stainless steel box. I later went in to implement predictive physics for racing line optimization for midnight club on the spus. Was a lot of fun. Weird thing was the floating point unit had a different intermediate bit size than the ppu so for deterministic results you had to schedule threads to always be dispatched to ppu or spu deterministically. That was essential for network games where the sim had to run bit for bit the same across players.

In general images are often limited by depth of field, camera movement, subject movement or lens resolving power. Some of these can be improved upon with better software. I have been working on software to do this myself as for fun. For the rest of this, though, there are other techniques that will work better than pixel shift.