Note that this is speculation, but it's pretty reasonable and makes a lot of sense. It doesn't explain why only some people experience this, but there you go.
Either by design or by accident, some of the assertions in HZD were left on in the PC port, and that's why the game crashes. But they usually get turned off before you actually ship the product. If they aren't true, the program crashes so the dev can take a look at what was happening internally right before the badness. These are commands added to a program to help developers check that assumptions they're making are true. What's probably happening here is that these instructions are part of some assertions left in the code by the developers. For those of you who don't program at all, this is an instruction that will crash a program immediately when executed (on most modern x86 architectures). What instruction were we nopping out? I pulled out my handy disassembler and got this result:Ġx0000000000000000: C7 04 25 00 00 00 00 A7 DC EA 0D mov dword ptr, 0xdeadca7įor those of you who speak C but not assembly, that translates to *0 = 0xDEADCA7.
It's a series of no-op instructions that the processor basically just skips over. is what's know in computer science as a nop slide. I was extremely skeptical of this, until I saw what we were changing the bytes into. I then saw someone suggest a fix that struck me as rather outlandish for a video game crash bug: open up the exe file in a hex editor, and replace some bytes in the raw game code with different values. Stopping every 5-25 minutes to restart the game is not great for immersion. I suffered through them for a few hours because the game was so beautiful and fun, but the constant interruptions were really killing the buzz for me. Hey all! Many of you, like me, have experienced frequent crashes in HZD.
0 kommentar(er)
