Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

We don't get a mem usage of 1.7-1.8GB. Our game usually is somewhat between 1GB-1.2GB or 1.2-1.4GB (later on with more characters in the game).

The video is great, but as we use the Unity Engine (C#/mono), we don't do any malloc(). So it's not really our fault, though if we find a repro-case, we'd happily report this to the Unity devs or see if we can find a workaround. 

It is a mystery why the OS does not start paging but crashes the software instead if one of those processes gets close to the 2GB mark. Of course, paging won't help if the app needs more than 2GB, but your crashes seem to occur once your user address space exceeds 2GB - which is not the same. All your background apps/services run under your user address space, not just our game.

Definately try the /3GB switch. Though we didn't see our game using more than 1.4GB of RAM. Is there a scenario where the game uses more than 2GB user address space?

We tried to reproduce the error with the process governor but the first part of the game works flawlessly (max Textures, 2xAA, FullHD). When do your crashes occur and what are your settings?

The crashes always occur in BatchDeleteObjects call and always at the same location:

55BC8C8A | je unityplayer.55BC8CE0                 |
55BC8C8C | lea ecx,dword ptr ds:[eax+eax*2]        |
55BC8C8F | mov eax,dword ptr ds:[esi+11C]          |
55BC8C95 | lea edx,dword ptr ds:[eax+ecx*2]        |
55BC8C98 | mov eax,dword ptr ds:[esi+10C]          |
55BC8C9E | movzx ecx,word ptr ds:[eax+edi*2]       |
55BC8CA2 | movzx eax,word ptr ds:[edx]             |
55BC8CA5 | shl eax,10                              |
55BC8CA8 | or ecx,eax                              |
55BC8CAA | mov eax,dword ptr ss:[ebp-10]           | <-- EAX is NULL here
55BC8CAD | mov dword ptr ds:[eax],ecx              | <-- Bret Hart is right!

So may be related to this Unity bug?

https://forum.unity.com/threads/batchdeleteobjects-crash-unity-5.321080/

Someone suggested to run a manual cleanup routine. Maybe you could try that?

I tried patching it to check for a null pointer and bail out, but then next times it comes with a pointer of 0x1000000, because it probably didn't clean up properly, so this is also pointless.

On my machine, it's enough to turn on highest resolution and Ultra HD Texture quality to immediately trigger it (by i.e. loading my last saved game now or opening a new game and leaving Bernards room). This always crashes it. If you want, I can give you TeamViewer access or remote debugging session to my test machine.

The bug report does not really fit into this scenario, as it is clearly linked to mobile, has been fixed and occured in a very old version of Unity which we are not using. Also, we can't try out the workarounds from the thread because they don't apply to our setup.

We suggest on your Win7 machine you should try the 4GB-Tuning (BCDEDIT /Set IncreaseUserVa 3072) or PAE (BCDEdit /set PAE ForceEnable). We cannot help with the crashes on XP, though.

Also, we are preparing an update which allows you to reduce the scene cache size. That may help, too.

Just a little note. I found debug symbols for Unity3D and therefore was able to find out that it crashes in  crnd::crn_unpacker::unpack_dxt5

Fortunately, this code seems to be available on the net:
https://github.com/toji/webgl-texture-utils/blob/master/crunch/crn_decomp.h

bool unpack_dxt5(uint8** pDst, uint32 dst_size_in_bytes, uint32 row_pitch_in_bytes, uint32 blocks_x, uint32 blocks_y, uint32 chunks_x, uint32 chunks_y);

So pDst is an array of pointers that gets filled by the unpacker, some of them being possibly NULL because allocation failed, as you suspected. 
In line 

uint8* CRND_RESTRICT pRow = pDst[f];

there needs to be a check:
if (!pRow) return false;
to fix the crash. I can add it in assembly code, maybe the game then will at least shut down properly.

I will try the method to expand memory in the evening, nevertheless the memory management of the application should be able to trim the cache automatically in order to not hit the 2GB barrier imho. So I'm looking forward to the new version which supports reduced cache size.

I now tried it with 3GB usermode address space, and now was able to play it through. Wow, what a great game, thank you! :-)

It took approx 2.3GB of memory during playing, so we definitely hit the 2GB barrier. Nevertheless fixing missing null-pointer checks couldn't hurt, maybe file a bug report to Unity developers, now that the issue is nailed down to a function.