Tag Info

Hot answers tagged

118

"Memory" and "efficiency" are commonly misused terms, so I'll give you an answer for four different elements that may affect the performance of your game. I will be oversimplifying way too many things to keep it short and concise, but there are tons of inaccuracies in this text below, so take it with a pinch of salt. However, the main concepts should be ...


47

the app crashes when it reaches 1.5Gb. This strongly suggests that you're not representing your tiles correctly, as this would mean that each tile is ~80 bytes in size. What you need to understand is that there needs to be a separation between the gameplay concept of a tile, and the visual tile that the user sees. These two concepts are not the same ...


44

Are you looping through all 500,000 tiles when you're rendering? If so, that's likely going to cause part of your problems. If you loop through half a million tiles when rendering, and half a million tiles when performing the 'update' ticks on them, then you're looping though a million tiles each frame. Obviously, there's ways around this. You could ...


43

Simple answer: the game is divided into chunks, while you move around chunks are constantly being loaded behind your back before you can see them and thrown away when you leave the area. To every simple answer is a complex solution that weighs innumerable trade-offs in implementation... but you get the idea. For games where you think you can see tens or ...


22

Split the terrain into regions or chunks. Then only load the chunks that are visible to the players and unload the ones that are not. You can think of it like a conveyor belt, where you're loading chunks at one end and unloading them at the other as the player moves along. Always staying ahead of the player. You can also use tricks like instancing. Where if ...


20

In an average game, there are hundreds or maybe thousands of obects in the scene. Is it completely correct to allocate memory for all objects, includiding gun shots(bullets), dynamically via default new()? That really depends what you mean by "correct." If you take the term quite literally (and ignore any concept of correctness of the implied ...


19

Game Engine Architecture has some information regarding this topic. The basics are that you need to do some analysis to understand what your memory requirements per level/frame/etc. are like, but there are a few patterns the author mentions having seen several times: Stack-based allocators: These allocate a large segment of memory once, and then allocate ...


17

Once an image is loaded off the disk and is formatted for rendering, it will use the same amount of memory regardless of whether that image was saved to disk using PNG, JPEG, or GIF. General rule of thumb: JPEG is a lossy format, and will degrade image quality in order to make the image smaller on disk. PNG, on the other hand, is a lossless image format, ...


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


14

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


12

Previous answer pretty much nails it all. Also worth mentioning is Dungeon Siege I. Here's a paper from one of the developer which actually goes over some of the architecture needed to make it work and common pitfalls: http://www.floatingorigin.com/mirror/continuous-world.htm I'd say it's a must read if you actually want to implement something like that.


12

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


11

We have a similar case with our RTS Remake. All units and houses are sprites. We have 18 000 sprites for units and houses and terrain, plus another ~6 000 for team colors (applied as masks). Long-stretched we also have some ~30 000 characters used in fonts. So there are some optimizations against RGBA32 atlases you are using: Split into many smaller ...


10

Use your common memory management sense. Use pools/freelists for things that are frequently allocated and deallocated (i.e. particles), free memory blocks that aren't in use. However, don't try to preallocate large chunks of memory upfront. iOS doesn't guarantee memory nor does it swap, so any memory you have allocated is taking resources away from the ...


10

Mick West's article explains the process of linearising entity component data, in full. It worked for the Tony Hawk series, years ago, on much less impressive hardware than we have today, to greatly improve performance. He basically used global, pre-allocated arrays for each distinct type of entity data (position, score and whatnot) and references each array ...


9

While I agree with the sentiment: "don't worry about it unless it's a proven issue", I do think it's worth thinking about early on: retro-fitting a solution is much more painful. And yes, only updating 'nearby' tiles is they way to go. But storage and addressability of items in your game world efficiently is very important for performance reasons. What ...


8

You can do this in C#, but you'll likely need to P/Invoke a lot of the functionality you'd need. C or C++ is probably more well-suited to the task -- you'll have fewer hoops to jump through. There are a few open source "cheat engine" projects out there you can look at for a better idea of what you're going to have to do. How do I find the correct memory ...


8

std::string does not do copy on write. CoW used to be an optimization, but as soon as multiple threads enter the picture it's beyond a pessimisation- it can slow the code by massive factors. It's so bad that the C++0x Standard actively bans it as an implementation strategy. Not just that, but the permissiveness of std::string with dishing out mutable ...


6

I don't have much to add to Josh's excellent answer, but I'll comment on this: Should I create any memory pool for dynamic allocation, or is there no need to bother with this? There is a middle ground between memory pools and calling new on each allocation. For example, you can allocate a set number of objects in an array, then set a flag on them to ...


6

If anything, the first option might be better for cache misses since generally you'll be iterating through, say, all the Renderable components at once. Just copy the data you need into that component to avoid cache misses due to looking up data. But it seems like you're suffering from design paralysis. Do you actually have a working game yet? Are the ...


6

As mentioned in PeterT's comment, you don't need to load all of your levels at once; instead you just load the current level and when the player transitions from that to a new one, you unload the current and load the new. That gets you down to about 100mb (the raw per-level cost), but we can go lower still. Consider a cube; right now you're defining each ...


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


5

In case you don't find such a comparison chart, the alternative is to inject an own allocator to the STL classes in question and add some logging. The implementation I tested (VC 8.0) uses no memory allocation just by declaring a string/vector/deque, but for it does list and map. The string has a short string optimization, since adding 3 chars didn't ...


5

According to your tags it says "browser-based-games" depending on the game and its complexity, I would say 100mb most likely too much, unless you are creating a large mmo style flash game(even that is very large!) There is a bunch of compression options you have for flash as well, which may shrink your game down tiny: 0 - 200 KB; small: 200 - 700 KB ...


5

I've been wondering about this as well, so I decided to check out some popular games and watch Firefox's plugin container memory consumption. Memory starts and defaults back to around 5-10MB on my setup. With that in mind, here are the peak memory usages in the first 3-5 minutes of gameplay for some popular games: The Company of Myself - 35 MB Don't Touch ...


5

Swapping textures will kill your performance. Modern hardware has only gotten more susceptible to this problem, not less, as the speed and power of the shader units and video RAM are growing much faster than the speed increases of the bus between system RAM and the GPU. The only sane approach is to cut down your texture sizes, or generate procedural ...


5

Byte56's answer is good, and I started writing this as a comment to that but it got too long and contains some tips that might be more helpful in an answer. The approach is absolutely just as good for server as it is for a client. In fact it's probably more appropriate, given that the server will be asked to care about far more areas than a client will. The ...


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 that, optimization for specific devices is the only thing you can do, there are little choices when you face low memory warning. The best practice is ...


5

In Minecraft, circuits in unloaded chunks simply do not work. Especially with pistons and other ways of interacting with the environment, it could get expensive quickly to keep far-away circuits running in an infinite world. I see three main possible choices for your game: Keep all chunks loaded. This is just a big nope. Keep nearby chunks loaded. For ...



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