This is not a real issue, but more a request for help, I guess. I'm trying to setup halley in a somewhat constrained environment: inside a docker container, with noVNC for displaying.

Specifically I'm using https://gitpod.io, which makes it super easy to tinker on projects like halley (Disclaimer: I'm working for the company behind Gitpod).

With the help of the patches from lye (#37) and gurka (#44) I was able to successfully build and run ./bin/halley-editor tests/entity:

Here is a link to (a copy of) the exact environment I created the screenshot with:

Is that the expected output of the test? If yes: Are there any other test "games" I can test the setup with and start playing around with? Thanks!

I'm trying to build a Dockerfile, so far I have:

FROM ubuntu:18.04

ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update && apt-get install -y g++ gcc \
                                         cmake clang-3.9 \
                                         wget \
                                         libfreetype6 \
                                         libyaml-cpp-dev \
                                         libsdl2-dev \
                                         software-properties-common \
                                         freetype2-demos \
                                         libfreetype6-dev

# above installs cmake 3.10.2, gcc 7.3.0

# Boost
RUN wget https://dl.bintray.com/boostorg/release/1.66.0/source/boost_1_66_0.tar.gz && \
    tar -xzvf boost_1_66_0.tar.gz && \
    cd cd boost_1_66_0 && \
    ./bootstrap.sh && \
    ./b2 install

# boost header files in /usr/local/include/boost
# compiled libraries in /usr/local/lib

RUN mkdir -p /code

ADD . /code
WORKDIR /code

RUN cd src && \
    cmake -DCMAKE_INCLUDE_PATH=/usr/local/lib -DHALLEY_PATH=../halley -DBUILD_HALLEY_TOOLS=1 -DBUILD_HALLEY_TESTS=0 -DCMAKE_LIBRARY_PATH=/usr/local/lib -DBOOST_ROOT=/usr/local/include/boost .. && \
    make

Make gets somewhat far, but I error out on

[ 83%] Built target halley-asio
[ 83%] Building CXX object src/tools/tools/CMakeFiles/halley-tools.dir/src/assets/importers/config_importer.cpp.o
/code/src/tools/tools/src/assets/importers/config_importer.cpp: In static member function 'static Halley::ConfigNode Halley::ConfigImporter::parseYAMLNode(const YAML::Node&)':
/code/src/tools/tools/src/assets/importers/config_importer.cpp:50:34: error: 'const class YAML::Node' has no member named 'Mark'
  result.setOriginalPosition(node.Mark().line, node.Mark().column);
                                  ^~~~
/code/src/tools/tools/src/assets/importers/config_importer.cpp:50:52: error: 'const class YAML::Node' has no member named 'Mark'
  result.setOriginalPosition(node.Mark().line, node.Mark().column);
                                                    ^~~~
src/tools/tools/CMakeFiles/halley-tools.dir/build.make:350: recipe for target 'src/tools/tools/CMakeFiles/halley-tools.dir/src/assets/importers/config_importer.cpp.o' failed
make[2]: *** [src/tools/tools/CMakeFiles/halley-tools.dir/src/assets/importers/config_importer.cpp.o] Error 1
CMakeFiles/Makefile2:769: recipe for target 'src/tools/tools/CMakeFiles/halley-tools.dir/all' failed
make[1]: *** [src/tools/tools/CMakeFiles/halley-tools.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
root@5b23cdcb9144:/code/src# 

I tried different installations of yaml and decided it would be easiest to ask for your help! Have you seen this before?

I get the following error when trying to build halley through cmake with the following input: cmake -DBOOST_ROOT=/home/anthony/bin/boost_1_69_0/boost -DCMAKE_INCLUDE_PATH=/usr/local/include -DCMAKE_LIBRARY_PATH=/usr/local/lib .. which gives: -- The C compiler identification is GNU 7.3.0 -- The CXX compiler identification is GNU 7.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found SDL2: /usr/include/SDL2 (found version "2.0.8") -- Boost version: 1.69.0 -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so -- Found YAMLCPP: /usr/local/include -- Boost version: 1.69.0 -- Found the following Boost libraries: -- system -- filesystem -- Found Freetype: /usr/lib/x86_64-linux-gnu/libfreetype.so (found version "2.8.1") -- Configuring done -- Generating done -- Build files have been written to: /home/anthony/Documents/halley/build But when i try to make with sudo make i get the error listed in the error.txt file error.txt at 93%. The build target that causes failure is the halley-test-target. Setting this target to 0 allows for a sucessful build

Running:

• linux mint 19.1
• SDL 2.0.8
• Boost 1.69.0

Any help would be greatly appreciated! I'm quite daft.

I'm not quite sure how to run the tests, but some things I probably did wrong:

• In the AudioTest, couldn't figure out the right way to pass an AudioClip to AudioAPI::play. The original test set up a background track; pretty sure AudioAPI::play doesn't quite do that.
• In the EntityTest, during TestState::init, a World reference is stolen from a unique_ptr. There's an API mismatch wherein createWorld returns a unique_ptr<World>, but StatsView::setWorld wants an unmanaged pointer (and doesn't take ownership of it). Stealing the pointer (via unique_ptr::release/unique_ptr::reset) is terrible, but I'm not sure how the ownership semantics should work.
• In the EntityTest, the mask passed to SpritePainter::add was 0; this causes the sprite to never be drawn (via SpritePainter::draw; the getMask() & mask check fails). I'm not entirely sure what the mask does, but setting it to 1 makes something (albeit incorrect) renders. I think the assets might be out-of-date? But the animation frames don't look like they have the right texture coordinates.

I believe this fixes #32

Building on ubuntu, compiling asio_tcp_connection.cpp fails because results_type is not known:

[ 77%] Building CXX object src/plugins/asio/CMakeFiles/halley-asio.dir/src/asio_tcp_connection.cpp.o
/home/bram/src/halley/src/plugins/asio/src/asio_tcp_connection.cpp: In constructor ‘Halley::AsioTCPConnection::AsioTCPConnection(boost::asio::io_service&, Halley::String, int)’:
/home/bram/src/halley/src/plugins/asio/src/asio_tcp_connection.cpp:20:133: error: ‘boost::asio::ip::resolver<boost::asio::ip::tcp, boost::asio::ip::resolver_service<boost::asio::ip::tcp> >::results_type’ has not been declared
  resolver->async_resolve(host.cppStr(), toString(port).cppStr(), [=] (const boost::system::error_code& ec, asio::ip::tcp::resolver::results_type result)
                                                                                                                                     ^~~~~~~~~~~~
/home/bram/src/halley/src/plugins/asio/src/asio_tcp_connection.cpp: In lambda function:
/home/bram/src/halley/src/plugins/asio/src/asio_tcp_connection.cpp:25:18: error: ‘begin’ was not declared in this scope
    for (auto& r: result) {
                  ^~~~~~

Ubuntu 18.04.2 LTS yaml-cpp 0.5.2 libboost-dev 1.65.1.0

I built a barebones halley project with metal and i get this when debugging:

2021-08-05 05:01:40.728215-0500 halleyGame[4068:1865771] [plugin] AddInstanceForFactory: No factory registered for id <CFUUID 0x1011181f0> F8BB1C28-BAE8-11D6-9C31-00039315CD46
2021-08-05 05:01:40.775186-0500 halleyGame[4068:1865771]  HALC_ShellDriverPlugIn::Open: Can't get a pointer to the Open routine
2021-08-05 05:01:40.775899-0500 halleyGame[4068:1865771]  HALC_ShellDriverPlugIn::Open: Can't get a pointer to the Open routine
2021-08-05 05:01:41.164656-0500 halleyGame[4068:1865797] flock failed to lock maps file: errno = 35
2021-08-05 05:01:41.166527-0500 halleyGame[4068:1865797] flock failed to lock maps file: errno = 35

This is with the latest commit up to now

OS: Arch Linux Compiling with: cmake/gcc

/home/**/Desktop/Sources/halley/src/tests/entity/src/test_stage.cpp: In member function ‘virtual void TestStage::init()’:
/home/**/Desktop/Sources/halley/src/tests/entity/src/test_stage.cpp:8:43: error: ‘createSystem’ was not declared in this scope
    8 |  world = createWorld("sample_test_world", createSystem);

[ 83%] Building CXX object src/tools/tools/CMakeFiles/halley-tools.dir/src/assets/asset_importer.cpp.o
In file included from /home/simon/code/halley/src/tools/tools/src/assets/asset_importer.cpp:8:0:
/home/simon/code/halley/src/tools/tools/src/assets/importers/material_importer.h:3:32: fatal error: yaml-cpp/node/node.h: No such file or directory
 #include <yaml-cpp/node/node.h>
                                ^
compilation terminated.

Looking at https://github.com/amzeratul/halley/blob/master/src/tools/tools/CMakeLists.txt it looks like ${YAMLCPP_INCLUDE_DIR} is in the wrong place, in add_library instead of in include_directories.

Hi @amzeratul & contributors,

I'd like to look into building a MVP for Metal support (eventually leading to iOS) in Halley. I think this would help me learn the engine's ins and outs better, and also would future proof the engine on Mac and iOS if Apple ultimately decides to pull the OpenGL rug out.

Unfortunately, Metal does not have a C/C++ API - the only options are Objective-C or Swift. This would add an additional language to your codebase, something I imagine you're hesitant to get behind for reasons that are very understandable.

I'd be interested to know your thoughts on what the optimal layout for this kind of thing looks like. I imagine I'd take something similar to the approach of (sadly not really maintained) mtlpp, which provides Objective-C-free headers, meaning compilation will still work on platforms without Metal support, even if linking doesn't.

Really liking the look of this engine so far, and congrats on the successful launch of Wargroove.

Cheers Joel

So far it was even set to $HOME/Library which I think is not a very good default and looks a lot like it was copied over from the OS X implementation.

The XDG Base Directory Specification is out there since about 10 years or even more, so let's look up the XDG_DATA_HOME environment variable and if it's not set, fall back to ~/.local/share as in the specification.

I did this change, because I'm very much looking forward to packaging WarGroove and don't want to fix it up via binary patching or LD_PRELOAD once the game is released :smiley:

One thing to note however is that I didn't test this, as the examples are no longer in par with the current API.

OS: macOS Mojave 10.14.5

Running cmake yields the error

CMake Error at halley/src/tools/editor/CMakeLists.txt:58 (add_dependencies):
  The dependency target "halley-metal" of target "halley-editor" does not
  exist.

Metal has been disabled: https://github.com/amzeratul/halley/blob/master/cmake/HalleyProject.cmake#L146

But it is assumed to be on for Mac systems: https://github.com/amzeratul/halley/blob/master/src/tools/editor/CMakeLists.txt#L44 https://github.com/amzeratul/halley/blob/master/src/tools/editor/CMakeLists.txt#L54

Guarding by the USE_METAL variable won't work, since the code for Mac requires the Metal libraries to link to: https://github.com/amzeratul/halley/blob/master/src/tools/editor/src/halley_editor.cpp#L37

I don't think you can submit GitHub wiki changes so I guess that's the best alternative. The CMakeLists.txt template provided in the wiki ends with:

halleyProject(project_name "${SOURCES}" "${HEADERS}" "" ${CMAKE_CURRENT_SOURCE_DIR}/bin)

This actually results in building with the following error:

[build] [1/1   0% :: 0.000] Re-running CMake...
[build] CMake Error at CMakeLists.txt:25 (halleyProject):
[build]   halleyProject Function invoked with incorrect arguments for function named:
[build]   halleyProject
[build] 
[build] 
[build] -- Configuring incomplete, errors occurred!
[build] See also "/Users/douglaslassance/Desktop/WIP/halleygame/build/CMakeFiles/CMakeOutput.log".
[build] See also "/Users/douglaslassance/Desktop/WIP/halleygame/build/CMakeFiles/CMakeError.log".
[build] ninja: error: rebuilding 'build.ninja': subcommand failed
[build] FAILED: build.ninja 

The template should feature the missing argument as such:

halleyProject(project_name "${SOURCES}" "${HEADERS}" "" "" ${CMAKE_CURRENT_SOURCE_DIR}/bin)

Hey, I've stumbled over your project, and a few screenshots are always a nice introduction, but I found none for this project xD. You have a UI library, so maybe it would make sense to add a screenshot of parts of that to your Readme?

Just to attract people. Thanks, and it's just a suggestion :)

while working with the engine with my SO we encountered a couple issues while setting up our linux development environment compared to our windows.

in the halleyproject cmake, finding X11 doesn't work with find_library, only find_package (at least for us on arch)

after compiling, the shared_gen components would always contain different componentID's because of linux sorting files differently in directories, meaning instead of using the order you put in shared_gen_src of

• 0_transform
• 1_rendering
• 2_audio

it would generate them out of order however adding

std::sort(files.begin(), files.end(), [](CodegenSourceInfo a, CodegenSourceInfo b) -> bool {
return a.filename.cppStr() < b.filename.cppStr();
});

in ECSData::loadSources (src/tools/tools/src/ecs/ecs_data.cpp) seemed to work in fixing this issue for us

aside from that joystick support doesn't appear to work on linux however that for us isn't really an issue at the moment.

the reason for this ticket is just in case you weren't aware and have the changes that worked for us in case you'd like to use these in the main repo.

Xcode is stricter in its runtime Metal validation than the built executable is; this fixes the errors it was complaining about.

• Mark texture usage on descriptor
• Ensure pixel formats match up in RTT