Executable does nothing?

[ouch67]

I'm trying to get this running on a raspberry pi. I'm not sure what kind of performance it will get and currently it compiles without error. But running the executable causes it to immediately close again without any errors or logs making this rather hard to pin down what the problem is.

[Enet4]

I'm afraid that we do not ensure compatibility with the Raspberry Pi for the time being. Can you provide us more details of your installation? Operating System, graphical environment, building tools used, etc.

[ouch67]

Yeah, I figured, but it's amazing what games those little things can run.

Anyway, it's running Raspbian (Gnome based OS) It runs the Pixel Desktop environment. (GTK Based GUI) Was built with gcc 8...ish I believe but I'll have to look into the exact version of gcc if you need it.

But as you can see it runs fairly standard stuff for linux. But it's on an ARM processor so maybe the game is looking for something like SSE2 or something ARM doesn't have?

I have a Raspberry Pi3 B+ here is the hardware specs for it: SoC: Broadcom BCM2837B0 quad-core A53 (ARMv8) 64-bit @ 1.4GHz GPU: Broadcom Videocore-IV RAM: 1GB LPDDR2 SDRAM

[Enet4]

To be fair, unless there is a system-specific quirk that we haven't discovered yet, it should be compatible with any platform that supports SDL 2. I believe the code does not rely on extended instruction sets (unless, then again, SDL 2 requires them).

The intriguing part is that the program won't output anything when run. This makes the issue pretty hard to diagnose. :(

[verhoevenv]

I've just now managed to compile and run it on a raspberry pi (I think it's a 3B+, too?) running Raspbian, using the commands in the README. We should really just put those in a shell script or something, they seem to work pretty consistently for me..

Anyway, not sure if the actual game works, as I did it over VNC and I think something weird happens with the mouse input so I can't click anything in the menu, but the main window showed so all the basics seem to be in place.

So, I'm not very sure of the next steps. Can you restart from scratch and post the output of the cmake and the make steps?

[ouch67]

it works for you? hmm... ok I made a shell script to create a new install of OpenNotrium and run it. The file is attached. The contents are:

pushd ./
cd ~
git clone https://github.com/verhoevenv/OpenNotrium.git OpenNotrium
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install cmake
sudo apt-get install build-essential libsdl2-dev libsdl2-mixer-dev libsdl2-image-dev libphysfs-dev
cd ~/OpenNotrium
mkdir build
cd build
cmake ..
make -j4
cd ..
mkdir out
cp build/OpenNotrium out
cp -r runtime_files/* out
cd out
./OpenNotrium
popd

And when run with the following command:

./notrium.sh > notrium.log

The log returns as:

~/Desktop ~/Desktop
Hit:1 http://archive.raspberrypi.org/debian stretch InRelease
Hit:2 http://pipplware.pplware.pt/pipplware/dists/stretch/main/binary ./ InRelease
Hit:3 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists...
Building dependency tree...
Reading state information...
cmake is already the newest version (3.7.2-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists...
Building dependency tree...
Reading state information...
build-essential is already the newest version (12.3).
libphysfs-dev is already the newest version (2.0.3-5).
libsdl2-image-dev is already the newest version (2.0.1+dfsg-2+deb9u1).
libsdl2-mixer-dev is already the newest version (2.0.1+dfsg1-1).
libsdl2-dev is already the newest version (2.0.8+1rpi).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.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 OpenGL: /usr/lib/arm-linux-gnueabihf/libGL.so  
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found SDL2: /usr/lib/arm-linux-gnueabihf/libSDL2main.a;/usr/lib/arm-linux-gnueabihf/libSDL2.so;-lpthread (Required is at least version "2.0") 
-- Found SDL2_mixer: /usr/lib/arm-linux-gnueabihf/libSDL2_mixer.so (found suitable version "2.0.1", minimum required is "2.0") 
-- Found SDL2_image: /usr/lib/arm-linux-gnueabihf/libSDL2_image.so (found suitable version "2.0.1", minimum required is "2.0") 
-- Found PhysFS: /usr/lib/arm-linux-gnueabihf/libphysfs.so  
-- Performing Test COMPILER_SUPPORTS_CXX11
-- Performing Test COMPILER_SUPPORTS_CXX11 - Success
-- Performing Test COMPILER_SUPPORTS_CXX0X
-- Performing Test COMPILER_SUPPORTS_CXX0X - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/OpenNotrium/build
Scanning dependencies of target OpenNotrium
[  7%] Building CXX object CMakeFiles/OpenNotrium.dir/engine.cpp.o
[ 15%] Building CXX object CMakeFiles/OpenNotrium.dir/editor.cpp.o
[ 23%] Building CXX object CMakeFiles/OpenNotrium.dir/func.cpp.o
[ 30%] Building CXX object CMakeFiles/OpenNotrium.dir/entities.cpp.o
[ 38%] Building CXX object CMakeFiles/OpenNotrium.dir/memleaks.cpp.o
[ 46%] Building CXX object CMakeFiles/OpenNotrium.dir/main.cpp.o
[ 53%] Building CXX object CMakeFiles/OpenNotrium.dir/mod_loader.cpp.o
[ 61%] Building CXX object CMakeFiles/OpenNotrium.dir/puzzle.cpp.o
[ 69%] Building CXX object CMakeFiles/OpenNotrium.dir/resource_handler.cpp.o
[ 76%] Building CXX object CMakeFiles/OpenNotrium.dir/sinecosine.cpp.o
[ 84%] Building CXX object CMakeFiles/OpenNotrium.dir/soundmanager.cpp.o
[ 92%] Building CXX object CMakeFiles/OpenNotrium.dir/text_output.cpp.o
[100%] Linking CXX executable OpenNotrium
[100%] Built target OpenNotrium
~/Desktop

The log is attached as well. But the problem still remains. It opens then closes immediately with no errors or anything... Is there a way to force the game to log stuff?

Also if relevant here is my pi's gcc version info:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 6.3.0-18+rpi1+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1) 

And how to check what pi hardware you have can be found here: http://ozzmaker.com/check-raspberry-software-hardware-version-command-line/

But your pi in that pic has a maxed out processor which is probably why clicks were not registering. And also likely means that this is one of those odd games that doesn't look like it would be very taxing on a pi but is for some reason.

notrium.zip notriumlog.zip

[verhoevenv]

I have the exact same versions of pretty much everything, and using your script, the game builds and runs for me. The output of the build process is also pretty much the same. That's about as much as I can do, I'm afraid..

Some other things I can think of that might be causing problems

• We attempt to write a config folder in ~/.monkkonen, so if that's not allowed things could break.
• Some localisation feature of the pi or debian might somehow cause something to act differently (from the Preferences > Raspberry Pi Configuration > Localisation menu, mine is set to en-US and charset UTF-8)
• There could be other things running on your pi that eat tons of memory, which causes a memory allocation to fail.
• Things that hijack some other resource that we need, but I wouldn't know what those could be.

For each of those things I would at least expect to see some error messages, but this game hasn't really been programmed with a lot of diagnostics or fail-safes built in, so who knows.

We do write out some debug log, but it's not very useful and mainly talks about resource loading. The file is debug_start.txt and it should be created in the working directory (so that would be in ~/OpenNotrium/out). Execution might stop before you get to the first log line, though, so the file might even not be there, or the content might not flush properly.

If you want to dig deeper, you can look into debugging (I suppose using gdb, it's been ages since I did anything with it so I can't help too much) or start adding console log lines to figure out where it breaks, if it even gets anywhere. The entry point of the program is at main.cpp#L559

[ouch67]

So if I turn on OpenGL I get a window and can hear music but the screen is blank...

So progress I guess? lol

[verhoevenv]

Ah. We do use OpenGL for rendering, yes. It turns out that OpenGL on the pi is a more complicated situation than I would have expected. Interesting!

Can you post the output of uname -a, cat /etc/os-release and glxinfo? This is my output, if you're interested. I don't know yet what most of it means, but it might be interesting to see if there are differences, and to find out more.

Also, glxgears did not look quite as I was expecting it to... I wonder what Notrium will look like when it's actually running.

[verhoevenv]

Theoretically, we could look into software rendering, as it's about the only part of the game that is properly encapsulated. 😄

But honestly, I don't think there's a lot of platforms out there that would profit from that. Apparently some raspberry pi's, and I can imagine the older ones have even worse OpenGL support. I've also heard bad things about macOS and OpenGL, but I don't think software rendering is the right step there.

[ouch67]

well uname -a: Linux raspberrypi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

cat /etc/os-release: PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)" NAME="Raspbian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

and for glxinfo: out.log

So what is interesting is here is a bit of your glxinfo:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: VMware, Inc. (0xffffffff)
    Device: llvmpipe (LLVM 3.9, 128 bits) (0xffffffff)
    Version: 13.0.6
    Accelerated: no
    Video memory: 732MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

Which says it's not accelerated... So do you not have opengl on and it's working? additionally it says your VMware while mine says Broadcom...

Here is my part:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Broadcom (0x14e4)
    Device: VC4 V3D 2.1 (0xffffffff)
    Version: 13.0.6
    Accelerated: yes
    Video memory: 875MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Broadcom
OpenGL renderer string: Gallium 0.4 on VC4 V3D 2.1
OpenGL version string: 2.1 Mesa 13.0.6
OpenGL shading language version string: 1.20

what fps does your glxgears get? it should be around 60fps when accelerated and 30-40-ish if not. And that's about what I get with it on or off.