[OLD] Old OXCE+ discussion thread

[robin]

nice, thanks!

[Meridian]

Aaaaaand, the same version for Android: OXCEPlus-v3.7a-4c5574a.apk

This one should actually be fully playable.

My test results:
- vanilla UFO and TFTD tested and working fine
- Final Mod Pack works fine... load time about 20 seconds on my device
- Xcom Files works... load time about 50 seconds on my device

The only mod, which didn't work for me was XPirateZ, which crashes after 3 minutes of loading... most likely "out of system resources".
I managed to start it once (on an emulator), but it was soul-crushingly slow and crashed soon after.
Sorry pirate fans... but there's tons of great mods to play... and don't forget: vanilla loves you.

PS: you need to uninstall OpenXcom for Android, before you install OXCE+ for Android.

[Yankes]

The only mod, which didn't work for me was XPirateZ, which crashes after 3 minutes of loading... most likely "out of system resources".
I managed to start it once (on an emulator), but it was soul-crushingly slow and crashed soon after.
Sorry pirate fans... but there's tons of great mods to play... and don't forget: vanilla loves you.

Question is if we could improve this a bit. In best case scenario there lot of low handling fruits to pick up because memory efficiency was never goal of OXC.

[Meridian]

Question is if we could improve this a bit. In best case scenario there lot of low handling fruits to pick up because memory efficiency was never goal of OXC.

I'm not sure if I am able (or willing) to do it alone... but I'd help if someone took the lead.

Assuming this would not change the whole project internal structure... that doesn't sound like a good idea to me.

[Yankes]

I think, I could look on this after 3.8, one example what I could try is made memory allocations in batches, delete earlier not used memory etc.
Small changes that could have impact of memory usage.

[Stoddard]

I think, I could look on this after 3.8, one example what I could try is made memory allocations in batches, delete earlier not used memory etc.
Small changes that could have impact of memory usage.

If it's memory usage (X-Piratez use about twice as much compared to vanilla)...

then about 65% of it are images.

Consider:

Spoiler:

Code: [Select]

96.93% (938,674,801B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->49.18% (476,277,936B) 0x5BB9193: SDL_CreateRGBSurface (in /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4)
| ->48.97% (474,181,792B) 0x628F4AB: ??? (in /usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0.8.4)
| | ->48.97% (474,181,792B) 0x628F9C6: IMG_LoadGIF_RW (in /usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0.8.4)
| |   ->48.97% (474,181,792B) 0x628D976: IMG_LoadTyped_RW (in /usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0.8.4)
| |     ->48.97% (474,181,792B) 0x873FF3: OpenXcom::Surface::loadImage(std::__cxx11::ba

->09.66% (93,530,592B) 0x871AB4: OpenXcom::Surface::Surface(int, int, int, int, int) (Surface.cpp:87)
| ->08.32% (80,529,200B) 0x86DBF2: OpenXcom::SurfaceSet::addFrame(int) (SurfaceSet.cpp:267)
| | ->08.04% (77,853,184B) 0x70F8F4: OpenXcom::Mod::loadExtraResources() (Mod.cpp:3684)
| | | ->08.04% (77,853,184B) 0x7115FF: OpenXcom::Mod::loadAll(std::vect

->08.40% (81,334,272B) 0x5BB6E37: ??? (in /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4)
| ->08.40% (81,334,272B) 0x5BB90B5: SDL_CreateRGBSurface (in /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4)
|   ->07.52% (72,775,680B) 0x5BB924F: SDL_CreateRGBSurfaceFrom (in /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4)
|   | ->07.18% (69,499,904B) 0x871B0E: OpenXcom::Surface::Surface(int, int, int, int, int) (Surface.cpp:141)
|   | | ->06.77% (65,567,744B) 0x86DBF2: OpenXcom::SurfaceSet::addFrame(int) (SurfaceSet.cpp:267)
|   | | | ->06.49% (62,806,016B) 0x70F8F4: OpenXcom::Mod::loadExtraResources() (Mod.cpp:3684)

->04.33% (41,966,416B) 0x874149: OpenXcom::Surface::loadImage(std::__cx
| ->03.82% (36,970,464B) 0x70EA96: OpenXcom::Mod::loadExtraResources() (Mod.cpp:3574)

->03.83% (37,120,120B) 0x60443E8: Mix_LoadWAV_RW (in /usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0.12.0)
| ->02.88% (27,932,976B) 0x83E435: OpenXcom::Sound::load(std::__cxx

->03.78% (36,562,600B) 0x9F68A1: YAML::detail::memory::create_node()
->01.21% (11,700,416B) 0x9F6887: YAML::detail::memory::create_node()

->06.19% (59,977,152B) 0x49193D: std::vector<OpenXcom::Cord, std::allocator<OpenXcom::Cord> >::
| ->06.19% (59,977,152B) 0x48D79E: OpenXcom::Globe::setupRadii(int, int) (stl_vector.h:676)
->10.35% (100,205,297B) in 1244 places, all below massif's threshold (1.00%)



And yaml parser is not releasing memory for some reason, but that's only about 5% of the total.

I'm not sure moving to loading images on-demand is feasible or even possible.

[Meridian]

I'm not sure what it is... that's why I used generic term resources.

I am (almost) sure, it is not an application exception, but an OS-related crash... each time I debugged (device or emulator), it simply crashed, no breakpoints. Emulator also restarted itself quite often.
The resource monitor in Android Studio didn't tell me much... actually memory usage was 2 MB according to them... which I guess was probably 2 GB... would be hilarious if they used MB instead of GB by mistake

As I said earlier, I managed to start it only on one emulated device, don't remember which one exactly... it was one of the newer tablets in default configurations.
It was hilariously slow:
- welcome screen opened for about 20 seconds... you could literally see each frame of window opening animation
- then I clicked on New Battle button... it was doing something for about a minute and then simply crashed and restarted (the whole emulator restarted, not xcom)

If anyone has experience with Android development, it would be good to look at Android version directly.
Although I think it's a resource problem, I don't think it's a simple "not enough memory" issue... probably more complicated than that

[Stoddard]

I don't think there's any difference between vanilla and X-Piratez apart from 2x memory usage, at least from the OS point of view.

Still, we need someone with Android experience here.

[Meridian]

I don't think there's any difference between vanilla and X-Piratez apart from 2x memory usage, at least from the OS point of view.

Still, we need someone with Android experience here.

2x memory usage somehow doesn't feel right... I would expect more than just 2x. Just a feeling tho, probably wrong.

Can you try also the XCom Files for comparison? (Because that works just fine.)

[Stoddard]

2x memory usage somehow doesn't feel right... I would expect more than just 2x. Just a feeling tho, probably wrong.

Can you try also the XCom Files for comparison? (Because that works just fine.)

Sure, you're right. My fault.

Vanilla UFO: 50M
Vanilla TFTD: 64M
XcomFiles: 349M
XPiratez: 840M

You can check out the valgrind+massif output at https://lxnt.wtf/oxem/#/massif

Is there any way to tell the emulator that it has 4x RAM?

EDIT: all data is for running the executable up to main menu showing up, then clicking 'quit'.

[Yankes]

Thax this will be useful for future work on this.

[Meridian]

Is there any way to tell the emulator that it has 4x RAM?

Yes, I found an option to increase RAM... and it worked.

I also used some newer phones and tested there, see below.
Until now I tested only on an old tablet... because phone's screen is just too small.

On 1 GB and 1.5 GB it always crashes.
On 2 GB, I had only one crash so far... seems to be "just enough" for playing.
On 3 GB, no crash yet.

[Meridian]

New version is up.

2017-04-24
 - "Close Quarters Combat" feature (by ohartenstein23): https://openxcom.org/forum/index.php/topic,5431.0.html
 - Displaying shotgun pellets also in ammo pedia articles
 - Indicator for items destroyed during research
 - Fixed heat vision (merge issue) -- didn't work at all since v3.5
 - Camo shouldn't affect formula for vision in smoke (I will add a better formula later)
 - Fixed infinite loop bug in research code (by karadoc)

Download: https://drive.google.com/open?id=0B8itkFQbhj-YQVdWb2R5R1U5QjA

Code: [Select]

extraStrings:
  - type: en-US
    strings:
      STR_ITEM_DESTROYED: "Item destroyed:"
      STR_FAILED_CQB_CHECK: "Failed Close Quarters Combat Check!"


[Stoddard]

New version is up.

Did you not push it to github or something? Or is it the ca2e93d one?

[Ethereal]

By the way, can you tell me more about pilots? I always wanted to introduce pilots into the game, the destination of which is mandatory for ships (without them ships do not fly), who gain experience depending on the number of downed UFOs (give different bonuses to ships), that occupy space in residential modules, but do not participate in battles landing places on ships do not occupy. And as you have them implemented? It is possible more in detail?