I need to find a way to stop guests from making posts altoghter…
Could you please name the files which I should send you. Cause my guess is they may be scattered around the file system.
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)
Thanks for uploading. I’ll be testing this build today on real Pi.
Hopefully I’ll manage to find out why it’s not worked for you.
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%. 
So I’m end up not being able to run actual gameplay because lack of “fuzzylite” build. Can you upload it as well? 
Could you please point the files which you need for fuzzlite.
I need “libfuzzylite.so.5.0” and if there any other files you built with VCMI please upload them too.
It is very easy to compile I will upload source. If you still need executables please reply.
fuzzylite-5.x.zip (1.81 MB)
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=callgrindSadly 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 instructionIf 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:
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurredPS: Already find out why valgrind not working, just commented out libcofi_rpi.so from /etc/ld.so.preload
Sadly now valgrind failed on other file:
==28302== Illegal opcode at address 0x50A5BF0
==28302== at 0x50A5BF0: ??? (in /usr/lib/arm-linux-gnueabihf/libSDL2-2.0.so.0.2.0)Don’t think there is way to bypass it this time. 
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.
VCMI does not support OpenGL. Iirc it was abandoned as not enough portable.
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.
SXX in one of your previous post you recommended comping vcmi using sdl1. How should i do it?
p.s. on pi2 compilation is much quicker. Only one day 
I think you can still specify it as cmake option, e.g:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_SDL2=0Though keep in mind you need to install SDL1.2 developer packages first:
libsdl-gfx1.2-dev libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-sound1.2-dev libsdl1.2-dev libsdl-net1.2Of course it’s may be won’t work any better on RPi that still have quite slow CPU.
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.