Hazel

Hazel copied to clipboard

"The final" PR that brings linux support to Hazel. Previously #13 and #27

To do list

This needs to be done before this PR can become final.

• [x] Add linux support to premake file in glfw
  • [x] Update premake file in PR TheCherno/glfw#6
  • [x] Update submodule in this PR
• [x] Add linux support to premake file in imgui
  • Update premake file in PR TheCherno/imgui#5 (optional, currently not using master branch)
  • [x] Update premake file in PR TheCherno/imgui#4 (docking branch)
  • [x] Update submodule in this PR

This needs to be done before this PR can be merged.

• [x] Resolve assets not loading due to relative file path, (see https://github.com/TheCherno/Hazel/pull/82#issuecomment-523330305) ~~LovelySanta/Hazel#13~~ LovelySanta/Hazel#16

Changes in this PR

Crossed out sections where changed initialy, but reverted/fixed later.

• Refactored engine code to work on linux builds
  • HZ_DEBUGBREAK() macro
    • Instead of __debugbreak() on windows
    • Added Linux equivalent
  • Update .gitignore
    • Removing Visual Studio files (generated by premake)
    • Add linux equivalent build files to ignore list
  • ~~Seperate entrypoint for linux build~~ One entrypoint as it is the same for windows and linux
  • ~~Moving #include<glad/glad.h> around to be included before #include<GLFW/glfw3.h>~~
  • Initializing OpenGL version to OpenGL4.5
    • In ImGuiLayer
    • In WindowsWindow
• Linux build instructions
  • Updating premake5.lua in all submodules and main repo
  • Added premake5.0.0-alpha14-linux binaries to vendor/premake5
• Added basic readme
  • Basic info about Hazel with links to social platforms
  • Install instructions for premake5
  • premake instructions to compile Hazel

Impact of this PR

This closes other issues/PR's when this is merged.

• ~~Closes #27: Updates previous linux PR, this one is based on #13~~
• ~~Resolves #51: Writing the readme was started from #51 and extended~~
• Resolves #67: Initialized OpenGL compatability version (set to 4.5)
• Resolves #89: Updating submodules

Seperate entrypoint for linux build

What do you mean by entrypoint? EntryPoint.h?

Yes I mean EntryPoint.h. As Cherno said in the video where he created the entrypoint that different platforms will have different functions, I thought he ment this? For now it's just the same..

I could revert that to where it's a single function without platform precompiler stuff around it?

Not ready for merge yet, still #error "No supported window creation API selected" in the GLFW

Ready for merge, compiles and runs fine on debian for @DaveAxiom and me

In linux, we have to have the absolute path, as of now, it is not loading our assets correctly. The application is located at ./bin/Debug-[system]/Sandbox/ while the relative path is resolved to ./Sandbox/.

Possible solution:

• Create post build command to copy the assets folder into the build directory, so the assets folder is located in the same location as the executable application
• Create a static function (in application?) to get the absolute file path, so we always use absolute file paths when searching
  • static inline const std::string Application::GetApplicationDirectory()
    • return Application::s_ApplicationDirectory
    • Application::s_ApplicationDirectory holds the absolute path to the directory the application is running from
    • Application::s_ApplicationDirectory gets resolved at runtime in the constructor of Application?
      • private function where implementation depend on system?
  • static const std::string Application::ResolvePath(const std::string& path)
    • check if path is already absolute
      • if path is absolute, return path
      • if path is relative, return path prepended by Application::GetApplicationDirectory()

I still have issues with some things in this, I'll make a fork into LovelySanta:linux-support-v2 and will merge when this is working again. I'm open to other possible solutions...

That is not true, linux can use relative paths. There is no reason to complicate things like that, just make sure that your working directory contains that assets folder. I would suggest making a Run.sh file that cds in the Sandox dir and runs the Sandbox program from there.

A beter solution we foud was indeed using a relative path. But we want to keep a relative path that will also work in release mode, and more: in distribution mode, where others - who don't have source code access - it will work as well. This solution that we came up with can be found in https://github.com/LovelySanta/Hazel/pull/16, where we copy the assets folder to the bin directory, so its relative path to the exe is the same as in the distributed version.

In the future we might want to distribute our own compiled assets instead. Then we will only copy subfolders (containing uncompiled assets, for example shaders?), and others may contain compiled assets that are not copied, but build instead.

I am just waiting on @DaveAxiom to give me the green light to merge it in, but that solution is working and should always work as well.

The .ini file is for a local configuration. This file should be banished from the repository.

As the commit says, cherno wants it in there. It is not ignored in master, marian-bielcik added it to gitignore in the first place in https://github.com/TheCherno/Hazel/pull/82/commits/eed0a7b405c4803f9f877ca8a4a304a59b752d5b in this PR, so I don't want to change things cherno doesn't want changed, so I removed it from gitignore in https://github.com/TheCherno/Hazel/pull/82/commits/d0459de725ae9639fb62108c8b540c3b10c18a5f.

I believe the imgui submodule is pointing to the wrong patch.

https://github.com/TheCherno/Hazel/commit/52ff54ca80ff426e42176482444b2874280c0ad6 updates submodules to the latest commits, I might have a look later at the merge conflicts.

This Linux branch is up to date. The segmentation fault caused by a static data structure in Renderer2D was given a temporary fix. I'll be looking into if the faulty code follows the RAII standard model, or research if the code is an undefined behavior, or if it is actually a problem with GCC and why.

It is one commit behind. Adding what's in commit https://github.com/TheCherno/Hazel/commit/3d3537d34345e5e81d1e5816809e5d3edabc7237 will fix this

Edit: Now it is really out of date

Rename this to "Linux support (out of date)"

Sandbox doesn't work because of upstream architectural problems at the moment!

Cherno recently implemented open/save functionality. A native open/dialog file dialog on Linux requires the GTK library.

@caelwithcats I private messaged electrondefuser whom is adding Linux support to the Hazel-dev repository. He addressed this issue by using Zenity which I'm going to patch in. That's when I catch up with watching the videos and finish a Pull Request I've been working on! :)

@DaveAxiom Zenity is for shell scripts?

How about using TinyFileDialogs (or my own C++ rewrite of it ModernFileDialogs) ?

Maybe issue #470 should be added to the tracker to close if merged.