https://linen.dev logo
Join Discord
Powered by
imgui
# lime
t
a
nice, cool, similar to the kha example in imgui-hx
passing each frame of imgui data through the relevant gl context buffers each frame
t
yeah I think
a
the kha version, for reference
t
oh I see
https://github.com/nspitko/hlimgui/blob/84eae09bbe6f2017b30d3336ac97193d235bef69/imgui/ImGuiDrawable.hx#LL124C1-L124C5 in here, do I just buffer the data with a 
glBufferData
call, not sure what creating a new Buffer corresponds to in lime (talking about both kha and heaps)
sorry if I said anything stupid, I'm not 100% sure about what's going on
a
no worries 🙂
I'm also not 100% sure
t
🤝
a
t
ah
a
create the buffers, grab the data from imgui, buffer it
t
mm let me give this a shot
one sec
https://github.com/nspitko/hlimgui/blob/84eae09bbe6f2017b30d3336ac97193d235bef69/imgui/ImGuiDrawable.hx#LL127C1-L127C12 hm assuming 
this.vertex_buffers[i].vertices
is the count of vertices, how do you retrieve that info with lime
/opengl
a
I guess you could count the array that you created originally, e.g.
or rather, the array of vertices that exist from the previous frame of data that imgui provided
t
but I don't think I got any info about these vertices, they're prob not known at compile time https://github.com/ocornut/imgui/blob/df8667b18b5281205e15fa0254dce9f3e87dd6b2/backends/imgui_impl_opengl3.cpp#LL538C10-L538C10, that's how its in the cpp
a
what about this?
looks like it can change from one frame to the next, so would not be determinable at compile time
t
yea also vertexCount is the other value the if statement checks whether vertex_buffers[i].vertices exceeds it or not
wait I just noticed its 
<
yk what I mean
hmm thats a tricky one
a
was just setting up your rectangle demo here for hashlink
will have a little try to integrate this imgui thingy
t
👀
alright, please ping if you're not sure about something, and thankss
a
cool, I might have some questions
mostly because I haven't really played with this part of lime befor
t
yep sureee
a
@tall-teacher-57409 do you know what the lime equivalent of these are? 
h3d.Buffer
and 
h3d.Indexes
looks like 
gl.createBuffer()
is used for each but that returns 
GLBuffer
which does not have the properties needed on it
maybe need to cast GLBuffer to something else
specifically, the property I'm looking for is 
.length
t
isn't 
.length
an Array thing
a
yeah maybe can use the array of Floats/Ints
will try that
t
https://github.com/nspitko/hlimgui/blob/84eae09bbe6f2017b30d3336ac97193d235bef69/imgui/ImGuiDrawable.hx#LL123C1-L123C4 I only find one usage for it in the source file, and its already used with 
vertex_buffers
which is an array ig
was that what you meant?
a
oh sorry I didn't mean length
that line is no problem
it's this one 
vertex_buffers[i].vertices
but I think I can count the Float32Array for that value
e.g. 
var vertexData = new Float32Array(vertices);
has the vertices in it
or even the vertices array itself
ok yeah I think that might do it
t
just to make sure, you changed 
vertex_buffer
to 
Array<GlBuffer>
?
instead of 
h3d.Buffers
a
yeah
vertexBuffers is an array of GLBuffer, so is indexBuffers
and since that GLBuffer does not expose any information about what is contained, I will try using the array of Ints/Floats that is passed into each
t
ah so 
vertex_buffers[i].vertices
is the number of vertices in a 
GlBuffer
, but how do you get these vertices, 
GlBuffer
indeed does not expose a property for that
a
yeah
it's pretty much this, so I can count the raw data
will make a little type to keep these bits contained
t
aighttt
a
there might be a better way but wanna get something working first, even if it's messy
then tidy up later
t
im just not sure if you can get these vertices directly, like there's not a static array that explicitly sets these vertices somewhere in the code
a
considered even just making new buffers each frame, to keep it simple
t
yep
a
that data comes from imgui itself
t
how exactly do you retrieve it? that bit is what confused me the most
a
proto looks like this currently
Copy code
hx
var bufferCount = 0;
var vertexStride = 8;
function renderDrawList(drawData:ImDrawData) {
    bufferCount = 0;

    for(i in 0...drawData.cmdListsCount){
        var cmdList = drawData.cmdLists[i];
        var vertexCount = Std.int(cmdList.vtxBuffer.size() / (vertexStride * 4));
        var indexCount = cmdList.idxBuffer.size() >> 2;
t
o
a
which is the equivalent of
t
mhm looks good 👍
a
not sure if I will finish tonight (I am too slow today)
but it's very interesting stuff
t
lol no its totally fine, we're not in a rush lol
a
\:D yeah all good fun
t
🙂
https://github.com/ocornut/imgui/blob/df8667b18b5281205e15fa0254dce9f3e87dd6b2/backends/imgui_impl_opengl3.cpp#LL543C3-L543C20interesting interesting , so in the cpp, it buffers a 
nullptr
(3rd arg) which is the vertices paramater
starting to give up on this, its VERY locked to heaps classes, even ImGuiDrawable extends h2d.Drawable, thinking of completely revamping it for lime
a
all the graphics stuff that needs to be ported is in 
ImGuiDrawableBuffers.instance.draw
which will be specific to lime
(apart from the imgui stuff)
t
the renderDrawList too
a
and then the input handling (keyboard/mouse) will need to hook into the events from lime window
so yeah lots to port but I think a similar pattern will work
I'm quite optimistic about it actaully
always thought it would be a pain in the ass
to do the render stuff especially
but since imgui provides the buffer data it should just be a case of piping that into lime's gl context, and connecting lime input through to imgui input
t
glad you find it simple, we will hopefully get there soon 🙏
btw did you figure how to get the vertex buffer's vertices?
a
🤞
have a vague plan but need to test it still
t
aight 👍
w
I mentioned this in #501408700142059520 earlier but you should be able to use the hdll without modification; just write lime compatible variants of ImGuiDrawable and (optionally) ImGuiApp. I'm happy to take PRs for this as well, provided it's not going to add significant maintenance costs on our end.
b
I
t
yeah we're not playing with any hdlls here, just the files you mentioned
PreviousNext
Powered by