Unable to find .so files in .love file

[ThePC007]

Sounds like a lot of work for what was meant to be nothing more than just a simple project. :/
I do have some lua code in place that performs the same exact calculations as numlua does (I use it for fast Fourier transforms), although it is quite a bit slower and, in fact, makes the game completely unplayable on my outdated Galaxy Note II. I don't know how much faster the newer generations of smartphones are, but even if they can actually run the lua code fine it might still be a good idea to at least try to get numlua to work. I'll consider it, although it definitely isn't anything I'll be doing just now.

[pgimeno]

Well, the FFT is based on FFTW3. Maybe you can leave numlua and focus on using just that library, and bind to it via FFI?

[Positive07]

Well you could search how to implement them with LuaJIT FFI, but again, try not to rely on libraries, just the standard library if possible.

You can also take a look at Lua Fun which is code designed to run as fast as it can on LuaJIT.

You could also try to thread your code, making the transformation in a separate thread and passing the results to the main thread.

You could also calculate only when needed instead of every frame.

Just some tips hope it helps!

EDIT: Well, pgimeno I wouldn't recommend trying to embed binary libraries into LÖVE for Android if you don't want to get dirty with setting up the building procedure, binding everything together, build files and even some C/C++

I would use the FFI with the standard library since the FFI is already good enough at math

[ThePC007]

Also your .so file is compiled for the specific libraries in your operating system, they may not work on other systems if the exact same dependencies are not available so your user may end up having to compile the library himself

Just wondering, what exactly is the point of a shared library then if it is this unportable and cannot be distributed? I don't really want to release a game and tell people that they need to compile the shared libraries themselves.

[Sulunia]

Sounds like a lot of work for what was meant to be nothing more than just a simple project. :/
I do have some lua code in place that performs the same exact calculations as numlua does (I use it for fast Fourier transforms), although it is quite a bit slower and, in fact, makes the game completely unplayable on my outdated Galaxy Note II. I don't know how much faster the newer generations of smartphones are, but even if they can actually run the lua code fine it might still be a good idea to at least try to get numlua to work. I'll consider it, although it definitely isn't anything I'll be doing just now.

I personally used this library for FFT in my game, so i wouldn't have to mess around with externals, but i'm quite sure it's slow. (although i use it just for visual eye candy, so no big deal)
I also tested this same game which used such FFT in a variety of new and old android devices, and it lagged even on a Samsung Galaxy Tab 3, with Intel Atom @ 1.6Ghz.
So, if you really need the FFT, i guess you're stuck with numlua, or pre calculating everything in a loading screen if possible.

[ThePC007]

Sounds like a lot of work for what was meant to be nothing more than just a simple project. :/
I do have some lua code in place that performs the same exact calculations as numlua does (I use it for fast Fourier transforms), although it is quite a bit slower and, in fact, makes the game completely unplayable on my outdated Galaxy Note II. I don't know how much faster the newer generations of smartphones are, but even if they can actually run the lua code fine it might still be a good idea to at least try to get numlua to work. I'll consider it, although it definitely isn't anything I'll be doing just now.

I personally used this library for FFT in my game, so i wouldn't have to mess around with externals, but i'm quite sure it's slow. (although i use it just for visual eye candy, so no big deal)
I also tested this same game which used such FFT in a variety of new and old android devices, and it lagged even on a Samsung Galaxy Tab 3, with Intel Atom @ 1.6Ghz.
So, if you really need the FFT, i guess you're stuck with numlua, or pre calculating everything in a loading screen if possible.

That's exactly what I am doing, too. My code supports both numlua and luafft and I can switch between both by changing a variable. But luafft is indeed way too slow for it to be useful on a mobile device. I also had the idea of simply pre-calculating everything in a loading screen, but I don't want people to have to wait for long amounts of time every time they start a new song. (Not to mention that I am going to be performing the same types of calculations on the main menu, meaning I'd technically have to add a loading screen to the main menu, which would be hilarious.)

[Sulunia]

That's exactly what I am doing, too. My code supports both numlua and luafft and I can switch between both by changing a variable. But luafft is indeed way too slow for it to be useful on a mobile device. I also had the idea of simply pre-calculating everything in a loading screen, but I don't want people to have to wait for long amounts of time every time they start a new song. (Not to mention that I am going to be performing the same types of calculations on the main menu, meaning I'd technically have to add a loading screen to the main menu, which would be hilarious.)

If your main menu always uses the same song, you could always dump these to a file (a huge one, if i was to take a guess, not recommended).
Otherwise, something i really want to test out, you can simply generate the entire song FFT information on a separate thread at once, and draw/use then on the main menu once you have it available, since threads in love2d can return tables. I've been thinking about this approach, because it should be reasonably fast to generate everything at once instead of doing so "live".

[Positive07]

Generate the entire song FFT information on a separate thread at once

Doing FFT in the main thread is crazy, FFT as sound needs to be done in parallel to the the main thread, or you would get choppy, out of sync results otherwise, plus FFT is a really heavy computation so you wouldn't want to slow everything down because of it.

FFI is not really nice on embedded devices, and interfacing C libraries is not nice in LÖVE in general, much less in the Android environment which is scary by itself.
Also providing binary libraries in Linux is always done through compilation or by using pretty common libraries found on repositories, nothing new there, if you are using Linux you should be pretty used to this stuff.

Again to me FFT is best done with threads, I would even start calculations before starting a game (say loading screen or a countdown counter) so that even if the threads is slowed down for some reason I still have some margin of time before getting out of sync. You could compute other possible FFT that may be needed soon, say the pause menu or the main menu song, the death sounds and such so that they are available exactly when you need them