Porting OXCE to the OpenPandora

[ElPoco]

Hi,

I don't know if I should post this here (since it's OXCE) or in the port section (since it's a port).
First of all, thanks for all the hard work on OXCE! It's a great platform for mods.

I'm trying to port OXCE to the OpendPandora (an ARM-based pocket computer/game console). I've got it to compile with a few changes here and there.
It starts and I was able to play a small "quick battle" of x-com 1 and start a new game and everything seemed to be working as expected. I was even able to get mods to start, though I had to set up a swapfile and the loading time was quite long.

So far I've got two main problems:

1. The game freezes when I click too far from the center of a button. If I press in the middle, it works, if I press to high/low or too far to the left or right, the button seems to register the press but nothing happens and everything is frozen (except the music that keeps playing). The device is still responsive and I can alt-tab out without any problem (when running in borderless mode). Any idea where that might come from? As far as I know I haven't changed any of the interface/menu/engine code.

2. I've noticed when running mods without a swapfile that I've got an out-of-memory error while loading sound files. I've seen that there's lazy loading for extra sprites but there doesn't seem to be for sound and music? Any reason to that? RAM usage could be lowered significantly if musics were loaded only when needed. For sound effects some caching would probably still be needed to avoid loading the shooting sound for every shot but a limited cache might be better for low-RAM devices than loading all sounds on startup.

[Yankes]

Hello,

First probably this should go to overall port thread as OXC and OXCE are close to each other than any effort porting one version can be nearly verbatim used in other. Only problem could be version of C++ used as OXC keep C++98 and OXCE use C++17 (it possible it will be bump in next year to 20 to be 3y behind standard).

1. This is probably something in your code as I don;t know what is exactly "far from the center of a button", from my perspective only input device is keyboard and mouse. If you map some native control to one of OXC you should try preserve limitations of original one, like if this "button" work as "mouse" it should not allow move pass screen.

2. Simply there was not need for this, usually graphic was is majority of memory and loading time hog, in theory it could be too lazy loaded but someone need spend time on this.

[ElPoco]

Oops, sorry I wasn't clear: when I write "to the left" it's to the left of the center of the button, but still on the button itself. And it's using the mouse cursor.

For example if I open the ufopedia from the geoscape, when I click on the "OK" button to close the window if I do it on the "OK" text itself it works but if I do it still on the button but further left or right, the game freezes.

[Yankes]

ok, you mean in-game "button", yes?
This is interesting as it all handed by engine and should not be difference between systems.
What changes you did to make this port work? maybe you make some changes that could affect it?

[ElPoco]

I've narrowed it down: it happens whenever the in-game mouse.cursor tries to move outside of the earth in the geoscape. If I zoom in, I can move the mouse anywhere without any problems. If I zoom out so that the cursor is hovering above space it works until I try to move the cursor. I can safely move the cursor anywhere on the earth but I get the freeze as soon as it moves outside.

The only changes I made outside of the Battlescape folder are:
- Using a vector of vector rather than a vector of array in Mod/RuleRegion.cpp (when loading the areas) specifying std::max<float> and std::max<double> for the calls to std::max in the AreSame mfunctions in fmath.h

Since I'm running on an ARM processor, there might also be differences in how some math operations work (especially if there's overflow involved)

[Yankes]

OXCE already work on ARM as Android or iOS, on its own it should not be problem.

Another thing now you say only about moving cursor on some place but before you mention clicking, to have this freeze only mouse move break game?
Any other action do not affect it?

[ElPoco]

I just tried:
- Zooming in the geoscape
- Moving the mouse cursor to the bottom left (Hovering over the Earth)
- Zooming out (without moving the cursor) until the cursor is outside the earth
- Clicking the mouse: nothing happens
- I've got a freeze (clock freezes, nothing responds, music keeps playing, I can still alt-tab out) if I:
-- try to move the cursor
-- open the Ufopedia (or the intercept window) with a hotkey (it opens but then the game freezes)

[ElPoco]

In other news, I've started working on a lazy loading for music and sounds.
I did a quick and dirty proof of concept and was able to start and play the 40K mod without using a swapfile, which wasn't possible before.
I didn't notice any performance issue.

It still needs some work (especially the sound part) and I've got nearly no experience with C++ (and very little with C) so it'll probably take me some time, but once I have something good enough I could create an option for it and make a pull request if you're interested.

[Yankes]

Yes, if it done correctly it could be included in OXCE or OXC

[ElPoco]

I'm making some progress on the lazy loading for sound and music. Music and ambient sounds are released on stop, for sounds I'm adding a kind of LRU cache to avoid loading common sounds every time they're needed.

I've also tested a bit further and found an other issue: when loading saves made in the battlescape, I get an "operator[] used on scalar". Saves made in the geoscape load correctly. I've done some changes in Battlescape code but it only explicit casts to float or double and mostly for calculations. I'll double-check

Is there a chance of a library/pre-requisite version mismatch? I used cmake without any change in my development environments, which has many common libs and pre-requisites and seen no error, but I'm not too familiar with C++ builds.

[Yankes]

what  "operator[] used on scalar" error is this exactly? who and where generate it?

If I should guess you mess with save code and mix type you save, and during load it try read it as different typ.

For lazy load, I would be careful with in making complex cache logic as if you release something too early then you will have hard crash.
Another problem is memory defragmentation, every time you allocate some memory and then deallocate it could leave some spaces that cannot be used again.
OXCE on its own could have this problem already as most users have more that 1GiB its invisible but on your system it could be detectable.
Best would be carefully monitored how memory usage change after long play time.


Btw, if you want better help you should at least publish your changes to github as it will allow to see what you changed.

[ElPoco]

The loading problem is due to the version of yaml-cpp I used to compile. I'll try to update to a newer version.

I wouldn't be surprised if my other problems are also due to similar issues. I'll keep debugging.

In other news, I've got a LRU cache mechanism for sounds that seems to be working. It still needs further testing, though.