#memory management

I don't think there's a term called "memory loss", but you're probably thinking of a "memory leak". A memory leak is when a program grabs more memory for use while looping than it releases. This results in the machine using more and more memory over time, thus having less and less available memory to use. This causes slowdown and eventually crashing once all of the available memory has been used. When you reboot, all of that claimed memory gets released and becomes available for use again. That's why your games run faster after rebooting, the games have access to more memory after the reboot.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

In Rust (and most programming languages), memory is divided into two main parts: the stack and the heap.

The stack is a region of memory that is used to store function call frames and local variables. The stack is fast and efficient, because data is stored and accessed in a Last-In-First-Out (LIFO) order, which means that when a function returns, its frame is immediately popped off the top of the stack. In Rust, stack-allocated values are stored on the stack and automatically cleaned up when they go out of scope.

The heap, on the other hand, is a region of memory that is used to store values that are required for a longer period of time. Unlike the stack, the heap does not have a fixed size and can grow or shrink as needed. Heap-allocated values are stored on the heap and are referenced through pointers. In Rust, heap-allocated values are managed through a system of ownership and borrowing, which ensures that data is automatically cleaned up when it is no longer needed.

Here's a simple example that demonstrates the difference between stack and heap allocation in Rust:

In this example, x is a stack-allocated integer and y is a heap-allocated integer, stored in a Box. A Box is a type of smart pointer that represents ownership of data stored on the heap. When y goes out of scope, the memory it references will be automatically freed.

It's possible, but if you had a full world's worth of assets loaded and running, the game would either run at an unplayable frame rate or would be significantly reduced in visual fidelity. This kind of thing actually did happen way back in the day - we used to load the entire game into memory in the arcade coin-operated machines and cartridge days. Nowadays we can do a lot with streaming data from disk into memory, most of which comes from being clever in optimizing what gets loaded when. As long as we can keep the smoke and mirrors going, the player never sees the railroad tracks they're following.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

It's always doing something. Consoles and PCs have finite memory available to hold data and assets. When the game transitions from one level to another, if there isn’t enough free memory to load the next level’s data and assets, it has to unload (some of) the current level’s data and assets in order to make room for the new stuff. 

The loading process is a lot like refurnishing an already fully-furnished room. When you start the load process, your room is currently already set from the previous level - there's a couch, desk, rug, dresser, chairs, television, tv stand, decorations, wall hangings, and so on. You can't necessarily just bring in all of the new furniture for the room willy-nilly, you need to make sure there's enough space in the room to place the new furniture before you bring it in. In order to clear out that space, you would first need to remove at least some of the old furniture. Once enough space has been cleared, you can start bringing in the new furniture and arranging it in the room. The loading screen is like the curtain coming down to hide the rest of the old furniture being removed and the new furniture being brought in and rearranged.

What is likely happening during the specific pause before the loading bar appears is that the system is clearing out enough memory to load the UI system and assets needed for the loading screen, and then loading those UI system and assets. If the UI system and assets were already loaded in memory, it wouldn't be necessary to load them since they would already be available... but they might not be necessary to keep around at all times.

It's worth noting that there's also hard certification requirement across all console platforms that a game cannot show a frozen screen (i.e. no movement at all) for longer than a few seconds. This is a guard against a crashed/frozen/locked game, something must be animating and updating on screen.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Generally, the eternal struggle is always about maximizing visual fidelity within the limitations of the technology. That hasn’t really changed, it’s just been a little bit different each time. This gaming technology generation’s struggle is probably two major hurdles to overcome:

Making everything look as pretty as possible while still running at 60 frames per second without dropping anywhere

Removing all loading screens and obvious loading zones

With today’s cutting edge technology, the first challenge basically means trying to juggle ray tracing, physics-based rendering (PBR), high dynamic range lighting (HDR), running shaders, and so on at 4k resolution while still retaining a 60 fps floor. These are all things that could have been done before, but it’s a question of the total number of calculations that must be done each frame. Increasing the display resolution in two dimensions means that you’re growing the number of calculations per second geometrically. [Click here] for a post I wrote explaining the kind of growth I’m talking about.

The second problem is us trying to avoid unintentional breaks to the flow state. We want players to be in the zone, fully immersed in the game. That state gets broken by the limits of technology, such as having to wait a few seconds for a loading screen, being forced to crawl slowly through a crawl space, or seeing blurry things appear that get sharper as time passes. This has always been because we have a finite amount of system memory that we can use to store data, and the rest of it has to sit on the disk somewhere and be loaded. We can’t load that disk-bound data any faster than the hardware can let us. In the past, we’ve adopted sneakier ways of doing this by doing things like predictively loading data from disk, but that doesn’t always work if players decide to turn around and go back to an area that was just unloaded. New hardware like SSDs will certainly allow us to transfer data from disk at a faster rate than before, which should help with loading screens and such. Still, it’s a very real problem that we’ve been experimenting with for ages.

Overall there are still very real limitations on the hardware that we have to work around with clever solutions. It’s always been a question of how to fit all of the relevant data we need within the available system resources. It was back in the early days and it’s still the same situation today. Our system resource capacity has increased, but we’ve also greatly increased the sheer amount of data we need to fit into those system resources. It’s an eternal struggle that has worn many faces and names over the decades, but the underlying issue is never truly solved. It is, at best, acceptably solved for now.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

It’s usually either because the code tried to access something at an invalid memory address or because it’s stuck in an infinite loop. 

Whenever a program is running, it starts sticking bits and pieces of data in the system memory while noting down their specific memory addresses so it can find them later. When the program needs a particular piece of data, it can then use the address it has stored to look it back up again. However, sometimes something happens to the data at that memory address - it could have been deleted, overwritten with other data, or maybe it was just a wrong address to begin with. Whenever this happens, the program usually crashes because it doesn’t know what to do. The reason you see a freeze instead of an error message is usually because the system is waiting for the program to do something, but the program can’t. At that point, the program has essentially become a static block of memory frozen in stasis until it is killed. That’s why the screen freezes - it’s the last valid snapshot that was sent to the GPU. These sorts of problems are usually handled by the operating system - it recognizes that the program has crashed and cleans it up, usually with a generic “this program has crashed” error message. So it’s not *really* a freeze anymore.

The other common occurrence is an infinite loop. Programmers use a lot of loops to do things in code - many tasks are regularly repeated with slightly different parameters. Most of the time, we check on some condition to know when to stop - there are this many pieces of equipment in the list to check, so we start from the first slot and work our way up to the last slot. However, the game only does what it’s told to do. if something goes wrong and the exit condition is never met, the game won’t know to stop - it will happily keep chugging in circles until the program is terminated. This causes the game to freeze because it thinks everything is running as expected but it’s just perpetually running in the same circle.

These two tend to be the most common occurrences of a game freeze. There are other situations that can come up, of course, but these two usually cover most of the situations. 

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Understanding Linux Swap Tuning: Optimize Your System’s Performance Now The Kubernetes NodeSwap feature, likely to graduate to stable in the upcoming Kubernetes v1.34 release, allows swap usage, a significant shift from disabling swap for performance predictability. This article focuses exclusively on tuning swap on Linux nodes, where this feature is available. By allowing nodes to use secondary…

– AI assistants that forget what you told them 5 minutes ago aren’t very helpful. While large language models (LLMs) excel at generating human-like responses, they are fundamentally stateless—they don’t retain information between interactions. This forces developers to build custom memory systems to track conversation history, remember user preferences, and maintain context across sessions, often…