Marc, i have given a quicj look into raylib.h definition, and I saw that the entire header has ~1600 lines of code, where as the .fx which is created from that, only offers the half of that, first I thought, well its old C99 code where alot fo stuff was made differently, but this cannot like be old plain 800 LoC more than oxygene, or is your parser that efficient 
in optimizing ugly C code away haha, im serious right now, if its right how it is, fine, than yea it must be investigated anyways, but if this isnt quiet normal, that he misses so many LoC, (lines of code) than yea check that pls out aswell.
You mean the decompiled fx? Because fx itself is binary. It doesn’t contain the source anymore but the parsed and resolved structures.
If the decompiled files lack functions or definitions i would love to know
What i meant is indeed this:
Leftside = Oxygene(import.fx) : LinesOfCode = 882
Rightside = raylib.h : LinesOfCode = 1516
Roughly half of code is missing, and my question was, is this normal or does somehow the linker remove stuff which he shouldnt remove?
I have honestly no clue…
I would need to see both for myself.
If you look at the generated .pas file, all enums are on a single line. Raylib.h has lots of enums spread over multiple lines. Besides that I don’t really see anything missing. So I think that’s it (and there are no comments of course)
@ck First of all, thanks for your effort even in this time!
Second, yea I have thought so tbh, since it makes sense that C99 is really really heavily cluttered with defines and mutliple enums and other bloated stuff so I thought that Oxygene is much cleaner and hence has way less LoC than C99. Good to know!
I think, regarding your pinned holiday post, I will stop posting stuff until its over, so every1 here can rest a while and enjoy the time more. So this is my final post for now, a good Holiday I wish ya!
Feel free to post. I’m here today. (Just me)
So for importing. There are 3 issues here:
- The .lib is x86_64, the import project should also be x86_64 then (not i386, the default)
- the .lib is compiled with /GL, this generates vc++ specific code we can’t link against, disable GL (but keep the optimizations)
- The exe project is also i386, and should be x86_64
can you guard me in that regard, how can I remove GL and keep opts in? shall I create a C++ project out of that lib and go to the compilersettings?
Yes, it’s a compiler setting, /GL is default for release but shouldn’t be used.
ok let me check…
correct like this?
the first means :"maxium optimizations (prefer speed/O2)
the last means: “Optimize the entire Project (Yes/GL) —> changed to NO”
Yes.
1 Like
I prressed right click on the solution “Build Project” is this enough or do i need to do stuff with CMake now ?
Sry im not sure how these things are done in C++ projects
you should make sure the profile is set to release (and make sure GL is unset in that profiel); then build is fine yes.
ok Carlo here the update(I managed it to get it working…)
and he builts now fine with all the respected hints from you, but he says, that he couldnt execute code since he cannot find: “raylib.dll” why is he searching for the .dll? and doesnt take the included .lib ?` NearlyImportedLIB.zip (3.9 MB)
~> Process ConsoleApplication started.
~> The process failed to start with the following error: A dependent dll was not found
Im curious, ( I made sure I compile the vscproject2017) with Releasemode and for all platforms, but he somehow still puts the stuff on Debug folder??
here u can see the settings, i have compiled with those on!
then you see in the log-editor that he puts the .lib and .dll in DEBUG
Odd, why doesn’t lld complain about the architecture mismatch? ld does, and its very helpful…
Actually, sry for this Im kinda confused now, since all of that didnt work, I rebuild the “vc++ project of raylib(its only c99 in vs++)” and changed the projecttype from Debug to Release like here
- went to bin/release/raylib.lib
- grabbed it, put it to the folder of my water project (where the other .lib was b4,
- replaced it
- set all the settings to x64_x86
- checked if the .lib has the flaggs (ImportLinklibrary; CopyLocal) set,
it does
Now he prints this:
could not open ‘MSVCRT.lib’: no such file or directory
E: could not open ‘OLDNAMES.lib’: no such file or directory
I will look into this later, need some rest for now haha
PS: the above picture shows falsly the “Relase.DLL” i chose “Release” not Relase.DLL!