OSX build and Cmake improvements

[ppiecuch]

Hello, I would like to share a couple of comments from my OSX build - maybe you find something interested in these changes:

and running HLSL shader:

1. Scaling - for retina screens it seems a bit to big:

        dpi /= 96.0f;

        // enable dpi awareness     
        if (Settings::Instance().General.AutoScale) {
            Settings::Instance().DPIScale = **std::floor(dpi)**;
            Logger::Get().Log("Setting DPI to " + std::to_string(dpi));
        }

dpi is 1.375000 - looks better if round() or floor()

2. Packaging app - I am attaching simple .app template that allows you build a standard OSX GUI application:

rm -rf bin/SHADERed.app
cp -rv templates/osx_tools.app bin/SHADERed.app
mkdir -p bin/SHADERed.app/Contents/MacOS
mv bin/SHADERed bin/SHADERed.app/Contents/MacOS/SHADERed
cp -rv bin/data bin/themes bin/templates bin/plugins bin/SHADERed.app/Contents/Resources/

templates.zip

Small change to in main.cpp that changes current directory to SHADERed.app/Contents/Resources/ (propably this should be replaced with something better):

    if (argc > 0) {
#if defined(__APPLE__)
        // check if we are running from .app
        if (ghc::filesystem::exists(ghc::filesystem::path(argv[0]).parent_path().append("../Resources"))) {
            ghc::filesystem::current_path(ghc::filesystem::path(argv[0]).parent_path().append("../Resources"));

            ed::Logger::Get().Log("Setting current_path to " + ghc::filesystem::current_path().generic_string());
        }
#else
        if (ghc::filesystem::exists(ghc::filesystem::path(argv[0]).parent_path())) {
            ghc::filesystem::current_path(ghc::filesystem::path(argv[0]).parent_path());

            ed::Logger::Get().Log("Setting current_path to " + ghc::filesystem::current_path().generic_string());
        }
#endif
    }

Application is using a couple of libs I am not using and keeping them globally is something I am not fan of :) Here is a piece of CMakeLists that downloads and builds all extensions locally. Maybe you would be interested to make this as an option (Cmake 3.14 is required):

include(FetchContent)

# sdl2
FetchContent_Declare(
    sdl2
    GIT_REPOSITORY "https://github.com/SDL-mirror/SDL.git"
    GIT_TAG "release-2.0.10"
)
FetchContent_MakeAvailable(sdl2)
# prepare SDL2/ header folder
if(NOT EXISTS "${sdl2_BINARY_DIR}/include/SDL2")
    execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${sdl2_SOURCE_DIR}/include ${sdl2_BINARY_DIR}/include/SDL2)
endif()
set(SDL2_INCLUDE_DIRS ${sdl2_BINARY_DIR}/include)
set(SDL2_LIBRARY_DIRS ${sdl2_BINARY_DIR}/libs)
set(SDL2_LIBRARIES SDL2-static)

# glew
FetchContent_Declare(
    glew
    URL "https://sourceforge.net/projects/glew/files/glew/2.1.0/glew-2.1.0.zip"
)
FetchContent_GetProperties(glew)
if(NOT glew_POPULATED)
  FetchContent_Populate(glew)
  # Top level doesn't contain the CMakeLists.txt, it is in the "build/cmake" subdirectory
  add_subdirectory(${glew_SOURCE_DIR}/build/cmake ${glew_BINARY_DIR})
endif()
set(GLEW_INCLUDE_DIRS ${glew_SOURCE_DIR}/include)
set(GLEW_LIBRARY_DIRS ${glew_BINARY_DIR}/libs)
set(GLEW_LIBRARIES glew_s)

# glm
FetchContent_Declare(
  glm
  GIT_REPOSITORY "https://github.com/g-truc/glm.git"
  GIT_TAG "0.9.9.7"
)
FetchContent_MakeAvailable(glm)

set(GLM_INCLUDE_DIRS ${glm_SOURCE_DIR})
set(GLM_LIBRARY_DIRS ${glm_BINARY_DIR})

# ASSIMP
FetchContent_Declare(
    assimp
    GIT_REPOSITORY https://github.com/assimp/assimp.git
)
FetchContent_MakeAvailable(assimp)

set(ASSIMP_INCLUDE_DIR ${assimp_SOURCE_DIR}/include ${assimp_BINARY_DIR}/include)
set(ASSIMP_LIBRARY_DIR ${assimp_BINARY_DIR})
set(ASSIMP_LIBRARIES assimp)

# sfml
FetchContent_Declare(
    sfml
    GIT_REPOSITORY "https://github.com/SFML/SFML.git"
    GIT_TAG        "2.5.1"
)
FetchContent_MakeAvailable(sfml)

set(SFML_INCLUDE_DIR ${sfml_SOURCE_DIR}/include)
set(SFML_LIBRARIES sfml-system sfml-audio sfml-network sfml-graphics)

Regards Pawel

[dfranx]

Hello! Here are my thoughts:

Scaling

I think that there should be a better way to handle this. Like maybe dividing DPI by a different value to get correct scaling value? Rounding it down seems a bit extreme to me.

Packaging app

Thank you for providing the template and these steps. I would like to provide macOS builds though there is currently some feature missing from SHADERed for macOS (recompiling on file change). I think I won't be providing macOS builds until that gets implemented. This way I think it would be pretty bad UX especially since SHADERed is already pretty buggy (working to change that :sweat_smile:)

CMake update

This is absolutely cool, I didn't know something like that existed. Thanks, I'll probably apply this in one of the upcoming updates when I'll have more time to test it.

Thank you for opening this issue. I'll leave it open until I fix/implement these things.

[ppiecuch]

Small addition to packaging script - I haven't noticed that SFML installs couple of additional dependencies - they are copied now into final .app package:

#!/bin/bash

set -e

cmake -DBUILD_SHARED_LIBS=OFF ..
make

echo "*** Packaging app ..."

pushd ..

rm -rf bin/SHADERed.app
cp -rv templates/osx_tools.app bin/SHADERed.app
mkdir -p bin/SHADERed.app/Contents/MacOS
mv bin/SHADERed bin/SHADERed.app/Contents/MacOS/SHADERed
cp -rv bin/data bin/themes bin/templates bin/plugins bin/SHADERed.app/Contents/Resources/

popd

install_name_tool -add_rpath "@executable_path/../Frameworks" ../bin/SHADERed.app/Contents/MacOS/SHADERed
cp -va _deps/sfml-src/extlibs/libs-osx/Frameworks ../bin/SHADERed.app/Contents/

[krupitskas]

DPI awareness is a top priority for me, It's just HUGE and not usable with my scaling value.