I just want clarification because I am constantly getting error code 12 and it's driving me crazy. I have even started playing The Sims 4 to prepare myself to move on. I still think about The Sims 3 because it feels more complete and whenever I play The Sims 4 something is missing. I know The Sims 3 is a 32 bit application so it only uses up to 3.7MB of ram and there is no way to successfully force more ram onto it. I love to play in huge worlds, I have lots of cc and mods, and I enjoy a decently big population (100 or more).
I am fully aware the game doesn't like all of that pressure which pushes it over the edge, but I notice something different. Years ago, when I was playing The Sims 3 on a low end, Windows 8.1, HP laptop no matter what I threw at the game it NEVER crashed. The most it ever did was lag a ton. I would say that I downloaded a lot more crap back then, but it seems to be catching up to me on newer systems. I can't for the life of me figure out which mod is crashing my game because I checked and nothing is conflicting.
I watched a video from a YouTuber/Simmer called Simphora - https://youtu.be/tNOB3Bw3kpE?si=krbjZ07y3VVq1Ym8
At some point in her video she said that she followed optimization guides which instructed to increase your seti texture memory in your graphics rules file. For her, it resulted in more frequent crashing and it's about time we all debunk that tip. It was recommended because it's somehow a part of getting your game to recognize your graphics card, but nobody was able to explain in detail the purpose. I also was one of those people to follow the tip, but what difference does it really make? I never did this in the past and my game was just fine.
I have my seti texute memory set to 2048 and my graphics card has 8gb of vram. Is my gameplay really the problem or is it blindly following optimization guides? Or... Is it Windows 10 and newer technology today no longer supporting older games? Should I just put my seti texture memory back down to 32? Have any of you noticed a difference either way?
Game Performance Seti Texture Memory
-
puzzlezaddict
- Reactions:
- Posts: 1257
- Joined: June 22nd, 2018, 6:00 pm
Seti Texture Memory
The value you're asking about is part of a block of code:
if ($textureMemory == 0)
seti textureMemory 32
setb textureMemorySizeOK false
that starts with "if the VRAM value of this GPU equals zero," which also applies to "if the game cannot detect this GPU's VRAM." In these cases, the game defines the "texture memory" (VRAM) as 32 MB (line 2) and notes that the value is an override of the actual value (step 3). Using the 32 MB value also has the effect of setting the GPU Memory rating, as shown in DeviceConfig, to the minimum. None of this is relevant if your graphics card's VRAM is already properly recognized; in that case, these lines wouldn't be used at all.
If this affects any in-game graphics settings, which I'm not completely sure it does (I'd need to test again), you could of course change them. But the bigger question is whether the game engine artificially limits the graphics-related data in response to thinking the GPU's VRAM is so low. In that case, graphics-related performance would take a noticeable hit—fewer textures held in video memory would mean more delays in rendering new objects on-screen, and perhaps trouble rendering even the active lot.
I haven't tested VRAM use when the texture memory value is set to 32. I can tell you that when the value is set to 2048 or higher, the game still uses only 800 MB of video memory. If you're curious, I can do more benchmarking, but I don't currently have a save that uses > 3 GB RAM to do any tests related to that. If you know of a world that uses that much memory, or close to it, on startup, please list it and I'll check it out.
As far as why you're getting crashes when you never did on your old system, there are too many variables to account for. Maybe you didn't use overly-complicated worlds back then, maybe your overall playstyle was somewhat different, maybe you were using graphics settings that used less RAM... it's impossible to say without a side-by-side comparison. But the first question for you now is how much RAM, not video memory but physical memory, Sims 3 is using when it's about to Error 12.
It's also worth noting that Error 12 is an out of resources condition, usually but not always tied to RAM. The game can throw the error when it runs out of a different resource, e.g. VRAM, as well.
if ($textureMemory == 0)
seti textureMemory 32
setb textureMemorySizeOK false
that starts with "if the VRAM value of this GPU equals zero," which also applies to "if the game cannot detect this GPU's VRAM." In these cases, the game defines the "texture memory" (VRAM) as 32 MB (line 2) and notes that the value is an override of the actual value (step 3). Using the 32 MB value also has the effect of setting the GPU Memory rating, as shown in DeviceConfig, to the minimum. None of this is relevant if your graphics card's VRAM is already properly recognized; in that case, these lines wouldn't be used at all.
If this affects any in-game graphics settings, which I'm not completely sure it does (I'd need to test again), you could of course change them. But the bigger question is whether the game engine artificially limits the graphics-related data in response to thinking the GPU's VRAM is so low. In that case, graphics-related performance would take a noticeable hit—fewer textures held in video memory would mean more delays in rendering new objects on-screen, and perhaps trouble rendering even the active lot.
I haven't tested VRAM use when the texture memory value is set to 32. I can tell you that when the value is set to 2048 or higher, the game still uses only 800 MB of video memory. If you're curious, I can do more benchmarking, but I don't currently have a save that uses > 3 GB RAM to do any tests related to that. If you know of a world that uses that much memory, or close to it, on startup, please list it and I'll check it out.
As far as why you're getting crashes when you never did on your old system, there are too many variables to account for. Maybe you didn't use overly-complicated worlds back then, maybe your overall playstyle was somewhat different, maybe you were using graphics settings that used less RAM... it's impossible to say without a side-by-side comparison. But the first question for you now is how much RAM, not video memory but physical memory, Sims 3 is using when it's about to Error 12.
It's also worth noting that Error 12 is an out of resources condition, usually but not always tied to RAM. The game can throw the error when it runs out of a different resource, e.g. VRAM, as well.
Seti Texture Memory
I play in a new world called Pottersville and the game throws error code 12 at, I think, 3.5mb. It doesn't take long for the game to reach that, but I don't keep track of the time. Maybe 20 to 30 minutes in. I am thinking about moving to another, smaller world.puzzlezaddict wrote: ↑September 25th, 2023, 7:10 pmThe value you're asking about is part of a block of code:
if ($textureMemory == 0)
seti textureMemory 32
setb textureMemorySizeOK false
that starts with "if the VRAM value of this GPU equals zero," which also applies to "if the game cannot detect this GPU's VRAM." In these cases, the game defines the "texture memory" (VRAM) as 32 MB (line 2) and notes that the value is an override of the actual value (step 3). Using the 32 MB value also has the effect of setting the GPU Memory rating, as shown in DeviceConfig, to the minimum. None of this is relevant if your graphics card's VRAM is already properly recognized; in that case, these lines wouldn't be used at all.
If this affects any in-game graphics settings, which I'm not completely sure it does (I'd need to test again), you could of course change them. But the bigger question is whether the game engine artificially limits the graphics-related data in response to thinking the GPU's VRAM is so low. In that case, graphics-related performance would take a noticeable hit—fewer textures held in video memory would mean more delays in rendering new objects on-screen, and perhaps trouble rendering even the active lot.
I haven't tested VRAM use when the texture memory value is set to 32. I can tell you that when the value is set to 2048 or higher, the game still uses only 800 MB of video memory. If you're curious, I can do more benchmarking, but I don't currently have a save that uses > 3 GB RAM to do any tests related to that. If you know of a world that uses that much memory, or close to it, on startup, please list it and I'll check it out.
As far as why you're getting crashes when you never did on your old system, there are too many variables to account for. Maybe you didn't use overly-complicated worlds back then, maybe your overall playstyle was somewhat different, maybe you were using graphics settings that used less RAM... it's impossible to say without a side-by-side comparison. But the first question for you now is how much RAM, not video memory but physical memory, Sims 3 is using when it's about to Error 12.
It's also worth noting that Error 12 is an out of resources condition, usually but not always tied to RAM. The game can throw the error when it runs out of a different resource, e.g. VRAM, as well.
-
CardinalSims
- Reactions:
- Posts: 576
- Joined: May 12th, 2021, 3:12 am
Seti Texture Memory
Modifying some of the more hidden properties of the game can be a great way of testing the limits and tapping into some leftover potential as far as new hardware is concerned. I don't think it's blind trust that is the issue (sometimes people discover cool and untested things!) but rather that it's just bad practice to apply a bunch of experimental things to a new install of the game on a new system before being familiar with your own hardware quirks. That's just kind of setting yourself up to be splitting hairs over not knowing what the game is possibly up to anymore.
Reaching the point of not actually knowing whether a bunch of miscellaneous tweaks are even related to game breaking issues sounds like the time to roll things back to vanilla
That doesn't mean these tweaks won't have value to you in the future, but their existence and co-existence with however many other variables is just not helping you right now.
I have a lot of old tweaks in my game that could very well have become redundant over the years, but I put them in place in order to solve problems- not before I knew of any problems that needed solving. In this way, even if it's been so long that I don't recall what all of them were for anymore- I know that I put them in for a reason and the desired effect was achieved. If I ever get a new computer, I wouldn't copy these changes verbatim because I would no longer have that understanding that it would be doing any good at all.
Then later on, regardless of how split opinions are over what something does or doesn't do, you can have a go at introducing it to your game. It's fun to tinker with that kind of stuff and make it your own, just requires a bit of patience.
I'd say the one change worth always applying is getting the graphics card recognised, as the game will never quite gel with modern cards without it. If this is done properly there is no need to touch that bit about texture memory, this covers it pretty well. (I've made changes to the non-'if' texture memory section further down from the code mentioned above, but again- it's likely something I did in 2019 and could no longer tell you why or what it solved.)
Reaching the point of not actually knowing whether a bunch of miscellaneous tweaks are even related to game breaking issues sounds like the time to roll things back to vanilla
That doesn't mean these tweaks won't have value to you in the future, but their existence and co-existence with however many other variables is just not helping you right now.I have a lot of old tweaks in my game that could very well have become redundant over the years, but I put them in place in order to solve problems- not before I knew of any problems that needed solving. In this way, even if it's been so long that I don't recall what all of them were for anymore- I know that I put them in for a reason and the desired effect was achieved. If I ever get a new computer, I wouldn't copy these changes verbatim because I would no longer have that understanding that it would be doing any good at all.
Then later on, regardless of how split opinions are over what something does or doesn't do, you can have a go at introducing it to your game. It's fun to tinker with that kind of stuff and make it your own, just requires a bit of patience.
I'd say the one change worth always applying is getting the graphics card recognised, as the game will never quite gel with modern cards without it. If this is done properly there is no need to touch that bit about texture memory, this covers it pretty well. (I've made changes to the non-'if' texture memory section further down from the code mentioned above, but again- it's likely something I did in 2019 and could no longer tell you why or what it solved.)
-
puzzlezaddict
- Reactions:
- Posts: 1257
- Joined: June 22nd, 2018, 6:00 pm
Seti Texture Memory
.Isisj18 wrote: ↑September 25th, 2023, 7:35 pmI play in a new world called Pottersville and the game throws error code 12 at, I think, 3.5mb. It doesn't take long for the game to reach that, but I don't keep track of the time. Maybe 20 to 30 minutes in. I am thinking about moving to another, smaller world.
Memory use around 3.5 GB is already in the danger zone. Trying to save creates a temporary spike in RAM, as do normal in-game issues that you might never notice on-screen if not for the crash or Error 12. So one of these spikes could easily put you over the ~3.7 GB limit. And if a save, any save, is using around 3.5 GB after 20-30 minutes of play, it's essentially unplayable, since saving will probably be impossible even if it doesn't crash outright.
I think a less-complicated world is a very good idea, whether it's smaller physically or just has fewer lots or sims.
Seti Texture Memory
I have everything done to get my graphics card being recognized by the game and have this line of code as follows in my graphicrules file:
if ($textureMemory == 0)
seti textureMemory 4095
# setb textureMemorySizeOK false
From my understanding we can set it to half the value of VRAM our graphics card has. For me this value works fine.
I did a lot of things from this guide to help prevent crashing. Maybe you haven't tried it.
https://steamcommunity.com/sharedfiles/ ... 1131162350
if ($textureMemory == 0)
seti textureMemory 4095
# setb textureMemorySizeOK false
From my understanding we can set it to half the value of VRAM our graphics card has. For me this value works fine.
I did a lot of things from this guide to help prevent crashing. Maybe you haven't tried it.
https://steamcommunity.com/sharedfiles/ ... 1131162350
-
puzzlezaddict
- Reactions:
- Posts: 1257
- Joined: June 22nd, 2018, 6:00 pm
Seti Texture Memory
.himawara post_id=96910 time=1695749739 user_id=1870 wrote: I have everything done to get my graphics card being recognized by the game and have this line of code as follows in my graphicrules file:
if ($textureMemory == 0)
seti textureMemory 4095
# setb textureMemorySizeOK false
From my understanding we can set it to half the value of VRAM our graphics card has. For me this value works fine.
You can actually set that value to whatever you want as long as it your graphics card's VRAM is higher than 800 MB. Below that, it would be important not to exceed the GPU's capabilities, although even that might be fine on current systems: to bridge the gap, the GPU can borrow from main memory, which these days is fast enough that may not impact effective performance, i.e. what we see on-screen.
.
.himawara wrote: ↑September 26th, 2023, 1:35 pmI did a lot of things from this guide to help prevent crashing. Maybe you haven't tried it.
https://steamcommunity.com/sharedfiles/ ... 1131162350
That guide has some useful information but is also over the top in what it considers "essential." Additionally, it lacks some caveats that unsuspecting users should receive, for example that the CAS features from the Smooth Patch 2.x are not totally stable and conflict with MC. I would never recommend that guide outright; it's easier to just suggest the helpful steps separately and as an individual user needs or wants them.
Seti Texture Memory
This guide has helped me in the past to a great deal but I know that the official Smooth Patch conflicts with MC. There is a version on this site which makes it compatible.
However, the Smooth Patch has never worked for me. I don't know why, I used the compatible version and all it does is that my save games load a lot slower than without it.
However, the Smooth Patch has never worked for me. I don't know why, I used the compatible version and all it does is that my save games load a lot slower than without it.
Seti Texture Memory
Lookn your device config. If it doesnt say "override: 32 bit" and says something else like your graphics card vram, then I dont believe you have to touch that setting at all.
Seti Texture Memory
I have the compatible version of the smooth patch since Lazy Duchess updated. Is that still a problem?puzzlezaddict wrote: ↑September 26th, 2023, 7:47 pm.himawara post_id=96910 time=1695749739 user_id=1870 wrote: I have everything done to get my graphics card being recognized by the game and have this line of code as follows in my graphicrules file:
if ($textureMemory == 0)
seti textureMemory 4095
# setb textureMemorySizeOK false
From my understanding we can set it to half the value of VRAM our graphics card has. For me this value works fine.
You can actually set that value to whatever you want as long as it your graphics card's VRAM is higher than 800 MB. Below that, it would be important not to exceed the GPU's capabilities, although even that might be fine on current systems: to bridge the gap, the GPU can borrow from main memory, which these days is fast enough that may not impact effective performance, i.e. what we see on-screen.
..himawara wrote: ↑September 26th, 2023, 1:35 pmI did a lot of things from this guide to help prevent crashing. Maybe you haven't tried it.
https://steamcommunity.com/sharedfiles/ ... 1131162350
That guide has some useful information but is also over the top in what it considers "essential." Additionally, it lacks some caveats that unsuspecting users should receive, for example that the CAS features from the Smooth Patch 2.x are not totally stable and conflict with MC. I would never recommend that guide outright; it's easier to just suggest the helpful steps separately and as an individual user needs or wants them.