Question about this project's future

[Kaleidosium]

Hi, I noticed you haven't checked-in any code for the past 7 months, but are still replying to comments. I'd like to ask two things.

1. Will there be a future for this project?
2. Have you considered using LuaJIT? (The website is outdated but there's 2 active repos for it)

Thank you very much in advance.

[evanbowman]

Hi!

1. I will add any new features requested by people who want to use the library, and I'll fix bugs, but I don't have specific plans for new development tasks, except possibly adding collision checking. My future plans for this project mainly involve providing maintenance for bugfixes, unless people have feature requests, or requests for various improvements, in which case, I may add new features.

The project complies the entire lua runtime into the GBA ROM, and the build script is written in Lua, so the project should not need much maintenance going forward. Someday, I may consider migrating to a new version of Lua, but I wouldn't want to break backwards compatibility for apps built with older versions of the engine, either, and 5.3 is still widely used.

2. I considered various ways to decrease memory usage in the engine. The main obstacle to building a large gba game with this project, besides the Lua interpreter speed, is the GBA's limited RAM, and the fact that the Lua interpreter dumps bytecode into gba ram when loading scripts. I thought about allowing users to pre-compile scripts to Lua bytecode for faster startup and lower memory usage, but Lua bytecode isn't portable between platforms due to endianness and stuff like that, and I think the interpreter loads bytecode into memory if pre-compiled anyway, so there'd be minimal benefit unless I edit the Lua source code a bit. I've thought a bit about pre-compiling stuff or using jit compilation, but, the main obstacles:
   a. If the GBA ROM itself performs the jit compilation at runtime, the compiled ARM assembly code needs to be stored in RAM, a limited resource.
   b. If the JIT compilation runs outside the gba program, as a preliminary build step, LuaJIT would need to output code compatible with GCC and devkit arm (if LuaJIT even supports such a thing), so that the LuaJIT output could be linked to the engine as a static library. This would require users to set up an ARM cross compiler and link the compiled engine code to the JIT compiled Lua code, I guess? I don't know much about Lua JIT. In this hypothetical scenario, I guess I'd provide a BPCoreEnine.a (static C library) along with a linker script, and users would run some build step to link the Jitted Lua code to the engine. Can LuaJIT pre-compile code for ARM, and output a static C library? If LuaJIT could generate a static lib, with the correct calling conventions and linkage, maybe it'd be possible, idk. The only real way I envision JIT compilation working would be for the JIT to run outside of the gba program, and the goal of this project was partly to make building a gba program easier (no need to install dependencies or gcc), so I hadn't explored external JIT pre-compilation much.

If you have any suggestions for improvements, let me know, and I might consider adding things as time permits

[Kaleidosium]

1. Maybe you can try doing the stuff in the readme, that would be nice
2. LuaJIT supports Cross-compilation, although I'm not sure if this really helps or not

[Mte90]

Just reading around, I think that hitbox/collision detection can improve the interesting to this project.

About endianess yes, I tried a RE on a Xbox 360 game and had various issues on generating a bytecode compatible to change it. I think that in this case the issue is less important as usually emulators and real devices have the same endianess.

[evanbowman]

Yeah, I've been thinking about ways to add hitbox and collision stuff, the only thing I can think of would be to add an object model to the engine. Right now, the engine just lets you draw graphics manually with the spr() function.

I think I'll need to add some sort of entity/object system to do collision checking correctly. Something like this:

entity1 = ent()
ent_hitbox(entity1, {0, 0, 8, 8})
ent_spr(entity1, 0)

entity2 = ent()
ent_hitbox(entity2, {0, 0, 8, 8})
entity3 = ent()
ent_hitbox(entity2, {0, 0, 8, 8})


-- return table of collisions between entity1 and entity2 or entity3
collision_test(entity1, {entity2, entity3, ...})

-- Return table of collisions between entity and tile layer 2, with table of solid tile ids
collision_test(entity1, 2, {1, 2, 3, 5})

[Mte90]

Maybe something by image? I mean a bmp with a green screen behind and when 2 images touches the green/transparent area there is the collision.
Probably by image can create problems for rotate etc?

I see that https://github.com/drludos/meteorain-gba has something for collisions.

I am not an expert so just some thoughts.

[evanbowman]

Today I created a basic entity model and collision API:
https://github.com/evanbowman/BPCore-Engine#entities

Next I'll add support for collisions between entities and tilemaps.