Explaining the Pink Soup (In Layman's Terms)
Hi everyone!
First off, I just wanted to say thank you for all of the positive feedback I've received over the past few days — I'm really pleased to see that my mod seems to have been effective for so many of you!
I am aware that my dissertation/thesis is really rather technical, filled with lots of academic/flowery language, and probably quite overwhelming to try and understand if you're lucky enough to have not studied computer science, so I wanted to attempt to break the key parts of it down into the simplest terms possible, to hopefully help answer some of the questions I've seen people have.
What is the pink soup?
The pink/purple strobe lighting we all know and love is 1 of 4 uniquely coloured shaders the game uses to indicate a specific type of error has occurred when trying to display something on-screen. The 3 other colours it uses (you've likely seen at least one of them) are red, blue, and yellow.
These shaders serve two main purposes:
To let you know something has gone wrong in an obvious (albeit obnoxious) manner.
To allow the game to keep running in spite of whatever error has happened (otherwise it would just crash).
Internally, the error that the pink soup represents is known as a "material parsing failure", i.e. the game has failed to understand some piece of material data (textures, rendering properties etc.) about an object it is trying to render.
Part of the process the game goes through before rendering an object to the screen is checking that its data only contains specific characters (numbers, letters, and certain symbols) — an example of when this would fail and trigger the pink soup would be if the game came across a random emoji during these checks.
What does 32-bit/64-bit mean?
A 'bit' is just a single digit of a binary number. All you really need to know is that a 32-bit number is a binary number that is 32 digits (bits) long, with the largest binary number possible being 32 consecutive 1s (1111111…).
I'm not going to bore you to death and show you how to convert binary numbers to decimal, so you'll just have to believe me when I say that 32 consecutive 1s in binary is equivalent to 4,294,967,295 in decimal.
4.2 billion might seem like a pretty high value to be able to represent, but if I said this is roughly equal to 4GB, you might be able to start to see how 32-bit computers/software could be a bit (no pun intended) limited memory-wise. For comparison, the largest decimal value a 64-bit binary number can represent is 18,446,744,073,709,551,615, or just under 18.5 exabytes (EB)!
But what if I wanted to represent the number 5 billion in 32-bit binary? Here's the fun thing — you can't. If you tried, the binary number would 'wrap around'. As in, it would max out at 32 consecutive 1s before resetting back to 0 and continuing to count up until it reached the binary value of 705,032,705 (5,000,000,000 - 4,294,967,295 = 705,032,705).
This is what is meant when we say that The Sims 2 can only use up to 4GB of your computer's memory (RAM) — it is physically unable to access/store data in more than 4,294,967,296 different memory addresses (it's 4,294,967,296 because the range of possible addresses would be 0 to 4,294,967,295).
If you're not sure what I mean when I talk about 'memory addresses', you can think of the concept as being like your home address (your house number, street name, and postal/zip code). It's just the location a piece of data lives at in memory so the game knows where to find it if it needs to use it for something.
Once the game has run out of memory addresses to use to store things, it will crash. The only way this could be fixed would be if EA magically decided to rewrite the game's engine to be 64-bit, thus allowing it to use an exponentially larger number of addresses.
Why does the pink soup happen?
This is where things get interesting. While the game is loading, the material data for the objects in your neighbourhood/lot is stored at individual addresses in your computer's memory so it can be processed.
Part of this processing involves the game taking all of the shader code found in the Materials.package file and linking the relevant shaders to the relevant pieces of material data of an object (e.g. a reflection shader would be linked to the glass part of a mirror object), creating shader 'packages' for the whole object. Again, both these packages and the information that links them to the object are also stored in memory.
As you can probably imagine, if you have a large number of different objects in your hood/lot (particularly more complex/detailed objects with many rendering properties), the amount of free memory the game has to use to keep storing things starts to decrease FAST.
Back in ye olden days of 2004 when The Sims 2 was released, 32-bit was the most commonly used architecture for consumer-grade hardware and software. Despite its known drawbacks, the 4GB memory restriction was not really a huge issue, as the technical limitations of the time meant your parents' PC would likely catch fire and explode long before this level of memory usage could be reached in-game.
Windows XP (the operating system the game was primarily developed for) was also a 32-bit operating system. The way XP handled the 4GB memory limit was simple:
2GB was given to the kernel (the core of the operating system).
2GB was given to applications (i.e. The Sims 2).
This is why it is commonly recommended to apply what is known as a '4GB patch' to the game, as by default, it still thinks it's living in 2004 and is only allowed to use 2GB of memory — the 4GB patch therefore permits the game to use the full 4GB of memory it is able to support.
So, where does the pink soup come in to this?
Basically, there is a piece of logic within the game's code that is used during the process of linking shaders to material data described above. All this logic does is check whether the material data it is being given is stored at a memory address above or below the 2GB mark, presumably some kind of relic of the Windows XP days.
For whatever reason (either due to a bug or intentional design), for data stored above 2GB, the game performs additional checks which will ALWAYS FAIL, and the game will treat this data as being malformed/invalid, refusing to link any shaders to it.
Hopefully, the chain of causality should now be clear:
The capabilities of our hardware has increased dramatically in the past 20+ years.
We've all been applying a 4GB patch to the game to allow it to make use of more of our RAM.
We've also all been installing a load of cool custom content and creating highly decorated hoods/lots because our fancy graphics cards can handle them easily.
All of these objects are causing memory usage to quickly surpass the originally intended 2GB range.
The game is considering any data for the objects stored above this range to be invalid and refusing to do anything with it.
The pink/purple error shader is instead being applied to these objects because the game thinks there is something wrong with their material data.
In conclusion, The Sims 2 is confused and elderly, frequently soiling itself when presented with high-tech information from the far off future of the 2020s that its puny 2004 mind can't possibly comprehend.
What are the differences between v1/v2 of the mod?
Both versions of the mod patch the same piece of logic in the game's code, but with differing approaches.
With v1, the additional (and always failing) checks the game performs on material data stored above the 2GB mark are essentially patched out, meaning they are not executed and shaders will always be correctly linked to them, regardless of their location in memory. This is great, as you should never see any pink soup that would usually be triggered by these failed checks. Consequently however, the game will give you no indication that it is running out of memory, except for when it inevitably crashes once all free memory has been used up.
On the other hand, v2 makes use of these faulty checks. Instead of removing them completely, they are repurposed to warn you of high memory usage, with the game not performing these checks until material data starts being stored above the 3.5GB mark. This means you will still see pink soup, but only once memory usage exceeds 3.5GB. This is intentional, and is meant to be a trade-off between allowing the game to correctly process more data in memory, but also still letting you know that a crash may be imminent some time after the pink soup appears, giving you enough breathing room to save and restart the game before this happens.
To illustrate these differences better, here is roughly what the code is doing in the vanilla game, v1, and v2 of the mod:
Vanilla:
if memory address <= 2GB everything is fine, continue as usual if memory address > 2GB pink soup time!
V1:
if memory address <= 2GB everything is fine, continue as usual if memory address > 2GB everything is fine, continue as usual
V2:
if memory address <= 3.5GB everything is fine, continue as usual if memory address > 3.5GB pink soup time!
Which version should I choose?
There's no correct option, but if you play with a lot of CC or with highly decorated hoods/lots, I would probably recommend starting with v2, only for the so-called 'safety' reasons I outlined above.
I personally use v1 because I play very vanilla, so I know memory usage should never really get that high. If you're like me, or you just don't care about potential crashes and want to be rid of the pink soup, then v1 of the mod is the one for you :)
I know people likely still have many questions, so I've enabled the 'Ask me anything' option on this blog - feel free to use it!
Thanks again,
Will
