ImGui LÖVE module

Showcase your libraries, tools and other projects that help your fellow love users.
Post Reply
User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui löve module

Post by Fenrir »

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.
User avatar
airstruck
Party member
Posts: 650
Joined: Thu Jun 04, 2015 7:11 pm
Location: Not being time thief.

Re: ImGui löve module

Post by airstruck »

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?
User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui löve module

Post by Fenrir »

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?
alloyed
Citizen
Posts: 80
Joined: Thu May 28, 2015 8:45 pm
Contact:

Re: ImGui löve module

Post by alloyed »

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
User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui löve module

Post by Fenrir »

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.
User avatar
Tanner
Party member
Posts: 166
Joined: Tue Apr 10, 2012 1:51 am

Re: ImGui löve module

Post by Tanner »

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
User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui löve module

Post by Fenrir »

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.
User avatar
slime
Solid Snayke
Posts: 3129
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: ImGui löve module

Post by slime »

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.
User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui löve module

Post by Fenrir »

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.
User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui löve module

Post by Fenrir »

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. :)
Post Reply

Who is online

Users browsing this forum: No registered users and 15 guests