Is it that during compilation, the compiler tries to compress and optimize the code in such a way that it “grows roots” into the assets (or vice versa) that if the asset is removed without proper care, the whole thing will collapse into itself? Like, the compiler realized that part of the binary code in one part of the program coincidentally is the same as a snippet of binary code in a nearby asset, so it chops code out to save space?
In: 0
There’s no single cause for this, because if there was, a solution to avoid it would have been found by now.
Generally, a program can be thought of as a hilariously complex list of instructions that the computer repeatedly goes through. In the ideal world, every instruction on the list would be preceded by instructions that do everything required for that instruction to work correctly. Programs are made by human beings though, and so are inevitably flawed in one way or another.
Maybe the programmer forgot a particular instruction that another instruction depends on, but it works anyway because coincidentally another programmer put the forgotten instruction in an earlier part of the list for totally unrelated reasons. Or maybe it used to be in both places, but a third programmer tried to speed up the program by making the list smaller and realised that it didn’t crash when he removed the instruction from the second part. In both cases the program now contains two parts that are both dependent on an instruction being run in the first part. If you swap the order the parts are being done in, or remove the first part entirely, the instruction in the latter part will now fail.
The same can hold true for assets, if the program is not very good at managing them. Maybe it assumes that something in particular it needs is located in Memory at a certain point from the start of the program’s memory allocation, because the preceding parts of it were always filled with assets of a fixed size by the point it got to that instruction. Remove one of those assets and everything is suddenly shifted around in ways that the code did not expect.
These are just some abstract examples. There are countless specific ways that removing seemingly inconsequential bits of complex programs can cause problems.
Latest Answers