Linux port

[nem0]

• audio (missing effects) Effects will be reworked
• debug
• multiple windows no support for multiple windows on linux
• text input
• default cube fails to load
• Continuous Integration
• Command line
• bugs

[MAnyKey]

At this point I stumbled upon include dirs.
math_utils.cpp includes random:

LumixEngine/src/engine/core/math_utils.cpp

Line 4 in 94d51b0

#include <random>

which in turn includes <debug/debug.h> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/random#L43
And with added include dir "src/engine" #include <debug/debug.h includes "src/engine/debug/debug.h" https://github.com/nem0/LumixEngine/blob/94d51b06070084d1e6b9bd76077b00eea7efcdfa/src/engine/debug/debug.h and everything is screwed.
I don't know if genie has option to add include dir only for quote includes.

[nem0]

MSVS does not include <debug/debug.h> so it works on Windows. I guess we can rename debug.h to utils.h. If you have any better suggestions, I am listening.

[MAnyKey]

I thought about changing current include dirs. How about retain only "../src" and external includes? That way we hopefully add level of indirection and our own headers will not collide with system ones.

[nem0]

Sounds OK

[MAnyKey]

I found a good portion of Windows-specific code in core/mt. What do you think about replacing at least part of it with standard C++ threading code? As far as I'm concerned some of the current code contains UB (e.g. using volatile for the atomics, using union to type pun).
Plus we can save the hassle of implementing std::mutex, std::lock_guard, std::condition_variable, std::atomic<> and spinlock on non-Win platforms.

[nem0]

After all my experiences with STL (although it was years ago) I really do not like to use it anywhere. I have tried to include and the preprocessed file went from 19kB to ~950kB. Also if included in every file, compile time went from ~25s to ~45s. That being said I have no problem with STL if it's encapsulated inside one cpp, i.e. if Linux uses STL's mutex internally.

As for undefined behaviour, there are places where it is intentional, e.g. I memcpy some classes with virtual functions somewhere. We need to discuss specific places. I would like to avoid using UB, but not if cost is too high, e.g. serious performance issues.

using volatile for the atomics, using union to type pun

I am not sure which code is this about.

[MAnyKey]

For unions:
https://github.com/nem0/LumixEngine/blob/master/src/engine/core/mt/lock_free_fixed_queue.h#L52
https://github.com/nem0/LumixEngine/blob/master/src/engine/core/mt/lock_free_fixed_queue.h#L176
Dereferencing another part of union is safe in C11 but not in C++11.

for volatile:
https://github.com/nem0/LumixEngine/blob/master/src/engine/core/mt/lock_free_fixed_queue.h#L195
https://github.com/nem0/LumixEngine/blob/master/src/engine/core/mt/sync.h#L92
I'm afraid there is no safe way to create atomic integers without C++11 or C11 atomics.

Also if included in every file, compile time went from ~25s to ~45s.

I envy you 😃 , my experience with C++ compilation is much more sad.

Ok, I will try to isolate these changes from rest of the codebase.

[nem0]

Union: I think it was written by @tluqo this way for convenience. Feel free to change it if it causes any problems.
volatile: I am not sure where exactly is the problem.

I've created a wiki page about undefined behaviour, you can put there anything you find. I will also go through all the code as I do not remember where I used UB and I bet there is myriad of places with UB I do not even know about.

my experience with C++ compilation is much more sad.

My experience is terrible. I tried to download one of the other smaller open source engines and compile it and it took like 5 minutes. And it even had less features than Lumix. That's why I put forward declarations or PIMPLs everywhere, and do all the other stuff that makes the code less readable. Yes, we can use precompiled header or unity builds, but they have their own problems and I want to avoid it as long as I can.

[MAnyKey]

It seems that crunch doesn't compile on x86_64 Linux. There is a pull request richgel999/crunch#19 but it not merged since November. As an option we can fork it and reference our fork.

[nem0]

We can do that or switch from crunch to something else, I do not really care what library is used as long as it is simple, small and efficient. Do you know any better library we could use?

[nem0]

Hi, I am working on it, I will let you know as soon as it's fixed

[nem0]

@spacepluk I've commited some changes to both source code and data. Just make sure pipelines/shaderc is executable. Use forward rendering if you have a warning about unsupported blit.

You can ignore the assert in crunch library for now, it seems it causes no problems.

[spacepluk]

I forgot to mention that I had to copy gui/vera.ttg to bin/VeraMono.ttf. Now after doing that I think I'm just missing some files: https://gist.github.com/spacepluk/18ed0796e3e71a02ae45dd73e66e9594

[spacepluk]

hi there, I gave this another try today: https://gist.github.com/a79f2e2a142ea5eca915c26d31c36257

[nem0]

Hi, I have to implement mf_resource for linux and compile cmft library. I will try to fix this tonight or if it takes too much time then tomorrow.

[nem0]

It should compile now

[spacepluk]

thanks, I still can't get it to run on my system: https://gist.github.com/spacepluk/d3b6be3215ef23fd6d1bc6c88246f85e#file-studio-out-log

[nem0]

I don't have access to Linux machine now. I tried OpenGL on Windows and fixed found issues, I will try Linux on Monday probably.

[nem0]

Ok, I figured it out. All text files in pipelines/ directory (recursive) must be convertex from dos lineendings to unix lineendings

[dud3]

bash genie_linux_gcc.sh

Gives me:

genie_linux_gcc.sh: line 1: ./genie_linux: cannot execute binary file: Exec format error

[nem0]

@dud3 try to set genie_linux executable

[dud3]

@nem0
It seems like we also need sudo apt-get install g++-multilib before running make on tmp/gcc5, maybe it would be good to note them somewhere?

[dud3]

make inside tmp/gcc5 fails:

Linking app
/usr/bin/ld: cannot find -lGL
/usr/bin/ld: cannot find -lX11
collect2: error: ld returned 1 exit status
app.make:147: recipe for target 'bin/Debug/app' failed
make[1]: *** [bin/Debug/app] Error 1
Makefile:44: recipe for target 'app' failed
make: *** [app] Error 2

I've tried sudo apt-get install libgl1-mesa-dev for -lGL, but didn't work, also there are a lot of dependencies starting with libgl when searched on apt-get.

Any ideas?

[dud3]

Guessing that is 32bit issue, I'll try on 64bit some other day.

[nem0]

Added info about 64bit limitation on wiki for other people.