android-luajit-launcher
sol2
android-luajit-launcher | sol2 | |
---|---|---|
4 | 20 | |
121 | 3,956 | |
2.5% | - | |
7.5 | 3.5 | |
6 days ago | 15 days ago | |
Kotlin | C++ | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
android-luajit-launcher
-
KOReader Android 2.3.4
Android 2.3 support was dropped back in 2019, see https://github.com/koreader/android-luajit-launcher/pull/91. The current minimum supported version is 4.0.
-
KOREADER is blurry -
Here: https://github.com/koreader/android-luajit-launcher/blob/master/app/src/main/java/org/koreader/launcher/device/DeviceInfo.kt
-
How do I implement positioning recognition in Lua?
That said, I've even developed a Lua/Android bridge myself back in time (other people have much improved that since) - https://github.com/koreader/android-luajit-launcher However, that was not driven by the idea to make "things simpler" somehow. I'm not providing that reference as a suggestion you use it for your task. It was done to provide means to run an existing Lua based codebase on Android devices. If I was to develop an application for Android devices from scratch, I think I would go with the Android SDK and Android Studio, probably using Kotlin.
-
MiniVM: A minimal cross-language runtime that beats C/luajit on some benchmarks
Out of curiosity, are you planning on (progressively, slowly) rolling your own JIT, or using something like DynASM (https://luajit.org/dynasm_features.html), libFirm (https://pp.ipd.kit.edu/firm/Features.html), or some other preexisting thing (eg https://github.com/wdv4758h/awesome-jit) in the space?
FWIW, I understand that LuaJIT gets some of its insane real-world performance from a JIT and VM design that's effectively shrink-wrapped around Lua semantics/intrinsics - it's not general-purpose. I've read (unfortunately don't remember exactly where) that people have tried to run off with the JIT and VM and use it in other projects, but never succeeded because of the tight coupling.
In the same way, while a bespoke 64/32-bit x86+ARM JIT would be a reasonable undertaking, it could make for a pretty interesting target with a potentially wide-ranging set of uses.
For example, it could be the VM+JIT combination that all those people dissecting LuaJIT were looking for :).
I could see something like this becoming an attractive option for games that want an exceptionally simple runtime. Sort of like a scaled-down NekoVM (nee Haxe).
Broadly speaking, I get the (potentially incorrect) impression (from a very naive/inexperienced POV) that MiniVM+JIT would be looking to close a more widely-scoped, higher-level loop than something like libFirm would be. So it'd be closer to Cling (https://root.cern/cling/) than raw LLVM, perhaps (albeit with 0.01% of the code size :D). It is for this reason that I kind of pause for a minute and ponder that a fully integrated JIT could be a pretty good idea. It would absolutely make the irreducible complexity of the project balloon, with reasonable motivation likely necessary to maintain cohesion.
If I were to backseat-drive for a minute :) the first thing I'd rant about is how attractive modern JITs need trivial ways to verify code correctness, both online (how exactly was *this* specific generated code constructed - so, straightforward logging) but also (and particularly) offline (humans staring at the JIT source code and mentally stepping through its behavior - and succeeding (miracles!!) because the code is small and well-written). If the JIT implemented in such a straightforward manner, end users wanting to run potentially malicious user-supplied code with high performance in potentially security-sensitive settings might be attracted to the project. (Mike Pall made bank for a while while CloudFlare was using LuaJIT for its WAF... ahem...)
I came across this reference of how to break out of LuaJIT 2.1 (2015) a while back: https://www.corsix.org/content/malicious-luajit-bytecode - and every time I take a look at the code I switch away from the tab :) (and sometimes step away from the computer for a minute :D). It's solely a demonstration of "this is how it would work", and clarifies that LuaJIT makes no sandbox guarantees about the code it executes, but reading through it, the amount of Stuff™ going on represents a surface area that to me (naively) seems just... like LuaJIT as a whole is generally too large to easily reason about from a security standpoint (oh yeah, besides being written in assembly language...). This might be inexperience speaking, but I can't help but wonder whether a smaller, simpler implementation might be able to implement a secure JIT; for all I know this might be an impossible P=NP pipe dream I haven't fully grasped yet, I guess what I'm trying to figure out is whether "small enough to mentally reason through" and "large enough to do a few things quickly" have practical overlap?
---
On an unrelated note, something I discovered recently and which I thought I'd idly mention is that JITs might seem to have a bit of a hard time on Android. I can't (yet) tell if this is LuaJIT-specific or "anything that's a JIT"-specific: KOReader (Android eBook reader, implemented entirely using LuaJIT) has a bunch of very scary magic Things™ it seems to need to do to make LuaJIT even work at all on Android (https://github.com/koreader/android-luajit-launcher/blob/mas...), due to a apparently-current issue causing issues across different domains (https://github.com/LuaJIT/LuaJIT/issues/285), which has been apparently cropping up going back years (https://www.freelists.org/post/luajit/Android-performance-dr... (2013)). KOReader has even nontrivially patched LuaJIT's C code in places (https://github.com/koreader/android-luajit-launcher/blob/bb0...) with purposes I am yet to fully understand (it might just be for debugging). I happened to be considering idly playing around with Lua on Android (currently fascinated with interpreted/JITed runtimes) and after stumbling on this I'm debating whether to use Lua instead, ha. I've been meaning to ask around on the LuaJIT list and wherever KOReader discusses stuff to learn more, after focusing on actually getting LuaJIT linked into an Android project and poking around. Haven't got to it yet. This could be an absolutely massive red herring that I'm going deer-in-headlights about because it just looks off-in-the-weeds, or potentially significant. It might also be absolutely irrelevant, but as I noted I'm not (yet) sure how to tell.
sol2
-
Any tips for how to make moddable games?
As someone said, make the game data-driven is a good first step but I will say, also have some sort of way to add additional game logic. For C++ games, lua is really easy to embed the interpreter in your C++ binary, read in the files from a directory (like /mods) with the C++ filesystem api new in C++17, and it's very easy to use SoL to write an API for lua specific to your game. Many games use lua in this way and it's probably the most common mod path setup.
-
Script Interoperability
I've only ever done this from C++, but it's using the same lua C library, so should be durable from C as well. You can look up how sol2 or any other wrapper libraries do it.
-
Need help trying to embed lua in c++
Consider sol2
-
CBN Changelog: December 3, 2022. Improved LUA support in progress!
This version relies on a Lua C++ wrapper called sol2 to hide Lua stack management from the developer, so creating new bindings can be done by adding a few lines of human-readable C++. It still has to be done manually, but at least sol2 is able to automatically figure out types of objects being bound, so it's not much different from our de-/serialization code.
- RTS programming game where you write real C++ code to control your player.
-
why?
Here's an example: sol2
-
Tools for rolling your own engine
Here is link number 2 - Previous text "Sol"
-
Storing pointers to C++ data in Lua in a type-safe-ish manner that are comparable on the Lua side.
Have you considered using sol2? https://github.com/ThePhD/sol2 Or if you don't want to switch over, you can at least look at their code and see how they handle this.
-
jluna: a new Julia <-> C++ Wrapper
It is half of a pun as I was inspired by [sol3](https://github.com/ThePhD/sol2) which is a lua <-> c++ wrapper. Sol means sun and the julia c-api prefixes all it's functions with jl, luna means moon so it is pronounced "jay luna"
-
A new C++ <-> Julia Wrapper: jluna
If you want to be portable I'd recommend C++ and Lua, I used those for years and it runs on everything and there's this most amazing wrapper API which was a huge inspiration
What are some alternatives?
wasm3 - 🚀 A fast WebAssembly interpreter and the most universal WASM runtime
Lua - Lua is a powerful, efficient, lightweight, embeddable scripting language. It supports procedural programming, object-oriented programming, functional programming, data-driven programming, and data description.
LuaJIT - Mirror of the LuaJIT git repository
ChaiScript - Embedded Scripting Language Designed for C++
minivm - A VM That is Dynamic and Fast
pybind11 - Seamless operability between C++11 and Python
paka - Paka language
SWIG - SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.
awesome-jit - A curated list of awesome JIT frameworks, libraries, software and resources
Wren - The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.
kotlin-satlib - 🗿 SAT solver wrappers for Kotlin
V8 - The official mirror of the V8 Git repository