The easiest way is probably to do it in your build script. Very simple to do in python for example
f = "path/to/game.project"
config = configparser.ConfigParser()
config.read(f)
config.set("project", "title", "DEBUG_TITLE")
with open(f, "w") as fp:
config.write(fp)
I tried stripping only the physics out to see the implications on memory and package size. May as well dump my findings here.
Because I didn’t want to spend too much time I only tested on macOS builds, the memory could differ from device to device though so keep that in mind. I built each version for macOS and got the memory with profiler.get_memory_usage(). I restarted the whole game after each sample and I used 9 samples. Testes done with engine version 1.2.117 and in release mode.
TLDR; The package size decrease is nice but memory implication is pretty meh.
# Release + No: Physics
platforms:
x86_64-osx:
context:
excludeLibs: ["BulletDynamics", "BulletCollision", "LinearMath", "Box2D", "physics"]
libs: ["engine_release", "physics_null"]
x86_64-linux:
context:
excludeLibs: ["BulletDynamics", "BulletCollision", "LinearMath", "Box2D", "physics"]
libs: ["engine_release", "physics_null"]
js-web:
context:
excludeLibs: ["BulletDynamics", "BulletCollision", "LinearMath", "Box2D", "physics"]
libs: ["engine_release", "physics_null"]
x86-win32:
context:
excludeLibs: ["libBulletDynamics", "libBulletCollision", "libLinearMath", "libBox2D", "libphysics"]
libs: ["libengine_release.lib", "libphysics_null.lib"]
x86_64-win32:
context:
excludeLibs: ["libBulletDynamics", "libBulletCollision", "libLinearMath", "libBox2D", "libphysics"]
libs: ["libengine_release.lib", "libphysics_null.lib"]
armv7-android:
context:
excludeLibs: ["BulletDynamics", "BulletCollision", "LinearMath", "Box2D", "physics"]
libs: ["engine_release", "physics_null"]
armv7-ios:
context:
excludeLibs: ["BulletDynamics", "BulletCollision", "LinearMath", "Box2D", "physics"]
libs: ["engine_release", "physics_null"]
arm64-ios:
context:
excludeLibs: ["BulletDynamics", "BulletCollision", "LinearMath", "Box2D", "physics"]
libs: ["engine_release", "physics_null"]
| Empty | 5 Collections from file | 5 Collection Proxies | 5 Collection Proxies - Loaded | |
|---|---|---|---|---|
| Average MB | 38.9 | 38.8 | 38.7 | 40.5 |
| Average Bytes | 38884693 | 38763633 | 38673066 | 40482588 |
The data collected indicates that each collection proxy adds 0.36 MB of memory.
| Empty | 5 Collections from file | 5 Collection Proxies | 5 Collection Proxies - Loaded | |
|---|---|---|---|---|
| Average MB | 38.6 | 38.4 | 38.6 | 40.2 |
| Average Bytes | 38600704 | 38420024 | 38642574 | 40194048 |
Interestingly the data we get now for 5 collection proxies loaded is 1MB lower compared to having it with physics, but it is also still 1.8 MB over the other values. The memory added per collection is 0.36, meaning a 0.09 difference between with and without physics.
| With | Without | Diff | Diff -MB | |
|---|---|---|---|---|
| Android | 2801489 | 2491918 | -309571 | -0.3 |
| iOS | 2619459 | 2263253 | -356206 | -0.35 |
| macOS | 5408039 | 4230099 | -1177940 | -1.2 |
profiler.get_memory_usage() is broken, doesn’t indicate that memory is released and only counts up. Making it only really reliable on build/app start.
If you have physics objects in your build and strips physics out the build will not be able to start but will not give any errors as far I noticed.
I should (but most likely won’t) test it out on android and/or iPhone to investigate if it is comparable with macOS.
Prompted by the other thread I made a github repo with the existing appmanifest files for easy access and to collect others made over time.
I will do some tests too to collect data and create other useful appmanifest files.
Or may be these could be also useful if put to the docs?
Summoning @sicher in case he has an opinion =]
I have a couple little questions/clarifications regarding appmanifest options:
By default, are both 3D and 2D physics engines included in all projects?
If yes, I guess it makes sense for all 2D projects to exclude 3D physics, and vice versa, so…
Which libs correspond to 3D physics, 2d physics, or both?
“vpx” is just for the built-in video recorder, right?
Whitch function should be on the place of zero?
OnMessage or something like that. It says in the docs
// DM_DECLARE_EXTENSION(symbol, name, app_init, app_final, init, update, on_event, final)
Exactly as @dapetcu21 and @sicher said, and you can find the function declaration here.
Currently, we only support two events, app activate/deactive, but in the future we could add more events.
Is Activate calls every time when focus back? Something like applicationDidBecomeActive on ios?
Thanks for the link to docs, I missed when searching.
The activate/deactivate events should happen at the same as the Lua window events. We currently have some discrepancies registered in DEF-2520: Android + HTML5: missing first focus gained, Windows: getting the focus lost when focus gained, iOS: no focus lost on voice control focus.
Hello, I need your help, guys.
I have strange memory leak in .mm file:
But with this simple code:
Code:
void DefAppsFlyer_trackEvent(const char*eventName, dmArray<TrackData>* trackData)
{
NSMutableDictionary* newDict = [NSMutableDictionary dictionary];
NSString* key;
NSString* value;
TrackData data;
for(uint32_t i = 0; i != trackData->Size(); i++)
{
data = (*trackData)[i];
key = [NSString stringWithUTF8String: data.key];
value = [NSString stringWithUTF8String: data.value];
newDict[key] = value;
}
}
What I am doing wrong here?
As I understand I am using only “safe” variable creation, and they should be free-up the memory.
I have memory leak even if I leave only one line:
NSMutableDictionary* newDict = [NSMutableDictionary dictionary];
Is this my mistake? Or something works wrong?
Is that code is running on a thread other than main thread?
Does this help?
@autoreleasepool {
// your code inside method
}
Yes, it helps in situation with creation of Dictionary with Strings, but has no effect when I add SDK call:
[[AppsFlyerTracker sharedTracker] trackEvent: evName withValues: newDict];
=(
I checked with:
if ([NSThread isMainThread])
it’s the Main thread.
In cocos2d ( appsflyer sdk implementation ) I found only one autoreleasepool mentioning :
I tried the same test with Android (JNI) implementation - and it works without memory leak
void DefAppsFlyer_trackEvent(const char*eventName, dmArray<TrackData>* trackData)
{
AttachScope attachscope;
JNIEnv* env = attachscope.m_Env;
jclass hashMapClass = env->FindClass("java/util/HashMap");
jmethodID hashMapInit = env->GetMethodID(hashMapClass, "<init>", "(I)V");
jobject hashMapObj = env->NewObject(hashMapClass, hashMapInit, trackData->Size());
jmethodID hashMapId = env->GetMethodID(hashMapClass, "put","(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;");
TrackData data;
jstring key;
jstring value;
for(uint32_t i = 0; i != trackData->Size(); i++)
{
data = (*trackData)[i];
key = env->NewStringUTF(data.key);
value = env->NewStringUTF(data.value);
env->CallObjectMethod(hashMapObj, hashMapId, key, value);
env->DeleteLocalRef(key);
env->DeleteLocalRef(value);
}
jclass cls = GetClass(env, JAR_PATH);
jmethodID method = env->GetStaticMethodID(cls, "DefAppsFlyer_trackEvent","(Landroid/app/Activity;Ljava/lang/String;Ljava/util/Map;)V");
jstring jEventName = env->NewStringUTF(eventName);
-- env->CallStaticVoidMethod(cls, method, dmGraphics::GetNativeAndroidActivity(), jEventName, hashMapObj);
env->DeleteLocalRef(hashMapClass);
env->DeleteLocalRef(hashMapObj);
env->DeleteLocalRef(cls);
env->DeleteLocalRef(jEventName);
}
What’s wrong with my objC implementation?
Which version of macos SDK used on the build server?
I want to use CGDisplayBitsPerPixel but I can’t.
UPD: I found a way to get BPP from the CGDisplayModeCopyPixelEncoding string, but question about macos SDK still actual.
Currently, it’s MacOSX10.12, but I’m currently updating to MacOSX10.13, and I’m anticipating that we’ll support it with the next release. I’m also adding iPhoneOS11.2 support.
As for supporting deprecated functions, like CGDisplayBitsPerPixel, we’ll see how to deal with that in the future. The question is, if you open a 4 year old project, which at the time relied on a certain function. And now, with the latest sdk, that function isn’t even there yet (e.g. the upcoming removal of the system() function from iPhoneOS.sdk), should we support it? And how would we go about doing it? We’ll have to discuss that in the team.