LÖVE

Positive07 wrote:That is totally what he means. This "plugin system" he mentions is just the Lua standard way of requiring binary libraries.

Though most probably he was doing this statically and now he can do it dynamically that is why it was necessary to modify LÖVE in the first place and now a dll is needed.

Yep that's totally the standard way, but it's a bit expended allowing to require your module from love directories and implementing a loveopen_ entry point.

Fenrir wrote:implementing a loveopen_ entry point.

I don't quite understand the point of this function. The only mention I can find of it anywhere is in ticket #401. It only seems to appear on this line of the filesystem module, and it looks like the custom loader does the same thing with it that it does with luaopen_. It must not be for internal use since it doesn't appear anywhere else. I'm not sure why this is useful, unless there's some reason to create modules that Love can load but Lua can't?

I'm currently updating the module to stop using direct GL calls for rendering, and instead use LOVE for it, it works quite well but in terms of performances I can't find a way to avoid transfering the imgui vertex and index lists into a lua table and then send it to LOVE (which then transform it back to other lists used for rendering, so we iterate a lot of times through those quite big lists...).

My best shot was to try to send to LOVE "virtual" tables, by using a metatable with __index and __len methods and directly accessing the data from the buffers sent by imgui, but it seems that with lua 5.1, __len is not used on tables, so it doesn't work as the len of the table needs to be properly set to retrieve its content on LOVE side.

Would you have any other idea on how to proceed?

Fenrir wrote:I'm currently updating the module to stop using direct GL calls for rendering, and instead use LOVE for it, it works quite well but in terms of performances I can't find a way to avoid transfering the imgui vertex and index lists into a lua table and then send it to LOVE (which then transform it back to other lists used for rendering, so we iterate a lot of times through those quite big lists...).

My best shot was to try to send to LOVE "virtual" tables, by using a metatable with __index and __len methods and directly accessing the data from the buffers sent by imgui, but it seems that with lua 5.1, __len is not used on tables, so it doesn't work as the len of the table needs to be properly set to retrieve its content on LOVE side.

Would you have any other idea on how to proceed?

You can always link to liblove and use the cpp interfaces for these things. For example, these are the exported constructors for mesh objects:
https://bitbucket.org/rude/love/src/331 ... hics.h-193

alloyed wrote: You can always link to liblove and use the cpp interfaces for these things. For example, these are the exported constructors for mesh objects:
https://bitbucket.org/rude/love/src/331 ... hics.h-193

Actually it's not possible with the current sources, those classes are not exported with LOVE_EXPORT, so on Windows I can't use them without statically linking with liblove.

Fenrir wrote:I'm currently updating the module to stop using direct GL calls for rendering, and instead use LOVE for it, it works quite well but in terms of performances I can't find a way to avoid transfering the imgui vertex and index lists into a lua table and then send it to LOVE (which then transform it back to other lists used for rendering, so we iterate a lot of times through those quite big lists...).

Hard to say without knowing the complexity of those data structures but it sounds like it might be a candidate for ffi.cast. http://luajit.org/ext_ffi_api.html#ffi_cast

Tanner wrote: Hard to say without knowing the complexity of those data structures but it sounds like it might be a candidate for ffi.cast. http://luajit.org/ext_ffi_api.html#ffi_cast

There's no ffi involved here, the module is a binary one written in C++. And anyway the structure is too different to allow it.

Well I guess I'll rebuild luajit with DLUAJIT_ENABLE_LUA52COMPAT and use __len on a virtual table, and keep the current implementation as a fallback when it's not available.

EDIT: Erf just tried this solution but actually with my __len metamethod, it works on lua side and my virtual table returns the correct length, but on LOVE wrapping part, when calling lua_objlen it bypass my metamethod and just returns 0... So I think I'm stuck with my slow path for now. The best solution would be to be able to create Mesh objects from raw data (a bit like Image objects), but it will require quite some modifications on LOVE side.

Fenrir wrote:The best solution would be to be able to create Mesh objects from raw data (a bit like Image objects), but it will require quite some modifications on LOVE side.

No modifications required, LOVE already supports that.

[wiki]love.graphics.newMesh[/wiki] optionally accepts a Data object instead of a table of vertices. The contents of the memory in the Data object must have the same byte-for-byte vertex layout that's specified in the layout argument of newMesh.

Since you'll want to reuse the same Mesh instead of creating a new one over and over, [wiki]Mesh:setVertices[/wiki] also accepts a Data object as well (despite not being documented on the Wiki yet), and it works the same way as the Data object argument of newMesh. (Both of them copy the contents of the Data during the call.)

Since you can use a Data object that way, you can use ffi.cast("vertextype *", data:getPointer()) or ffi.copy(data:getPointer(), bytes, size) from Lua to write to the Data object, or pass the Data's pointer to C and write from there.

slime wrote: No modifications required, LOVE already supports that.

[wiki]love.graphics.newMesh[/wiki] optionally accepts a Data object instead of a table of vertices. The contents of the memory in the Data object must have the same byte-for-byte vertex layout that's specified in the layout argument of newMesh.

Since you'll want to reuse the same Mesh instead of creating a new one over and over, [wiki]Mesh:setVertices[/wiki] also accepts a Data object as well (despite not being documented on the Wiki yet), and it works the same way as the Data object argument of newMesh. (Both of them copy the contents of the Data during the call.)

Since you can use a Data object that way, you can use ffi.cast("vertextype *", data:getPointer()) or ffi.copy(data:getPointer(), bytes, size) from Lua to write to the Data object, or pass the Data's pointer to C and write from there.

Thanks a lot for the tip, it works! But as you can see here (line 58):
https://github.com/slages/love-imgui/bl ... i_impl.cpp
The trick I'm using is to create an ImageData to send my buffer to the mesh, as there's no MeshData or RawData objects I'm aware of. So yes my buffer is copied back into the ImageData object, the best would be to have a RawData object or something like that just storing a lightuserdata and a size without copying it back. And if it would be possible to do the same for the vertex map by using a cutom data object (as imgui is sending me an unsigned short buffer), it would be great, hehe!

And for now I'm creating a new mesh each frame, I'm getting an weird error when trying to reuse the same, I'll try to investigate on that.

Hey guys,

Just to let you know that I've made a new release removing the SDL2 dependency:
https://github.com/slages/love-imgui/releases/tag/0.4
Now it only relies on LOVE, and the only dependency to build it is lua.

I still provide pre-build binaries on the release page, but still missing a MacOSX one, so I would be really grateful is someone can send me one.