It’s depend on how exactly you compiled/installed it. E.g if you used cmake without installation then everything should be in build directory, e.g:
[ul] ]BUILD/launcher/vcmilauncher/:m] ]BUILD/client/vcmiclient/:m] ]BUILD/server/vcmiserver/:m] ]BUILD/lib/libvcmi.so/:m] ]BUILD/AI/BattleAI/libBattleAI.so
BUILD/AI/BattleAI/EmptyAI.so
BUILD/AI/BattleAI/StupidAI.so
BUILD/AI/BattleAI/VCAI.so/:m][/ul]
Though if files already installed across filesystem you may find them using command like:
# For executables
which vcmilauncher
which vcmiclient
which vcmiserver
# For libraries
ldd `which vcmiclient`
ldd `which vcmiserver`
Though if you used something like “make install” in future I recommend you to use “checkinstall” instead as it’s appropriately register installed files as debian package.
I am uploading files you have specified. It is 7 zipped into two files because whole size is over 50 MB. Before unzipping them you need to rename build001.7z to build.7z.001 and build002.7z to build.7z.002. build002.7z (27.6 MB) build001.7z (30 MB)
So I finally managed to run it. Bypass resolution issue you noted and I think it’s related to fact that SDL check XRandr modes and on RPi only native available.
Though I set “driver” to “opengles2”, set fullscreen in launcher to “On” and it’s kind a run. Though menu load RPi CPU for 100%.
Just want to let you know that I’m successfully started game, but client is extremely slow.
I’m attempted to run it under via:
valgrind --tool=callgrind
Sadly valgrind fail to run VCMI for some reason:
=27621== Callgrind, a call-graph generating cache profiler
==27621== Copyright (C) 2002-2011, and GNU GPL'd, by Josef Weidendorfer et al.
==27621== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==27621== Command: vcmiclient
==27621==
==27621== For interactive control, run 'callgrind_control -h'.
disInstr(arm): unhandled instruction: 0xF1010200
cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
==27621== valgrind: Unrecognised instruction at address 0x4831588.
==27621== at 0x4831588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so)
==27621== Your program just tried to execute an instruction that Valgrind
==27621== did not recognise. There are two possible reasons for this.
==27621== 1. Your program has a bug and erroneously jumped to a non-code
==27621== location. If you are running Memcheck and you just saw a
==27621== warning about a bad jump, it's probably your program's fault.
==27621== 2. The instruction is legitimate but Valgrind doesn't handle it,
==27621== i.e. it's Valgrind's fault. If you think this is the case or
==27621== you are not sure, please let us know and we'll try to fix it.
==27621== Either way, Valgrind will now raise a SIGILL signal which will
==27621== probably kill your program.
==27621==
==27621== Process terminating with default action of signal 4 (SIGILL)
==27621== Illegal opcode at address 0x4831588
==27621== at 0x4831588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so)
==27621==
==27621== Events : Ir
==27621== Collected : 52916814
==27621==
==27621== I refs: 52,916,814
Illegal instruction
If you can find way to attach profiler to client it’s may be possible to find out why is lag so much.
Only suspicious thing that visible from outside is error related to sound system:
Anyway I’m think I played enough with VCMI on RPi. Everything looks working fine except that client is extremely slow. This isn’t huge surprise for me just because current SDL2 build sometimes looks like pretty laggy even on my PC with i7 4771.
I’m think that it’s will be important to actually investigate why is this happen, but not on RPi itself as I have no idea what to do to avoid issues with it’s specifics and re-compilation on device painfully slow.
@spliff If there any chance you have more time try to compile it with SDL1.2 because as far as I understand it’s still possible and it’s may work better.
I recompiled vcmi on raspberry pi 2 and have ran it. But it was slow. I noticed that it uses software rendering as video driver and it was the only choice . What should I install / reinstall to get opengl.
SDL2 is currently laggy even on my i7 4771. Though even with nearly no hardware acceleration ( SDL provide some) I think there is huge bottleneck somewhere as I personally think it’s shouldn’t be that slow.
Sadly no time to investigate them as there things with higher priority.
Ok got it, but when what should i use for rendering. After writing my previous post I reinstalled sdl2 lib and now i have 3 rendering devices: software opengl and opengles2. Thinking that software rendering is slowest I have tried using opengl but that was even slower. As for opengles2 it did not even start giving error
libEGL warning: DRI2: failed to authenticate
terminate called after throwing an instance of 'std::runtime_error'
what() : unable to create render
You can specify anything that works, but as @Warmonger posted above there is no real hardware acceleration in VCMI itself. Though SDL still using OpenGL / GLES to render bitmaps that VCMI push into framebuffer.
So no it’s doesn’t matter what you choose performance won’t be better.