ImGui LÖVE module

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

Re: ImGui löve module

Post by Fenrir » Wed Sep 07, 2016 12:04 pm

OK I updated the latest release with the Win64 build:
https://github.com/slages/love-imgui/releases/tag/0.7

It's now missing the Linux 64bit version but well, I premuse that most Linux users will anyway build it from source instead of retrieving a pre-built version.

Zireael
Party member
Posts: 139
Joined: Fri Sep 02, 2016 10:52 am

Re: ImGui LÖVE module

Post by Zireael » Wed Sep 14, 2016 9:04 am

How would one go about using it? Is this a .dll or a .lua or what? Would it be suitable for player UI (inventory, character screen) or is it only for dev-side stuff?

User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui LÖVE module

Post by Fenrir » Wed Sep 14, 2016 12:06 pm

Zireael wrote:How would one go about using it? Is this a .dll or a .lua or what? Would it be suitable for player UI (inventory, character screen) or is it only for dev-side stuff?
See the "Getting Started" section here:
https://github.com/slages/love-imgui

And about using it for in-game UI, well it depends a lot on what kind of UI you need, and how you'll use it (adapted for both keyboard/mouse and gamepad, mostly gamepad or only mouse/keyboard). But now that it supports images it can actually be used for this purpose, the biggest limitation for it is that it doesn't support (yet) custom fonts, so you can't skin it enterly for now.

User avatar
Rishavs
Party member
Posts: 103
Joined: Sat Oct 17, 2009 5:29 am
Contact:

Re: ImGui LÖVE module

Post by Rishavs » Thu Sep 15, 2016 6:50 am

quick question. Is there any performance penalty for using this?
I am currently using SUIT and would love to work with more feature heavy libs.
But performance is genrally my biggest nightmare n most stuff that I do.

User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui LÖVE module

Post by Fenrir » Thu Sep 15, 2016 7:39 am

Rishavs wrote:quick question. Is there any performance penalty for using this?
I am currently using SUIT and would love to work with more feature heavy libs.
But performance is genrally my biggest nightmare n most stuff that I do.
Well on imgui side it's super optimized and fast, but currently transfering the vertex data from imgui to LÖVE is far from optimal, there's a lot of useless buffer copies, it will require some modications to LÖVE to be able to optimize it. But anyway I'm doing quite an intensive use of it and performances is definitely not an issue so far.

User avatar
Rishavs
Party member
Posts: 103
Joined: Sat Oct 17, 2009 5:29 am
Contact:

Re: ImGui LÖVE module

Post by Rishavs » Thu Sep 15, 2016 8:25 am

Thanks. gonna try it out.

User avatar
EntranceJew
Prole
Posts: 31
Joined: Fri Apr 03, 2015 10:02 pm
Location: Saint Petersburg, Florida
Contact:

Re: ImGui LÖVE module

Post by EntranceJew » Fri Sep 16, 2016 4:07 pm

I've been using this library a fair bit lately so I have some requests, general comments, and notes -- apologies for the braindump:
  • The full imgui_demo.cpp doesn't have a lua version just yet. I attempted a full conversion, but a lot of the examples don't translate to lua so cleanly. imgui.ShowTestWindow() is a lot less helpful when it doesn't have a lua source backing it up. ;)
  • I also tried to translate the MemoryEditor example, and it works, but the FFI string buffer I wrote to prevent crossing between FFI and lua so much with data on render and the sort isn't working. Writing this buffer to allow strings to be treated more like C strings also helps keep some of the original code in place, but only if it worked.
  • I could use a list of things in the API that are / aren't supported as a reference. A bible for transliterating the C source so that I know which patterns to use where. Knowing that the clipper helper isn't exposed anywhere without doing a full walk of the imgui table would save me some time, for example.
  • I would really enjoy being able to change the path that imgui loaded / saved from. Or invoke these loads / saves manually. For sandsmas, this would make it easier to let the user save and load their settings. As well as let sandsmas let projects save and load their own imgui settings when sandsmas is emulating a love instance.
  • I know you don't exactly control this, but the Dock extension only saves settings for its original window and not any of the docked sub-windows made with BeginDock. In my case where the dock area makes up the entirety of the application, this isn't particularly useful. Do you think fixing this might be easy enough? Allowing the passthrough of some variables and the sort on everything but the floating/dragged window.
  • The sprintf version of functions don't always work with variable arguments, or maybe I'm seeing ghosts. It's usually safer to pass a table or do your own string concatenation even though this creates garbage.
  • Whenever am ImVec2, flags table, is encountered, is it safe to assume I will need to supply additional parameters and I will receive many returns? I thought this was almost universal but it felt like there were some cases that didn't work like this or that something broke in a way that I couldn't see. Maybe the code I was porting was attempting to use a function signature that didn't fully work.
  • (If I properly insulated package.* and the environment,) Would it be possible to safely sandbox this library? Right now I expose it directly to the user on the pretense that it's for debug / editor hooks only, but if they required in their own version that may or may not be the same version outside the application itself and I can see it fighting over certain things if they (don't?) share an instance.
sandsmas: A LÖVE Editor
My Libraries: Imgur, Palettes, Music Macros, Timer, Hooks

User avatar
portify
Prole
Posts: 18
Joined: Sun Feb 15, 2015 10:15 pm
Location: Locating
Contact:

Re: ImGui LÖVE module

Post by portify » Fri Oct 14, 2016 3:34 pm

Is there a way to 'properly' remove the label from an InputText?

Image

One solution I've found is PushItemWidth(GetContentRegionAvailWidth()) and PopItemWidth(), but I'm not sure if that's how I should be doing it.

I'd also like to let the scrollable region expand its height as far as it can while still leaving space for the input. Using 0 for height just makes it expand to the end of the window. Manually setting the height to GetWindowWidth() - 58 works, but I really don't want to do that. Using a height of -imgui.GetItemsLineHeightWithSpacing() works perfectly.
Last edited by portify on Fri Oct 14, 2016 3:55 pm, edited 2 times in total.

User avatar
Fenrir
Party member
Posts: 222
Joined: Wed Nov 27, 2013 9:44 am
Contact:

Re: ImGui LÖVE module

Post by Fenrir » Fri Oct 14, 2016 3:47 pm

Call:
imgui.PushItemWidth(-1)
-- Your InputBox
imgui.PopItemWidth()

It should work this way.

Zireael
Party member
Posts: 139
Joined: Fri Sep 02, 2016 10:52 am

Re: ImGui LÖVE module

Post by Zireael » Fri Oct 14, 2016 5:30 pm

I was using my own code for UI but realized I need input for character creation and movable, semi-transparent GUI dock for the hotbar with skills and the like. I think imgui would help for both but I can't tell how to actually create a list or a console window such as the one portify made...

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 4 guests