Linux build

[flibitijibibo]

Done:

http://www.flibitijibibo.com/files/OpenHexagonV1.4.tar.gz

[vittorioromeo]

Thanks!

[vittorioromeo]

I've released 1.5. Could you please make a linux build? Thanks.

[flibitijibibo]

Will be looking at this tonight. Vessel shipped a couple days ago, so I'm trying to get that all cleared up before the weekend.

[flibitijibibo]

http://www.flibitijibibo.com/files/OpenHexagonV1.51.tar.gz

Also, be sure you're updating all of your submodules in the main project. Had to git pull origin master for all of the submodules... not a big deal, but someone who wants a fully up-to-date branch will want this.

[vittorioromeo]

Thank you! I thought I had updated the submodules - isn't typing "git submodule update" in the root folder enough?

[flibitijibibo]

I think once you update all the submodules, you have to git add each folder name, then commit the result.

[tshirtman]

Those changes should be integrated so one can build directly from master :).

[vittorioromeo]

Released 1.52... could you please make some linux binaries?

[flibitijibibo]

http://www.flibitijibibo.com/files/OpenHexagonV1.52.7z

[vittorioromeo]

Thanks!

[vittorioromeo]

I've released 1.6. As always, could you make linux binaries? Thanks.

[flibitijibibo]

May take some additional time due to current workload and GitHub being borked.

If anyone has a VM hanging around, Fedora 17/18 fully updated should be able to build as long as you have the game's dependencies. And GCC, of course.

[flibitijibibo]

Update: What changed in this build? My Makefile's probably out of date, and it seems some SFML stuff changed too.

Anyone want to make a pull request for this one? Not sure if I can get all this together any time soon.

[vittorioromeo]

1.7 is now released! I've added a git tag (as suggested). Linux port is stuck to 1.52 (and old, and unstable version). Any contribution will be deeply appreciated :)

[flibitijibibo]

I've updated the OpenHexagon-Unix repository to build the current SSVOpenHexagon repository. @SuperV1234, I recommend updating the submodule so people can build out of the box.

Apologies for the disappearance, I was getting a ton of commercial ports done these last few months... Super Hexagon for Linux was one of them. :D

Here's the package: http://www.flibitijibibo.com/files/OpenHexagonV1.7.tar.gz

There's apparently a problem in the FileSystem; if you try to read from a directory that doesn't exist, the program will segfault. Using the 1.7 download I had to add the ./Profiles/ and ./Packs/VeeDefault/Sounds/ directories.

There are also a couple includes that are of concern:

First one, SSVEntitySystem/Manager.h: #include <sparsehash/dense_hash_set> Should technically be #include <google/dense_hash_set> According to the SparseHash page. This is the location in Fedora's sparsehash-devel package.

Second one, SSVLuaWrapper/LuaContext.h: #include <lua5.1/lua.h> Should technically be #include <lua.h> This applies to all the Lua includes, of course. This is also according to the Fedora lua-devel package.

Neither of these are particularly difficult to fix, but Linux users using system development packages will probably have to make these adjustments every time.

Other than these issues, this is a HUGE difference compared to 1.5! It's extremely impressive, I must say. :)

[flibitijibibo]

I just updated the OSX libs/information as well. Apple Clang does not yet support everything needed to build Open Hexagon, so you'll either have to wait for Clang to catch up or scale the engine back to support Clang.

[vittorioromeo]

Thank you for the hard work and for the feedback! I updated the submodules, and I'm uploading the Linux version on my servers. I'll look into the header issues.

Do you have any idea why the FileSystem segfaults on Linux but not on Windows?

[flibitijibibo]

Here's the backtrace:

#0  0x0000003d30eb6789 in __readdir (dirp=0x0) at ../sysdeps/unix/readdir.c:45
#1  0x000000000046c041 in ssvs::FileSystem::traverse(std::string const&, std::function<void (std::string, std::string)>) (mPath=..., mFunction=...)
    at ../SSVStart/FileSystem/FileSystem.cpp:34
#2  0x000000000046c75f in ssvs::FileSystem::getFilesByExtension (mPath=..., 
    mExtension=...) at ../SSVStart/FileSystem/FileSystem.cpp:101
#3  0x0000000000443c97 in hg::loadProfiles () at ../Global/Assets.cpp:125
#4  0x0000000000441acd in hg::loadAssets () at ../Global/Assets.cpp:48
#5  0x000000000042e970 in main (argc=1, argv=0x7fffffffdf38) at ../Main.cpp:25

I'd start looking there.

[vittorioromeo]

Thanks. Probably a "directory exists? check" will fix the problem. I'll open an issue in SSVStart.

[cocreature]

I'm not able to build it here on an uptodate Archlinux 64bit installation. The lua paths seem to be correct because lua5.2 is the default one lua5.1 is needed. I don't know C++ so I can't provide a fix to this myself. If you need more information, just tell me what you need.

make: Entering directory `/home/moritz/git/SSVOpenHexagon/Unix'
g++ -g -std=c++11 ../HexagonGame.o ../HGGraphics.o ../HGProperties.o ../HGScripting.o ../HGUpdate.o ../Main.o ../MenuGame.o ../Components/CPlayer.o ../Components/CWall.o ../Data/EventData.o ../Data/LevelData.o ../Data/MusicData.o ../Data/PackData.o ../Data/ProfileData.o ../Data/StyleData.o ../Global/Assets.o ../Global/Config.o ../Global/Factory.o ../Utils/Utils.o ../SSVStart/GameSystem/GameState.o ../SSVStart/GameSystem/GWProperties.o ../SSVStart/GameSystem/GameWindow.o ../SSVStart/Timeline/Command.o ../SSVStart/Timeline/Do.o ../SSVStart/Timeline/Go.o ../SSVStart/Timeline/Timeline.o ../SSVStart/Timeline/TimelineManager.o ../SSVStart/Timeline/Wait.o ../SSVStart/Camera/Camera.o ../SSVStart/Log/Log.o ../SSVStart/Assets/AssetManager.o ../SSVStart/Assets/AssetFolder.o ../SSVStart/FileSystem/FileSystem.o ../SSVStart/Input/InputManager.o ../SSVStart/Input/InputCombo.o ../SSVStart/Tileset/Tileset.o ../SSVStart/Utils/Utils.o ../SSVEntitySystem/Component.o ../SSVEntitySystem/Entity.o ../SSVEntitySystem/Manager.o ../SSVEntitySystem/Utils/Utils.o ../SSVLuaWrapper/LuaContext.o -o x86_64/openhexagon.x86_64 -llua libs/x86_64/libjsoncpp.a libs/x86_64/libsfml-audio.so.2 libs/x86_64/libsfml-graphics.so.2 libs/x86_64/libsfml-system.so.2 libs/x86_64/libsfml-window.so.2
../HexagonGame.o: In function `void Lua::LuaContext::_call<void, std::tuple<std::tuple<> > >(std::tuple<std::tuple<> > const&)':
/home/moritz/git/SSVOpenHexagon/Unix/../SSVLuaWrapper/LuaContext.h:279: undefined reference to `lua_pcall'
../HGScripting.o: In function `std::tuple<> Lua::LuaContext::_call<std::tuple<>, std::tuple<> >(std::tuple<> const&)':
/home/moritz/git/SSVOpenHexagon/Unix/../SSVLuaWrapper/LuaContext.h:279: undefined reference to `lua_pcall'
../HGScripting.o: In function `std::enable_if<std::numeric_limits<int>::is_integer, int>::type Lua::LuaContext::_read<int>(int, int const*) const':
/home/moritz/git/SSVOpenHexagon/Unix/../SSVLuaWrapper/LuaContext.h:687: undefined reference to `lua_tointeger'
../HGScripting.o: In function `std::enable_if<std::numeric_limits<float>::is_specialized&&(!std::numeric_limits<float>::is_integer), float>::type Lua::LuaContext::_read<float>(int, float const*) const':
/home/moritz/git/SSVOpenHexagon/Unix/../SSVLuaWrapper/LuaContext.h:698: undefined reference to `lua_tonumber'
../HGUpdate.o: In function `float Lua::LuaContext::_call<float, std::tuple<std::tuple<float> > >(std::tuple<std::tuple<float> > const&)':
/home/moritz/git/SSVOpenHexagon/Unix/../SSVLuaWrapper/LuaContext.h:279: undefined reference to `lua_pcall'
collect2: error: ld returned 1 exit status
make: *** [all] Error 1
make: Leaving directory `/home/moritz/git/SSVOpenHexagon/Unix'

[vittorioromeo]

Looks like lua is missing. Did you install lua correctly? Also, try changing #include <lua5.1/lua.h> to #include <lua.h> as flibitijibibo suggested.

[flibitijibibo]

Sounds more like an incompatibility between Lua 5.1 and 5.2.

[cocreature]

I think you missunderstood me. I have Lua 5.1 and Lua 5.2 installed. The files are installed in /usr/include/lua5.1 so the path should be correct. I don't see why it should use lua 5.2 if lua5.1 is specified in the include.

[flibitijibibo]

Change this in the Makefile:

-llua To -llua-5.1

[cocreature]

I managed to build it now by changing it to --llua5.1 However it's now segfaulting on startup. I don't know if I should open a new issue for this and if so on which repo, so I'm gonna post it here. Trying to run the game results in the following error:

* Line 1, Column 1
  Syntax error: value, object or array expected.

[CONFIG] loading config
zsh: segmentation fault (core dumped)  LD_LIBRARY_PATH=../libs/x86_64 ./openhexagon.x86_64

Here's the backtrace of gdb:

(gdb) bt
#0  0x00007ffff6838c16 in readdir64 () from /usr/lib/libc.so.6
#1  0x000000000046ba4d in ssvs::FileSystem::traverse(std::string const&, std::function<void (std::string, std::string)>) (mPath="ConfigOverrides/", mFunction=...)
    at ../SSVStart/FileSystem/FileSystem.cpp:34
#2  0x000000000046c16b in ssvs::FileSystem::getFilesByExtension (mPath="ConfigOverrides/", mExtension=".json") at ../SSVStart/FileSystem/FileSystem.cpp:101
#3  0x00000000004567df in hg::loadConfig (mOverridesIds=std::vector of length 1, capacity 1 = {...}) at ../Global/Config.cpp:33
#4  0x000000000042dc2e in main (argc=1, argv=0x7fffffffe128) at ../Main.cpp:25

[flibitijibibo]

Sounds like you don't have the game itself. I recommend just using my binary package instead.

[cocreature]

Ok thank you your binary package is working fine.

[vittorioromeo]

Hey flibitijibibo, I've released 1.8.

It is a major feature update: it adds an options menu (new dependency SSVMenuSystem), online high scores (MD5 secret key encryption that I need to give you), online version checking, and many more improvements/bugfixes.

I am adding SSVMenuSystem as a SSVOpenHexagon submodule. Let me know when feel like working on it so I can send you the encryption key.

I've also changed the #includes for sparsehash (it's now <google/... not <sparsehash/...)

[vittorioromeo]

1.81 notes: validation now gets the MD5 hashes of all LUA and JSON files related to the level. Modifying these files puts the score under another category.

[flibitijibibo]

Ran into a compiler error, if anyone wants to look at it:

g++ -g -std=c++11 -c -o ../SSVEntitySystem/Manager.o ../SSVEntitySystem/Manager.cpp -Ilibs/include -I.. -I../SSVStart -I../SSVEntitySystem -I../SSVMenuSystem -I../SSVLuaWrapper
In file included from ../SSVEntitySystem/Utils/Repository.h:11:0,
             from ../SSVEntitySystem/Manager.h:13,
             from ../SSVEntitySystem/Manager.cpp:5:
../SSVEntitySystem/Utils/Utils.h:20:46: error: ‘Repository’ is not a member of ‘sses’
../SSVEntitySystem/Utils/Utils.h:20:46: error: ‘Repository’ is not a member of ‘sses’
../SSVEntitySystem/Utils/Utils.h:20:68: error: wrong number of template arguments (1, should be 2)
In file included from ../SSVStart/Utils/MemoryManager.h:9:0,
             from ../SSVStart/Timeline/TimelineManager.h:9,
             from ../SSVStart/SSVStart.h:27,
             from ../SSVEntitySystem/Manager.h:11,
             from ../SSVEntitySystem/Manager.cpp:5:
../SSVStart/Utils/Traits/Traits.h:17:57: error: provided for ‘template<class TContainer, class TItem> struct ssvs::Utils::Traits::Container’
make: *** [../SSVEntitySystem/Manager.o] Error 1

[flibitijibibo]

Fixed it, here's the diff (SSVEntitySystem):

diff --git a/Utils/Repository.h b/Utils/Repository.h
index c58c350..56a470b 100644
--- a/Utils/Repository.h
+++ b/Utils/Repository.h
@@ -8,7 +8,6 @@
 #include <vector>
 #include <map>
 #include <string>
-#include "Utils.h"

 namespace sses
 {

[flibitijibibo]

Alrighty, so I've got the Linux version updated and happy. If you want to send the key my way (check flibitijibibo.com for my e-mail address) I can build it with that and send that your way. (Also let me know where I need to put it, haven't read the source thoroughly.)

A couple things I should point out:

• Without the Profiles/ directory we'll get a segfault when we try to make a file in there. Not so bad since we can just make a Profiles/ directory anyway, but it's worth checking that out to make the filesystem more resilient. Considering this is the Profiles directory, this might be a good time to make saves in the XDG location rather than in ./Profiles.

This is the code I use to get OSX/Linux save locations for my ports:

https://gist.github.com/flibitijibibo/5139524

Feel free to hack that as needed (probably want to change GameName to OpenHexagon).

• Inputting the profile name is tremendously difficult... something with how input events are polled maybe? Dunno how SFML input works or how it's being used in Hexagon, so :shrug:

[flibitijibibo]

Linux 1.82 with the server key:

http://www.flibitijibibo.com/files/OpenHexagonV1.82.tar.gz

The Unix submodule can be updated now.

[vittorioromeo]

Thanks, will advertise it when I get home. Online scores work, right?

[flibitijibibo]

Yup, should work just fine.

[vittorioromeo]

Alright, uploaded it on my server. Thank you for your work.

[vittorioromeo]

Flibitijibibo, sent you an email.

[flibitijibibo]

If someone's got the time this weekend to get a build of 1.83 up, definitely let us know. I'm going to be out of the office for this weekend, so I won't have access to the environment I use to build/ship OpenHexagon binaries. Otherwise, Linux 1.83 will have to wait until Monday (possibly Tuesday, depends on what I come back to).

[Mischa-Alff]

I'm working on getting an automatic build system for Linux, and Windows if MinGW through Wine allows. This'll obviously be running on a server, hopefully, soon, the same one that's hosting the website.

[flibitijibibo]

1.84 Linux: http://www.flibitijibibo.com/files/OpenHexagonV1.84.tar.gz

The Unix submodule can be updated now. Also, the SSVStart submodule needs to be updated.

[Mischa-Alff]

Is there any makefile you use to compile?

[flibitijibibo]

You mean the one in here?

https://github.com/flibitijibibo/OpenHexagon-Unix

The only difference is the spec that @SuperV1234 can give you. NDA-ish stuff.

[Mischa-Alff]

I'm aware. I hadn't noticed the makefile, though. That's really cool! (Building OH without one is a pain, and writing Makefiles is something I will never understand.)

[Mischa-Alff]

Hm, so, I've been using the recent CMake files so nicely written by Vee/SuperV1234. Being an ArchLinux user, the default include directory for jsoncpp is /usr/include/jsoncpp/json/. However, the AUR package only gives me 0.5.something, and Open Hexagon uses 0.6.0rc, so I had to go through the (fun and murderous) process of compiling and installing that.

I also realize that /usr/include/json is an important Linux library not to be trifled with, so I can't just stick the headers in there, which leaves me with putting them in /usr/include/jsoncpp/. Would it be reasonable to do:

#ifdef _WIN32
#include <json/json.h>
#include <json/reader.h>
#endif
#ifndef _WIN32
#include <jsoncpp/json.h>
#include <jsoncpp/reader.h>
#endif

? I've never done such things in my own code, so I don't know how fitting it is, but this seems like more of an important issue.

[flibitijibibo]

The directory also conflicts in Fedora too, they also went for /usr/include/jsoncpp/json/ when adding it to F18. This may just need to be updated to use #include <jsoncpp/json/...>, since we can just move directories around on Win32 and the static libs in OpenHexagon-Unix. (Though I'd like to remove that and just have SFML2 as our only included dependency.)

Of course, we could also port the JSON code to the more common json-c... :P

[Mischa-Alff]

Good to know I'm not the only one. Getting all of that to work nearly killed me. I think the end goal for this repo is to have a single repo for all platforms, instead of using submodules, hence the cmakefiles (which work quite well!). So, the question is, can we safely update the include path from <json/...> to <jsoncpp/json/...> on the main repo?

[flibitijibibo]

That change would only require that Win32 devs move their jsoncpp headers down one folder, and OpenHexagon-Unix would need to do the same thing. Not a big deal, but as long as the project uses dependencies that aren't commonly found in repos (jsoncpp RC, SFML2-Git) we'll probably need to use the lib/ folder I've got in the build environment. A transition to using system dependencies would be good, but deciding between backporting to SFML1.x and json-c and just waiting for jsoncpp/SFML2 to get adopted is where it gets messy.

[Mischa-Alff]

We could also just do the #ifdef _WIN32 stuff.

[flibitijibibo]

Actually, just updated OpenHexagon-Unix now:

https://github.com/flibitijibibo/OpenHexagon-Unix/commit/de0b02dc429e623cecf45bdde4a48aea781ba9ac

This lets us use system JsonCpp without changing the includes. Changing them is preferred, but this works for now.

Edit: Seems that there's going to be some more submodules added to SSVOpenHexagon. Don't expect upstream to build just yet.