Permalink
Commits on Apr 12, 2018
  1. CMake: add C4GROUP_TOOL_ONLY

    RomainNaour committed Apr 8, 2018
    When cross-compiling c4group should be build for the host
    machine before building OpenClonk for the target.
    
    Without C4GROUP_TOOL_ONLY option, we have to build OpenClonk
    for the host.
    
    C4GROUP_TOOL_ONLY allow to build only c4group tool for the
    host.
    
    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    ---
    With this patch I can build OpenClonk with Buildroot.
  2. CMake: use FIND_PROGRAM

    RomainNaour committed Jul 21, 2017
    While cross-compiling, it is easier to find a binary
    from the patch using FIND_PROGRAM instead of using
    a cmake file.
    
    Try to find c4group native tool with FIND_PROGRAM and
    fallback to the cmake file if c4group is not found.
    
    Signed-off-by: Romain Naour <romain.naour@gmail.com>
  3. CMake: build libmisc and libc4script statically

    RomainNaour committed Jul 15, 2017
    As reported by [1], some distributions use shared libraries as
    default preset in CMake.
    
    Without explicitely linking statically libmisc and libc4script,
    we have the following link issue:
    
    [...]/host/bin/x86_64-linux-g++ --sysroot=[...]sysroot
    -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os
    -std=gnu++14 -Wall -Wextra -Wredundant-decls -Wendif-labels
    -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Winit-self
    -Wsign-promo -Wno-reorder -Wno-unused-parameter -Wnon-virtual-dtor
    -Woverloaded-virtual  -DNDEBUG
    -rdynamic CMakeFiles/c4group.dir/src/c4group/C4GroupMain.cpp.o
    -o c4group
    -Wl,-rpath,[...]/build/openclonk-7.0:
    liblibmisc.so -lz -lpthread -lrt
    liblibmisc.so : référence indéfinie vers « C4LangStringTable::Translate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const »
    liblibmisc.so : référence indéfinie vers « C4LangStringTable::system_string_table »
    
    [1] #26
    
    While at it, build libopenclonk statically since libopenclonk is not
    installed by the CMake build system.
    
    Signed-off-by: Romain Naour <romain.naour@gmail.com>
Commits on Mar 21, 2018
  1. BLAKE2: Fall back to plain C implementation on non-amd64 platforms

    isilkor committed Mar 21, 2018
    While amd64 always supports the SSE2 instruction set extension,
    other architectures don't (including 32 bit x86). For the platforms
    that don't, we'll use the reference C implementation by default, but
    allow users to override it with the BLAKE2_USE_SSE2 option.
Commits on Mar 19, 2018
  1. Squashed 'thirdparty/blake2/' content from commit beb75f451

    isilkor committed Mar 19, 2018
    git-subtree-dir: thirdparty/blake2
    git-subtree-split: beb75f4512223e6a3a03a48992345256c5ef393a
Commits on Mar 16, 2018
Commits on Mar 15, 2018
  1. moving brick: fix movement graph saving

    MDT-Maikel committed Mar 14, 2018
    Did not test all corner cases but this improves the situation for sure.
  2. remove duplicate cloud effect object

    MDT-Maikel committed Mar 14, 2018
    The particle had the same graphics as the real Cloud object and the script does not seem to have any uses. Also unused for more than 4 years.
  3. fix meteor graphics

    MDT-Maikel committed Mar 13, 2018
  4. hide some more objects in editor creation list

    MDT-Maikel committed Mar 12, 2018
    The burned object may be creatable, but must then be moved such that the libraries parent folder remains invisble in the editor.
Commits on Mar 12, 2018
Commits on Mar 5, 2018
  1. update version to 8.1

    MDT-Maikel committed Mar 5, 2018
  2. add wooden sign object

    MDT-Maikel committed Mar 4, 2018
    Graphics made by Foaly.
  3. add stone sign object

    MDT-Maikel committed Mar 3, 2018
    Graphics made by Foaly.
  4. Enable SSE2 for BLAKE2 library

    isilkor authored and MDT-Maikel committed Feb 25, 2018
  5. Add BLAKE2 library and expose its a CS hash algorithm to script

    isilkor authored and MDT-Maikel committed Feb 25, 2018
    The crypto "library" only consists of a single function at the
    moment because that's all that users have asked for so far. It is
    also highly experimental. We will make an attempt to keep the public
    interface (i.e. the interface provided by Library_Crypto.c) stable,
    but it might still change if necessary. The internal interface
    (provided via the global _Crypto proplist) is not for public
    consumption and will probably change at some point.