Wintermute Engine Forum

Wintermute Engine => WME Lite => Topic started by: Lazov on September 25, 2014, 01:22:12 PM

Title: Random Access Memory
Post by: Lazov on September 25, 2014, 01:22:12 PM
Hello!
Recently ported your project on the Android platform using WME Lite. The problem is that the WME consumes a lot of memory. I understand that all the resources of engine loads into RAM. Thus, when file size 45 MB dcp game takes 300 MB! RAM. Can I somehow fix this problem?
Title: Re: Random Access Memory
Post by: HCDaniel on September 27, 2014, 03:10:00 PM
Using the "asset" method for packaging game files is only really usable if your game is small.

For distribution in Google Play, 50MB is the limit for your app anyway.

The best idea for distributing games > 50MB in Google Play is to use "expansion files". This link has more information: http://developer.android.com/google/play/expansion-files.html

If you have max. 2 game packages, you can use the "obbplain" method (directly accessing the expansion files). If you have more packages, you should create a file system image with the "jobb" tool http://developer.android.com/tools/help/jobb.html and use the "obbmount" option.
Title: Re: Random Access Memory
Post by: Lazov on September 27, 2014, 08:39:39 PM
Using Files "obb" can reduce the consumption of RAM?
Title: Re: Random Access Memory
Post by: HCDaniel on September 27, 2014, 09:52:21 PM
I would assume so. Asset files are mmap'ed when opened, but .obb files you can handle like you want. WMElite will not mmap them when they are opened, so you should see a difference.
Title: Re: Random Access Memory
Post by: Lazov on September 29, 2014, 08:32:12 AM
File obb engine does not read. I unpacked the archive and threw dcp files on the sd-card. That is, files are in an open state. Nothing has changed, the game takes 300 MB of RAM. The problem in the engine. At this moment there is no way to port the big games.
Title: Re: Random Access Memory
Post by: HCDaniel on September 29, 2014, 09:09:31 AM
That is strange, I have a game with ~ 1GB of data running fine.

With the "obbplain://" access method, wme lite perfectly well reads .obb files.

How did you get the figures for memory consumption? Are you sure you are not looking at the "overcommitted memory" figures?
Title: Re: Random Access Memory
Post by: Lazov on September 29, 2014, 01:15:43 PM
Have written to you in a PM.
I just looked at the free memory to run and after.
Title: Re: Random Access Memory
Post by: HCDaniel on September 30, 2014, 12:30:10 PM
Hm, that might be inappropriate for a real memory usage estimation. But I don't have an easy alternative that is 100% correct.

I suggest that you run "top" on the command line while executing the app. Maybe "top -m 10" for less uninteresting output.

The values reported will still be too high, but "RSS" can give you at least an idea of how much memory is needed. Unfortunately, shared libraries are also included, so this value is always higher. Also, a complete Dalvik VM including all preloaded classes is included - I don't know how much memory that populates by default.

On my device (with a game data package ~ 400MByte) the "RSS" value is always ~ 150 MB. The majority of that is probably graphics memory (I use the "pixelperfect" rendering option that about doubles graphics memory). While I play the game, the memory figures do not continuously increase, thus I'd assume that this is about it.

You can compare it to the other apps that run on your phone. Many of them will also reach an "RSS" of > 100MB, thus I don't see wmelite for Android being that special. Yes, pure native programs (android system specific daemons) consume less memory - but that's not something you can use for your app (and you should not compare it to these).

I haven't compared memory consumption to the Windows wmelite w.r.t. memory, and neither did I compare wmelite to the original wme on Windows. Might be an interesting comparison...
Title: Re: Random Access Memory
Post by: Lazov on October 19, 2014, 10:50:53 AM
When using obb game consumes the same amount of RAM.
The problem remains open.