Hot answers tagged

63

Same as all average programs: They don't.* For most applications there is no customer expectation that they continue working once memory runs out. All games fall under these "most applications". Spending time and money to work on an edge case which the customer doesn't expect to work doesn't make sense. The question is similar to the following: How do you ...


36

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, ...


29

GPU compressed texture formats like DXT / BC / ETC are specifically designed to be read directly from their compressed form. They don't need to be unpacked into a raw RGBA buffer. The way this works is each block of texels (often 4x4) takes up some fixed number of bits - so we know exactly how far along in the buffer to look for a particular texel - and ...


27

This would depend on the game and the indexing structure used for the chunks. Though, at such a high level, it's not too likely it has much to do with memory or a specific performance enhancement. More than likely it's an arbitrary decision for sizing chunks in a predictable way. It allows for some counting and indexing tricks using bit shifting that wouldn'...


26

I don't know how old that writeup is, but I'd say it's pretty old. In modern Windows (XP and newer, but specially on 64-bit versions), I would say doing something like that will have little to negative impact on the startup of your game. First of all, remember that the address space is virtualized for each process. As far as your process is concerned, you ...


23

Typically this kind of scenario never happens. Firstly, virtual memory on modern operating systems means that it's highly unlikely to happen in normal operation anyway; unless you have a runaway allocation bug, the game will be allocating memory from the OSs virtual address space and the OS will be looking after paging in and out. That's all well and good, ...


21

Virtual memory is allocated from the OS in large chunks, when even a byte is left still in use in that large chunk it cannot be released back to the OS. Allocation libraries in user-space also keep a certain amount for re-use to avoid repeatedly demanding and releasing memory from/to the OS which is extremely slow. E.g. you allocate a texture, the OpenGL ...


16

Generally, you don't handle out-of-memory. The only sane option in software as large and complex as a game is to just crash/assert/terminate in your memory allocator as soon as possible (especially in debug builds). Out-of-memory conditions are tested for and handled in some core system software or server software in some cases but not usually elsewhere. ...


16

Modern open-world games simply don't fit in memory. Keep in mind that most games are still 32-bit due to the number of gamers with 32-bit OSes, and a 32-bit process at best can only have 4GB of addressed memory at a time (independent of virtual memory) but realistically is limited to 2-3 GB. Toss in fragmentation and the actual amount of usable objects you ...


16

What you need to do is separate terrain from live blocks. For example you could store the live blocks in a dictionary that uses a point as key. And then unload the terrain. This way your live blocks stay in memory in a way you see fit, and you can still look them up based on position, but the terrain is stored on disk for later retrieval. This will increase ...


15

First, multiplying by powers of two is much cheaper than multiplying by an arbitrary number, since you can do it by bit shifting. Most of the time the compiler can do this for you, so whenever you write "* 16" in your code, the compiler actually does a shift by four, and you don't need to worry about it - you just need to give the compiler the opportunity by ...


14

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 ...


12

Does its data get sent to GPU memory only once and sit there forever? Usually yes, but the driver is free to do what is "optimal", the data might be stored at VRAM or RAM or could just be cached here is an atricle that explains what actually happens with the VBO flow. For example if it was flagged as a dynamic openGL buffer (e.g. VBO), it's more likely to ...


12

Yes, it is possible for a user to get the images in GPU memory. It's not likely they'd get them by dumping the entire GPU memory space (though with specialized hardware, drivers or debugging software such a thing is possible -- Visual Studio has a powerful GPU debugger these days). Rather, they can get them from CPU memory, which is much easier. Your game's ...


12

One thing that pre-allocating a large chunk of memory could do, if your computer was low on RAM, might be to force the OS to free some extra space by swapping parts of other programs' memory space to the disk. Since such swapping is generally a very slow operation that pretty much freezes your program while it's happening, there could be some advantage to ...


9

The real answer is just this: On a binary computer, powers of two are nice round numbers. When a normal person needs to pick an arbitrary number for some purpose, they typically choose nice round numbers in the number system they're comfortable with, base 10. So they'll pick 10, 100, 1000, etc. Because they're simple and easy and don't require much ...


9

Yes, a game/engine should clean up after itself when it's closed. There are good reasons for that: Show to your team that you know what's going on in your game Know when your managers are shut down Make sure your files and handles are closed and your data is saved Help prevent crashes on exit because you have a better idea to what's going on Help find ...


8

I've recently implemented both versions in OpenGL (4.3) and using the (Crytek) Sponza scene as a test render scene, I had shaders that used either only a subset or the complete set of all vertex attributes defined. There was one difference to your setup: In the non-interleaved case, the attributes were inside the same vertex buffer, too. It easy to do this ...


7

Basically, it's not easy to get the vertex data back from the video card once it's there. Keeping the vertex data available to the CPU allows for a number of things, here are a few: As melak47 suggests, it allows the developer to free up video memory by freeing a VBO, while being able to quickly replace the data without needing to read from disk again. It ...


7

There are 2 issues in your synthetic sample: The first issue is that you are calling target.GetDataAsImage which is unoptimized in scenarios where you need to do it each frame. Internally the GetDataAsImage is creating a CPU/GPU staging resource (same size as the render target) and allocating an Image on the CPU (again same size on the render target). A ...


7

Answers to your questions really depends on the platform. Generally BC formats are kept in compressed form in memory and decompression is done in flight by GPU texture units, but there are exceptions. Namely Xbox 360 is known to decompress complete 4x4 pixel BC blocks to cache before TU fetches the data thus inflating cache usage. I don't know of any ...


6

One reason not mentioned in other answers is that if needed, powers of two numbers can always be halved without rounding problems. This is probably not a reason in Minecraft clones, but is in some other cases such as in textures with mipmaps.


6

For a 32-bit game, as most games are for a variety of reasons, even a game that comes on one single-sided DVD (4.3GB) already has far more content that can be fitted into a 32-bit address space. And that's assuming the content isn't compressed on disc, and a perfectly optimal, load everything at once into contiguous address space approach. Many games now ...


6

No. If you request a buffer store (via glBufferData) larger than the implementation can satisfy, you'll get a GL_OUT_OF_MEMORY error. Buffers may be temporarily (or permanently) backed by CPU memory depending on their state, but a overly-large buffer store will never overflow out of GPU memory into CPU memory. To handle the large volume of data you're ...


5

The application is usually tested on the targeted platform with the worst case scenarios and you will always be prepared for the platform you are targeted. Ideally the application should never crash, but other than optimization for specific devices, there are little choices when you face low memory warning. The best practice is to have preallocated pools ...


4

"Map is stored only on the server it's sent to the client in parts": Pros Client always has most up-to-date map Can keep map data hidden until the user has visited the area System already in place for pushing expanded or updated map data Cons Client has to always download map data even if it's un-changed and they've been there before Due to the above,...


4

Tekkit (a popular minecraft mod) does this by allowing players to build anchors that keep a few blocks around them in memory regardless of player proximity. It might be a good choice if there is clear distinction between dynamic blocks that require the presence of the player (an automatic door) and others that don't (a generator of some sort). http://...


4

Yes, there's a reason to do this. The user might want to play the map again, and if so having all (or at least most of) the map already resident in memory means it doesn't needed to be loaded from disk again, thus reducing load times in that (often typical) case. Purging something from memory is not free, either, as there may be references to loaded that ...


4

Simple Answer This isn't properly precise, but it's "good enough" for most day-to-day work: Value types like structs do not themselves create garbage collection overhead. If you already have some memory set aside for a struct somewhere, assigning a new value to it doesn't give the compiler or runtime any cause to go reserve memory elsewhere - it already ...


Only top voted, non community-wiki answers of a minimum length are eligible