Even worse, you could end up asking yourself why are you in gamedev after all. This will lead to questions such as “ where are these extra 200MB coming from?” or “ why is this still in memory even if I destroyed all references to it?“. → Here’s the second problem: profiling your game won’t be accurate anymore because the numbers you see won’t match what you expect. If you ever played Arkham Horror, or Eldritch Horror for the matter, you’ll know better than to play with sanity points. But some OS won’t be that forgiving when it comes to memory (Oculus Quest comes to mind). → This won’t endanger your game often, as a good operating system will kindly remind Unity to clean its shit when it becomes too greedy. You’ll think you have more free memory than you actually have. If you believe memory is released when it is NOT, then you might run into trouble at some point. These all are examples of wrong assumptions most game developers make regarding Unity memory management and asset unloading.Īnd these assumptions might have somewhat nasty consequences. “What the f*** is going on here?”, you curse aloud. You’re furious to see that nothing changed in your memory layout. ![]() You profile again and aren’t happy to see the sprites are still in memory.Īnd the last one: you call Addressables.Release(myInstance) on an addressable asset.The user returns to the game and you unload that additive scene.All its sprites are loaded, and that’s fine. You additively load a scene that contains the pause menu UI. ![]() However, the memory taken by that prefab didn’t come back and your internal dialog says “shitty editor”. You even go as far as to remove the original reference to the prefab to make sure it’s removed from memory.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |