3 ms·
Performant games never release their memory, so they should never get paused by the GC.
by confluence 13y ago
Performant games never release their memory, so they should never get paused by the GC.
- AshleysBrain 13y agoHaving written one of the major HTML5 game engines (Construct 2), it's extraordinarily difficult to completely avoid memory allocations, so there is always some garbage overhead. Consider straightforward calls like slice() make allocations and have to be worked around to avoid garbage - and that is very much just the tip of the iceberg.
- kevingadd 13y agoFalse. Do you mean that performant games tend not to allocate each frame? That is generally true. Performant games very certainly do release memory, though their allocation patterns tend to vary - lots of modern games actually use a garbage collector of some sort, whether it's for lua scripts or for larger parts of the game code. Sometimes their GC is a weak form of refcounting, sometimes it's a conservative stack-scanning GC, sometimes it's a precise one. Lots of modern 'performant' games are written in Java or C# and in those cases too, you have a GC and occasional allocation/freeing of memory, however they do tend to make an effort not to allocate from frame to frame or allocate temporary objects. For console games it's definitely false that they don't release memory; memory usage has to be precisely controlled on console so subsystems that don't happen to be using memory at the moment are definitely not holding onto it - that memory's being used for something else.
- azth 13y ago> Lots of modern 'performant' games are written in Java or C# and in those cases too... I keep wondering whether it is possible to write a game like BattleField4 or Crysis in Java/C#/etc. Do you have any insights on this issue?
- yoklov 13y agoIt's probably possible, but it's not really worthwhile. In the best case scenerio, it's the same amount of work as writing one in C++. The benefits and nice features of those languages would cancel out the drawback of lack of control. In the worse case, the lack of control means you can't use the features of those languages which would make development easier, and you'd miss C++'s low level features which have no equivalent in higher level languages. Since the reality is somewhere between these (in my experience, it's pretty close to the worse case), and implementing a high performance game engine is such a large task, it's a much better engineering decision to just go with C++ (or another language which allows a similar level of control) from the start.