First of all, are you sure you really need that? Have you calculated the memory footprint?
A small back-of-the-envelope calculation: A single mob and its state should fit into 100 byte of data. Let's give it a whole kByte, in case you are doing something extraordinary. When a cell has 1000 such entities, it requires a MByte. If your world is 100x100 cells, ...
One way you could solve this problem is not actually storing state on disk, but just setting up your generation code to use a seed for the random number generator, so it generates the same thing for a given area every time the area is generated, deterministically.
Then you just keep the 1000 or so most recently visited areas in memory. When areas are ...
Save it to the hard drive instead.
Saving large quantities of data in a non-volatile fashion is literally why hard drives were invented. If a player isn't interacting with it anymore, you won't need to rapidly access it, so why keep it in the RAM? Just save it to the your server's hard drive in a text file or something.
Textures, RenderTextures, and Materials use memory outside of C#'s managed heap (including GPU memory), so the regular C# garbage collector alone can't fully clean them up.
You need to manually Destroy() them once you no longer need them.
Your current code does this for the RenderTexture rt (though it doesn't call Release first - I'm not sure if that's ...
Or is it safe to assume that if it's a device local heap it will always be viable for device local resources?
If it were safe to assume that, Vulkan wouldn't have APIs that specifically allow you to query which memory types support which resource objects.
Indeed, NVIDIA can get pretty fine-grained in its relations between memory types and resource objects. ...
I finally used this code :
public class Capture : MonoBehaviour
private static int resWidth = 3840;
private static int resHeight = 2160;
private static GameObject camObj = null;
private static RenderTexture rt;
private static Texture2D screenShot;
public static string ...
Your crashes is mostly because of improper handling of the object's ownership.
When you add something to a collection, you should clearly understand who's owning the object. Is that handler owns the added objects now, and may delete those when time has come? Or is that handler only references the objects, and there's some other subsystem that will destroy ...
For a project that we worked on, we had utilized grouping. It was one creature (with a model of many creatures), but had many hitboxes. When a hitbox HP became 0, it would divide the creature and create a second or third model.
Utilize low-poly models. We had to use this a long time ago for massive battles with multiple mobs.
I used a combination of the new-fangled (and non-allocating!) std::to_chars and std::string_view with a static std::array for a buffer. It works okay, but having to deal with the buffer being overwritten is a little annoying. The use of std::strlen is unavoidable but shouldn't be an issue due to the short strings.
I also refactored the code to not use the ...
Well, you can allocate about 16 MiB (just to be 100% sure) at startup or even in .bss at compile time, and use a "safe allocator", with a signature like inline __attribute__((force_inline)) void* alloc(size_t size) (__attribute__((force_inline)) is a GCC/mingw-w64 attribute that forces inlining of critical code sections even if optimizations are disabled, ...