Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
ImGui new thread - Page 3 — Gideros Forum

ImGui new thread

13»

Comments

  • MoKaLuxMoKaLux Member
    edited April 17


    :-1: error: cannot find -llua
    :-1: error: cannot find -lgideros...
    collect2.exe:-1: error: error: ld returned 1 exit status

    C:/Qt/Tools/mingw530_32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -llua
    C:/Qt/Tools/mingw530_32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lgideros...
    collect2.exe: error: ld returned 1 exit status
    mingw32-make[1]: *** [debug\imgui.dll] Error 1
    mingw32-make: *** [debug] Error 2

    - I have cloned gideros github to my computer: C:\gideros\my_gideros\
    - I opened C:\gideros\my_gideros\plugins\imgui\source\Desktop\imgui.pro with Qt5.10.1 (with MinGW)


    The errors come from this line in imgui.pro:
    43 LIBS += -L"../../../../Sdk/lib/desktop" -llua -lgideros -lgid -lgvfs

    and effectively this folder is empty:
    C:\gideros\my_gideros\Sdk\lib\desktop\

    What am I missing? Any help please <3
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • rrraptorrrraptor Member
    edited April 17
    MoKaLux said:

    and effectively this folder is empty:
    C:\gideros\my_gideros\Sdk\lib\desktop\

    But it should not


    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited April 17


    ok so I copied the missing files from gideros installation folder to my gideros folder (c:/gideros/my_gideros/Sdk/lib/desktop) and that worked :) I could compile imgui.dll in both debug and release mode.
    Now I just need to copy the dll to C:\Program Files (x86)\Gideros\Plugins and test :smile: Thank you for your help rrraptor
    EDIT
    : that seems to work :)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLuxMoKaLux Member
    edited April 17
    I don't understand the magic :o
    imgui.h IMGUI_API void TextColored(const ImVec4& col, const char* fmt, ...) IM_FMTARGS(2);
    imgui.cpp ImGui::TextColored(GetStyleColorVec4(hovered_id ? ImGuiCol_Text : ImGuiCol_TextDisabled), "Click to break in debugger!");
    TextColored(ImVec4(1.0f, 0.4f, 0.4f, 1.0f), "CURRENTLY APPENDING");
    imgui_demo.cpp ImGui::TextColored(ImVec4(1.0f, 0.0f, 1.0f, 1.0f), "Pink");
    imgui_widgets.cpp
    void ImGui::TextColored(const ImVec4& col, const char* fmt, ...)
    { va_list args; va_start(args, fmt); TextColoredV(col, fmt, args); va_end(args); }
    imgui_bindings.cpp
    int TextColored(lua_State* L) {
    const char* text = luaL_checkstring(L, 2);
    ImGui::TextColored(GColor::toVec4(luaL_checkinteger(L, 3), luaL_optnumber(L, 4, 1.0f)), "%s", text);
    return 0;
    }

    Every functions seem we should call textColored(0xff0000, 1, "some text") but instead it is used like this: ImGui:textColored(text, color)!?!?
    How is this possible? I don't understand!? Is there a secret file?
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLuxMoKaLux Member
    edited April 18
    to delete!
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLuxMoKaLux Member
    edited April 18
    Ok I have tested my commit on my machine and I can say it didn't break anything :) (fixes 1 or 2 things see: https://github.com/gideros/gideros/pull/509/files)

    here is a modified imgui.dll https://github.com/mokalux/gideros_various you can paste it in your C:\Program Files (x86)\Gideros\Plugins (make a backup of the original), then call require "ImGuiX". I don't know if that works for all platforms or if I need to build those (which I don't know how to yet!)
    Let us know if you find other problems.
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLux said:


    Every functions seem we should call textColored(0xff0000, 1, "some text") but instead it is used like this: ImGui:textColored(text, color)!?!?
    How is this possible? I don't understand!? Is there a secret file?

    I thought that fmt means format (like LUA string.format), so there is "%s" followed by text argument. And from LUA side it is
    textColored("some text", 0xff0000, 1)
    Take text argument:
    const char* text = luaL_checkstring(L, 2);
    Take the color as hex
    luaL_checkinteger(L, 3)
    Take alpha
    luaL_optnumber(L, 4, 1.0f)
    Convert color to ImGui format
    GColor::toVec4(...)
  • MoKaLuxMoKaLux Member
    edited April 18
    oh yes that makes sense now that you wrote it :)
    int TextColored(lua_State* L)
    {
    const char* text = luaL_checkstring(L, 2);
    ImGui::TextColored(GColor::toVec4(luaL_checkinteger(L, 3), luaL_optnumber(L, 4, 1.0f)), "%s", text);
    return 0;
    }

    It's the lua function that wins. First argument = string (the text) and then the color (hex, alpha), and it returns nothing (int = 0). Thank you mister :)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • rrraptorrrraptor Member
    edited April 19
    Fun fact. ImGui draw lists is faster than gideros particles :D
    Particles: 1 fps (but when using imgui to show fps text, it says 7 fps, and then it slows down to 1)
    ImGui draw list: 21-24 fps
    Demo code:
    USE_IMUGI @ true -- change this line 
     
    GW @ 256
    GH @ 128
    TILE @ 4
    HTILE @ &TILE/2&
     
    require "FastNoise"
    local perlin = Noise.new()
    perlin:setNoiseType(Noise.PERLIN)
    perlin:setFrequency(0.06)
    perlin:setFractalOctaves(5)
     
    local ps = Particles.new()
    local tf = TextField.new()
    tf:setPosition(10,20)
    local timer = 0
     
     
    require "ImGui"
    local ui = ImGui.new()
    local IO = ui:getIO()
     
    if (not USE_IMUGI) then
    	stage:addChild(ps)
    	stage:addChild(tf)
    else
    	stage:addChild(ui)
    end
    -- actual area size
    local REAL = Pixel.new(0xff0000, 0.2, GW,GH)
    REAL:setY(11 * TILE)
    REAL:setScale(TILE)
    stage:addChild(REAL)
     
    local function onEnterFrame(e)
    	local dt = e.deltaTime
    	tf:setText(1//dt)
    	timer += dt
    	ps:removeParticles()
    	for y = 1, GH do 
    		for x = 1, GW do 
    			local v = (perlin:noise(x, y, timer*10)+1) / 2-- math.random(1, 5) - 1
    			if (v > 0) then 
    				local sx = (x - 1) * TILE
    				local sy = (y + 10) * TILE
    				local c = v * 255
    				ps:addParticles{{
    					x = sx + HTILE, 
    					y = sy + HTILE, 
    					size = -TILE,
    					color = ("0x%02x%02x%02x"):format(c,c,c)
    				}}
    			end
    		end
    	end
    end
    --
     
    local function onDrawGui(e)
    	ui:newFrame(e)
    	ui:value("FPS",IO:getFramerate())
     
    	local list = ui:getBackgroundDrawList()
    	for y = 1, GH do 
    		for x = 1, GW do 
    			local v = (perlin:noise(x, y, ui:getTime()*10)+1) / 2-- math.random(1, 5) - 1
    			if (v > 0) then 
    				local sx = (x - 1) * TILE
    				local sy = (y + 10) * TILE
    				local c = v * 255
    				list:addRectFilled(sx, sy, sx + TILE, sy + TILE, ("0x%02x%02x%02x"):format(c,c,c))
    			end
    		end
    	end
    	ui:render()
    	ui:endFrame()
    end
     
    local function onAppResize()
    	local minX, minY, maxX, maxY = application:getLogicalBounds()
    	local W, H = maxX - minX, maxY - minY
     
    	ui:setPosition(minX, minY)
    	IO:setDisplaySize(W, H)
    end
    --
    if (USE_IMUGI) then
    	onAppResize()
    	stage:addEventListener("enterFrame", onDrawGui)
    else
    	stage:addEventListener("enterFrame", onEnterFrame)
    end	
    stage:addEventListener("applicationResize", onAppResize)

    Also, it seems that gideros have limited amount of triangles that it can draw in a single frame because in this demo actual grid size must be 1024x512, but it shows a 1024x256 rectangle

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • hgy29hgy29 Maintainer
    rrraptor said:

    Fun fact. ImGui draw lists is faster than gideros particles :D
    ...
    Also, it seems that gideros have limited amount of triangles that it can draw in a single frame because in this demo actual grid size must be 1024x512, but it shows a 1024x256 rectangle

    Interesting. Actually the particle shader is quite convoluted, and probably not efficient for bare rectangles. That may explain the difference.

    Gideros isn't limited in number of triangles it can draw in a frame, but it is limited in number of indices it can send to the GPU in a single draw call. I thought it was 64k indices, but 512k triangles would already exceed this. Interesting issue...
  • SinisterSoftSinisterSoft Maintainer
    "glGet with argument GL_MAX_ELEMENTS_VERTICES
    glGet with argument GL_MAX_ELEMENTS_INDICES"

    https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawRangeElements.xhtml
    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
Sign In or Register to comment.