Problem getting Cimgui to work
Hi guys!
I need some help or advice about Cimgui (a C-API for Imgui)
because I have no idea how to get it working.
First, I'm new to D (only a few weeks) and still learning. I have
a small C++/C# background, but wanted to try something new. So D
got into my focus.
I am working on Manjaro Linux btw.
Since 2 weeks I am working on a small project of mine to test the
SDL2 functions with derelict. Until now everything worked just
fine and I got my first window in SDL.
For this I have installed all SDL library and development files
with the package manager of Manjaro Linux. Even GLFW.
To fill the SDL window with some widgets I have decided to try
Imgui via Cimgui.
My first approach was to use the derelict-imgui version 0.9.4
over DUB.
import derelict.imgui.imgui; has been accepted yet, but
DerelictImgui.load(); not
While compiling I got the following error message:
derelict.util.exception.SharedLibLoadException@../../.dub/packages/derelict-util-3.0.0-beta.2/derelict-util/source/derelict/util/sharedlib.d(158):
Failed to load one or more shared libraries:
cimgui.so - cimgui.so: cannot open shared object file: No such
file or directory
so Cimgui was missing..
Ok, so in a second attempt I downloaded Cimgui as a ZIP and also
the Imgui files from the homepage into the appropriate directory
and unzipped them. First, the compiling via make doesn't wanted
to compile:
cimgui.cpp: In Funktion »void
ImGuiTextBuffer_append(ImGuiTextBuffer*, const char*, ...)«:
cimgui.cpp:1716:13: Fehler: »struct ImGuiTextBuffer« hat kein
Element namens »appendv«; meinten Sie »appendf«?
buffer->appendv(fmt, args);
Translated from german -> "there is no element appendv in
ImGuiTextBuffer"
So I changed the code myself on that position by replacing
"appendv" with "appendf"
That worked fine. But next problem was this:
/usr/bin/ld: ../imgui/imgui.o: relocation R_X86_64_PC32 against
symbol `_ZN6ImVec2C1Eff' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
After some research I found out it meant that the imgui files had
not been compiled with -fPIC to be used as a shared library. So I
deleted all .o files in the imgui directory and recompiled
imgui.cpp
imgui_draw.cpp and
imgui_demo.cpp
each with "g++ -c -fPIC -pie"
So I copied the new compiled .o files to the cimgui project and
recompiled it again.
This time it worked without problems :-)
The new shared library file cimgui.so moved to my project
directory and exported LD_LIBRARY_PATH so it could be found by
the compiler.
This time the compiler cried this error:
derelict.util.exception.SymbolLoadException@../../.dub/packages/derelict-util-3.0.0-beta.2/derelict-util/source/derelict/util/sharedlib.d(181):
Failed to load symbol igPushIdPtr from shared library cimgui.so
??:? void*
derelict.util.sharedlib.SharedLib.loadSymbol(immutable(char)[],
bool) [0xcfec77a6]
??:? void*
derelict.util.loader.SharedLibLoader.loadSymbol(immutable(char)[], bool) [0xcfec5cce]
??:? void derelict.util.loader.SharedLibLoader.bindFunc(void**,
immutable(char)[], bool) [0xcfec5978]
??:? void derelict.imgui.imgui.DerelictImguiLoader.loadSymbols()
[0xcfebe7a5]
??:? void
derelict.util.loader.SharedLibLoader.load(immutable(char)[][])
[0xcfec5b4e]
??:? void
derelict.util.loader.SharedLibLoader.load(immutable(char)[])
[0xcfec5ac8]
??:? void derelict.util.loader.SharedLibLoader.load() [0xcfec59ab]
??:? _Dmain [0xcfeae0af]
Program exited with code 1
After some research again I found a workaround on the Derelict
Util homepage:
import derelict.util.exception : ShouldThrow;
ShouldThrow myMissingSymbCB( string symbolName )
{
if ( symbolName == "igSetNextWindowPosCenter" ||
symbolName == "igAlignFirstTextHeightToWidgets" ||
symbolName == "igPushIdStr" ||
symbolName == "igPushIdStrRange" )
{
return ShouldThrow.No;
}
else
{
return ShouldThrow.Yes;
}
}
int main()
{
DerelictImgui.missingSymbolCallback = &myMissingSymbCB;
DerelictImgui.load();
}
But with each attempt to compile my project with "dub" by adding
the next symbol name into the list above a new symbol fails to
load. Again and again.
Since 1 week I tried several ways to get the libray to work.
Unfortunately without success.
Because I couldn't find any relevant information on the internet
about this problem I hope to get a solution here. Maybe someone
(an Cimgui expert here?) can give me a step by step instruction
how to compile the library properly ?
Thank you!
Re: Problem getting Cimgui to work
Could you describe what dub package you tried to build first of all? It helps to reproduce your case. Hello. In my personal project folder I only have: derelict-sdl2 version="~>3.1.0-alpha.2" derelict-imgui version="~>0.9.4" Then I realized that I needed the shared library file cimgui.so Unfortunately there is no DUB for Cimgui itself, so I downloaded it via ZIP + the Imgui ZIP from the homepage https://github.com/Extrawurst/cimgui/archive/master.zip and https://github.com/ocornut/imgui/archive/master.zip Extracted and copied the imgui files into the cimgui/imgui directory, because the make file of cimgui needet it. The first compiled cimgui.so file didn't work because the same problem with the symbol names at the end of my last post. So I deleted the Cimgui + Imgui directory again and cloned it by GIT this time. Compilation didn't work because of the -fPIC problem. So I compiled the imgui .cpp files by hand with "g++ -c -fPIC -pie" to be able to compile cimgui. Thats all. Thank you for your time!
Re: Problem getting Cimgui to work
On Wednesday, 6 December 2017 at 18:27:20 UTC, drug wrote: probably this can help you https://github.com/drug007/timespatial this project uses cimgui by means of derelict-imgui Hi, thank you. I tried it and first it seemed to work, but after I entered "dub build config=demo" following error messages occured: Fetching taggedalgebraic 0.10.7 (getting selected version)... Fetching msgpack-d 1.0.0-beta.6 (getting selected version)... Fetching d2sqlite3 0.9.8 (getting selected version)... Fetching gfm 6.1.4 (getting selected version)... Fetching dstats 1.0.3 (getting selected version)... Fetching emsi_containers 0.5.3 (getting selected version)... Fetching color 0.0.5 (getting selected version)... Performing "debug" build using dmd for x86_64. d2sqlite3 0.9.8: building configuration "with-lib"... derelict-util 2.0.6: target for configuration "library" is up to date. derelict-imgui ~master: building configuration "library"... DerelictImgui/source/derelict/imgui/funcs.d(38,12): Deprecation: module std.c.stdarg is deprecated - Import core.stdc.stdarg instead dstats 1.0.3: building configuration "library"... ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/regress.d(1056,8): Deprecation: dstats.summary.reduce is not visible from module regress ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/regress.d(1056,8): Deprecation: dstats.alloc.max is not visible from module regress ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/regress.d(1106,38): Deprecation: dstats.alloc.max is not visible from module regress ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/regress.d(1109,31): Deprecation: dstats.alloc.max is not visible from module regress ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/regress.d(2119,20): Deprecation: dstats.alloc.max is not visible from module regress ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/regress.d(2226,15): Deprecation: dstats.alloc.max is not visible from module regress ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/regress.d(2233,12): Deprecation: dstats.alloc.max is not visible from module regress ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(1458,24): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(1461,24): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(1501,9): Deprecation: dstats.summary.swap is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(1502,23): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(1799,24): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(1802,24): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(1821,9): Deprecation: dstats.summary.swap is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(3594,20): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(3596,20): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(3637,31): Deprecation: dstats.summary.min is not visible from module tests ../../.dub/packages/dstats-1.0.3/dstats/source/dstats/tests.d(3646,9): Deprecation: dstats.summary.swap is not visible from module tests emsi_containers 0.5.3: building configuration "library"... gfm:math 6.1.4: building configuration "library"... derelict-gl3 1.0.23: target for configuration "library" is up to date. gfm:opengl 6.1.4: building configuration "library"... derelict-sdl2 1.9.7: building configuration "library"... gfm:sdl2 6.1.4: building configuration "library"... msgpack-d 1.0.0-beta.6: building configuration "library"... taggedalgebraic 0.10.7: building configuration "library"... timespatial 0.0.3+commit.167.gd82e6dd: building configuration "demo"... DerelictImgui/source/derelict/imgui/funcs.d(38,12): Deprecation: module std.c.stdarg is deprecated - Import core.stdc.stdarg instead /usr/include/dlang/dmd/std/conv.d(4502,34): Error: cannot cast expression chunk.idx.idx of type TreeMap!(uint, DataSet, Mallocator, "a/usr/include/dlang/dmd/std/conv.d(4604,21): Error: template instance std.conv.emplace!(DataSource, DataSourceHeader) error instantiating /usr/include/dlang/dmd/std/experimental/allocator/package.d(672,52): instantiated from here: emplace!(DataSource, DataSourceHeader) demo/app.d(208,55):instantiated from here: make!(DataSource, StatsCollector!(Region!(Mallocator, 16u, cast(Flag)false), 262143LU, 262143LU)*, DataSourceHeader) source/data_index.d(143,27):instantiated from here: processElement!(Tuple!(int, "index", TaggedAlg
Re: Problem getting Cimgui to work
On Wednesday, 6 December 2017 at 19:12:43 UTC, drug wrote: I've check it before posting using old version dmd 2.073 and it works. What dmd version you compile with? Hi. The newest as I know. Version 2.077.0 (64bit Version) But the error messages in my last post don't seem to relate to my problem, but of some depricated stuff of dmd module "conv". I am now analysing your way to implement Cimgui into your project. As far as I could find out till now youre using a script to clone the whole cimgui stuff into your project directory. I didn't know that this is possible :-) The next difference I found is the -shared flag on compilation of the cimgui files. Maybe that is the big deal. And at last point loading the shared lib is totaly different. I will try it the same way. If it loads the shared library correct thats more than I could hope :-) Thank you.
Re: Problem getting Cimgui to work
On Wednesday, 6 December 2017 at 19:37:54 UTC, Thomas wrote:
On Wednesday, 6 December 2017 at 19:12:43 UTC, drug wrote:
I've check it before posting using old version dmd 2.073 and
it works.
What dmd version you compile with?
Hi. The newest as I know. Version 2.077.0 (64bit Version)
But the error messages in my last post don't seem to relate to
my problem, but of some depricated stuff of dmd module "conv".
I am now analysing your way to implement Cimgui into your
project. As far as I could find out till now youre using a
script to clone the whole cimgui stuff into your project
directory. I didn't know that this is possible :-)
The next difference I found is the -shared flag on compilation
of the cimgui files. Maybe that is the big deal.
And at last point loading the shared lib is totaly different.
I will try it the same way. If it loads the shared library
correct thats more than I could hope :-)
Thank you.
I tried it now your way. First I cloned cimgui + imgui inside my
project the same way with the build.sh script. That worked out of
the box.
Next I wrote a new app.d file only using the necessary code for
testing:
import std.stdio;
import derelict.imgui.imgui: DerelictImgui;
int main()
{
DerelictImgui.load("DerelictImgui/cimgui/cimgui/cimgui.so");
return 0;
}
After compiling with dub again the same problem with symbol names
->
"Failed to load symbol igSetNextWindowSizeConstraints from shared
library DerelictImgui/cimgui/cimgui/cimgui.so"
strange..
Re: Problem getting Cimgui to work
Hi folks!
I got it to work, but honestly I don't know why.. :-)
1. clone project imgui_d_test with git
2. subloading the base cimgui stuff by command: git submodule
update --init --recursive
3. enter cimgui directory and enter make
4. after that dub doesn't work properly, you have to edit app.d
replace DerelictImgui.load(); with
DerelictImgui.load("/..pathToFile../cimgui.so");
Now it works for me! :-)
testet on dmd 2.077.0
@drug007: I have testet the new generated cimgui.so file from
imgui_d_test project on your and mine project and it worked.
Replacing the file with the shared library generated inside my or
your project, the build will not run -> same problem with loading
the symbol names.
Hmm.. maybe they did some corrections in project imgui in the
last couple of hours ?
Whatever.. i will take the new cimgui.so file and use it.
Thank you for your time!
Re: Problem getting Cimgui to work
So the steps should be: checkout imgui 1.50 checkout cimgui 1.50 Build both Put them on your system library path Then you should be set to use DerelictIMGUI without the need to modify its package recipe. Thank you for your very very good description what was going on and how everything relate together! I will watch closely the version numbers from now on :-) Best wishes!
How to catch line number of exception without catching it ?
Hi forks!
I wanted to ask if there is a way to catch the line position on
an exception without setting a try + catch block ?
What I want is something like this:
module main;
import std.stdio;
import std.conv;
void foo()
{
scope(failure)
{
writeln("Got a failure in ", __FILE__, " ", __FUNCTION__, "!" );
// what I miss is the line position with __LINE__
}
int x = to!int("1x"); // <-- here is the exception throwing
}
int main()
{
foo();
return 0;
}
My goal is to trace the failure from the branch back to the root
like this:
(error) in "module2" at "foo2()" on line "..."
(error) in "module1" at "foo1()" on line "..."
(error) in "main" at "main()" on line "..."
I don't want to set on every function a try + catch functionality
because I think it is not a good coding style. Also I dont want
to send on every possible position where an exception/error could
happen (even when catched) the line position into an error log
function. So I got the idea of writing out modulename and
function with scope(failure) on the beginning of each function,
which works great recursive, but only the line position is
missing.
So my question is: Is there a way to catch that line where the
exception has happened without a catch ?
Or is there a better solution for tracing the error position from
root till the branch ?
Thank you for your time!
Problem with gfm.math.matrix (some gamedevs out there ?)
Hi!
I am following some examples in C++ about how OpenGL is working.
There are great tutorials out there and most of it works also
with D.
For my code I am using gfm.math.matrix (Version 8.0.3) to be able
to calculate the mouse position in a 3d world.
Now I have some problems with the projection matrix by inverting
it.
My example code:
-
import std.stdio;
int main()
{
import gfm.math.matrix;
const int width = 800;
const int height = 600;
auto projectionMatrix = mat4!(float).identity();
auto ratio = cast(float)width / cast(float)height;
projectionMatrix = mat4!(float).perspective( 45.0f, ratio,
0.0f, 100.0f );
writeln("projectionMatrix: ", projectionMatrix );
auto inversedMatrix = mat4!(float).identity();
inversedMatrix = projectionMatrix.inverse(); // <-- why this
does not work ?
writeln("inversedMatrix: ", inversedMatrix );
return 0;
}
The projection matrix will be calculated correctly with
[1.3, 0, 0, 0, 0, 1.79259, 0, 0, 0, 0, -1, -0, 0, 0, -1, 0]
assuming that the screen size is 800x600.
But using the .inverse() function in gfm returns only a matrix
with following values:
[-nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan,
-nan, -nan, -nan, -nan, inf, -inf]
I don't know what I am doing wrong here:
- do I call the function wrong way ? (but there is no other way)
- is there a bug in the function ? (I do not believe that
because the library is battle proved)
So I looked a couple of hours for an answer, but did not find
anything useful.
Is somebody out there who could help me out ? Maybe one developer
of the d gfm library ?
Thank you for you time!
Thomas
Re: Problem with gfm.math.matrix (some gamedevs out there ?)
On Thursday, 3 September 2020 at 13:31:01 UTC, Mike Parker wrote:
On Thursday, 3 September 2020 at 12:36:35 UTC, Thomas wrote:
My example code:
-
import std.stdio;
int main()
{
import gfm.math.matrix;
const int width = 800;
const int height = 600;
auto projectionMatrix = mat4!(float).identity();
auto ratio = cast(float)width / cast(float)height;
projectionMatrix = mat4!(float).perspective( 45.0f, ratio,
0.0f, 100.0f );
writeln("projectionMatrix: ", projectionMatrix );
auto inversedMatrix = mat4!(float).identity();
inversedMatrix = projectionMatrix.inverse(); // <-- why
this does not work ?
writeln("inversedMatrix: ", inversedMatrix );
return 0;
}
This is not the problem, but FYI these two lines are reduntant:
auto projectionMatrix = mat4!(float).identity();
auto inversedMatrix = mat4!(float).identity();
This is all you need:
auto projectionMatrix = mat4!(float).perspective( 45.0f, ratio,
0.0f, 100.0f );
auto inversedMatrix = projectionMatrix.inverse();
`perspective` and `inverse` return new instances that overwrite
the two identity matrices you initialized, so you're doing work
you don't need to do.
The projection matrix will be calculated correctly with
[1.3, 0, 0, 0, 0, 1.79259, 0, 0, 0, 0, -1, -0, 0, 0, -1,
0] assuming that the screen size is 800x600.
But using the .inverse() function in gfm returns only a matrix
with following values:
[-nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan, -nan,
-nan, -nan, -nan, -nan, inf, -inf]
I don't know what I am doing wrong here:
- do I call the function wrong way ? (but there is no other
way)
- is there a bug in the function ? (I do not believe that
because the library is battle proved)
My guess is the problem is in the `inverse` implementation:
https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/matrix.d#L448
T invDet = 1 / det;
It doesn't check if det is 0.
This shows 1f / 0f results in `inf`:
import std;
void main()
{
float f = 0;
float i = 1 / f;
writeln(i);
}
https://run.dlang.io/is/ZyggRg
With all those zeroes in the perspective matrix and all the
multiplications in the `inverse` function, I guess things are
getting wonky.
Thank you very much! Both of you!
Windows Service
Hi, I want to run a D program as a Windows service. After googl'in, I only found a very old project on github: https://github.com/tylerjensen/WindowsServiceInD Unfortunately, I wasn't able to compile it successfully. Does anybody know of newer approaches or even a template to start from? Thanks in advance, Thomas
Re: Windows Service
On Thursday, 15 November 2018 at 04:45:26 UTC, Soulsbane wrote: On Wednesday, 14 November 2018 at 19:38:08 UTC, Thomas wrote: Hi, I want to run a D program as a Windows service. After googl'in, I only found a very old project on github: https://github.com/tylerjensen/WindowsServiceInD Unfortunately, I wasn't able to compile it successfully. Does anybody know of newer approaches or even a template to start from? Thanks in advance, Thomas There is https://code.dlang.org/packages/daemonize I've only played with it a little on the Linux side so I'm not sure how good the windows service implementation is. I have just successfully compiled and started the hello-world example. It works (after fixing a small error) in Windows as well. Thanks a lot!
Just another question about memory management in d from a newbie
Hello!
First my background: C++ and Java ages ago. Since then only
PLSQL. Now learning D just for fun and personal education on time
to time and very pleased about it :-)
Now I have to ask a question here, because I could not find a
corresponding answer for it. Or I am unable to find it :-)
I was wondering about the memory system in D (and other C like
languages) about the handling of the memory allocation overhead.
Just an example that I have seen many times:
int main()
{
foreach(i;0 .. 1)
{
int x;
// do something with x
}
return 0;
}
Do I understand it right that the variable x will be created
1 times and destroyed at the end of the scope in each loop ?
Or will it be 1 overwritten by creation ?
I mean does it not cost the CPU some time to allocate (I know
were talking here of nsec) but work is work. As far I know from
my school days in assembler, allocation of memory is one of the
most expensive instructions on the cpu. Activate memory block,
find some free place, reserve, return pointer to caller, and so
on..
In my opinion this version should perform a little better:
int main()
{
int x;
foreach(i;0 .. 1)
{
x = 0; // reinitialize
// do something with x
}
return 0;
}
Or do I miss something and there is an optimization by the
compiler to avoid recreating/destroying the variable x 1
times ?
I know that version 1 is more secure because there will be no
value waste after each loop we could stumble onto, but that is
not my question here.
And I know that were talking about really small cpu usage
compared to what an app should do. But when it is to look on
performance like games or gui (and there are a lot of examples
like version 1 out there) then I have to ask myself if it is not
just a waste of cpu time ?
Or is it a styling of code thing ?
Thank you for your time!
Greetings from Austria
Thomas
Re: Just another question about memory management in d from a newbie
First, thank you for your fast reply! On Monday, 17 June 2019 at 20:00:34 UTC, Adam D. Ruppe wrote: No, the compiler will generate code to reuse the same thing each loop. Does this code also work on complex types like structs ?
Re: Just another question about memory management in d from a newbie
On Monday, 17 June 2019 at 20:26:28 UTC, H. S. Teoh wrote: On Mon, Jun 17, 2019 at 07:53:52PM +, Thomas via Digitalmars-d-learn wrote: [...] [...] If x were a heap-allocated object, then your concerns would be true: it would be allocated once every iteration (and also add to the garbage that the GC will have to collect later). [...] Thank you for your exact explanation on how the compiler works inside. That will clear some question that have bothered me. Thomas
