LÖVE

JIT is not enabled on iOS so FFI runs poorly if at all in this platform, all other platforms don't present much problem. Also loading binary libraries in Android isn't that hard if that is what you are looking for. If not then FFI can be used without dependencies as someone stated just to make code faster with memory allocations and better structs.

Criticizing is not wrong, but is better to ask. Also if you are gonna criticize, don't be rude about it, and don't simply criticize everything you don't like, make your point about why such feature would be useful, evaluate why the developers took such decision and understand, that even if you don't like it, NO ONE CARES, the decisions are taken by the development team, which of course takes feedback, but not individual, if you want a feature try to convince everyone it's really needed, just complaining as you did, without reason at all is pointless and rude.

Also having the ability to discern if a tool is right for a job is something a great developer MUST have, if LÖVE doesn't suit your needs, go away, I'm sure you can find something better, say Electron?

Another important ability is to make a tool work the way you want it by implementing features, which I guess this is the path you will follow with GIF decoding, don't just simply go and critic that the LÖVE developers haven't done it for you, try to search for libraries, ask if someone has done it, ask why LÖVE devs took the decision not to put this feature in the framework, ask if it can be done and for directions and you will probably get more constructive answers.

That's all I have to say, I have no more intentions to continue this discussion I hope you can learn something from my feedback on your critic and sorry if I was ever rude to you, I just wanted to say that there are better ways to ask, and decisions always have a background you should try to look at.

JIT compilation is disabled by default on Android as well, because the Android OS memory allocation implementations are subpar and don't play well with how LuaJIT allocates executable memory (causing massive slowdowns when JIT compilation is enabled).

In any case, the FFI is still usable even when JIT compilation is disabled, it's just slower.

OH! Didn't know about Android, well the point actually was the FFI is still there, not sure it's as useful, being slower but still would work...

slime wrote:JIT compilation is disabled by default on Android as well, because the Android OS memory allocation implementations are subpar and don't play well with how LuaJIT allocates executable memory (causing massive slowdowns when JIT compilation is enabled).

In any case, the FFI is still usable even when JIT compilation is disabled, it's just slower.

Indeed, but FFI is disabled on iOS since you can't really use shared libraries there.

The FFI is enabled and usable on iOS (and you can use shared libraries, but even if you couldn't the FFI would still be usable).

JIT compilation is completely disabled on iOS, because Apple's App Store rules prevent apps from using executable memory for security reasons. Consoles do the same thing.

slime wrote:The FFI is enabled and usable on iOS (and you can use shared libraries, but even if you couldn't the FFI would still be usable).

JIT compilation is completely disabled on iOS, because Apple's App Store rules prevent apps from using executable memory for security reasons. Consoles do the same thing.

Its only on disabled on the stock compile because of how slow it is without jit (honestly haven't tried using interpreted FFI with just data types); and the prevention of allocating executable flagged pages is a massive downside and why all iOS browsers have to use safari's WebKit. I could swear that one of the modern consoles allowed executable memory though hm

LuaJIT's FFI isn't disabled on a stock compile of LuaJIT for iOS. It is for consoles though, I believe.

slime wrote:LuaJIT's FFI isn't disabled on a stock compile of LuaJIT for iOS. It is for consoles though, I believe.

Curious, must be a recent development (I guess new iOS does support shared libraries) because I know it hadn't for awhile, that's good news however the performance must be poor.

Keep in mind the FFI is orthogonal to loading dynamic libraries - neither depends on the other at all. It's true that the App Store didn't allow loading dynamic libraries at runtime until iOS 8, but the FFI was still enabled by default long before then, and works at runtime on much lower versions.

Note that I haven't checked into iOS having FFI enabled by default in a long time (primarily because I don't have an apple device); but a long time ago it was disabled by default. Given one can embed all the symbols into the library however you could use FFI but given the lack of JIT it'd be preferable to use the Lua C api instead.