Running ResidualVM on a Raspberry Pi
Moderator: ScummVM Team
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
Running ResidualVM on a Raspberry Pi
I did a quick search on here and didn't find any other topics so I figured I'd create one (I also posted on Facebook recently).
I tried compiling ResidualVM to run on my RPi (I think I'm using RaspRazor if memory serves). I was impressed that it compiled just fine and then ran straight away:
Annoyingly it runs too slowly to be playable at the moment and I don't know if audio works (currently I haven't got audio working within the OS, a project for another day).
I was wondering if anyone else had better luck on with regards to framerates?
Interestingly the game ran horrendously when graphics acceleration was enabled but merely stuttered a bit with software rendering. The intro cinematic played smoothly when software rendering was used too.
I'm considering trying some different OS variants to see what works best but wanted to see if anyone else had done so already to save me the trouble
I tried compiling ResidualVM to run on my RPi (I think I'm using RaspRazor if memory serves). I was impressed that it compiled just fine and then ran straight away:
Annoyingly it runs too slowly to be playable at the moment and I don't know if audio works (currently I haven't got audio working within the OS, a project for another day).
I was wondering if anyone else had better luck on with regards to framerates?
Interestingly the game ran horrendously when graphics acceleration was enabled but merely stuttered a bit with software rendering. The intro cinematic played smoothly when software rendering was used too.
I'm considering trying some different OS variants to see what works best but wanted to see if anyone else had done so already to save me the trouble
- YakBizzarro
- Posts: 37
- Joined: Wed May 18, 2011 8:10 am
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
Ooh, interesting stuff. There's a fair bit I don't know about the way the RPi handles stuff.YakBizzarro wrote:The hardware accelerated renderer used in ResidualVM uses plain OpenGL, but AFAIK on Raspberry, OpenGL is software emulated, so it's slower that our software renderer.
No worries. Is there any sort of timeline for that or is it just "before the heat death of the universe" sort of thing?YakBizzarro wrote:For an acceptable framerate, you'll probably have to wait for a port to OpenGL ES, which is hardware accelerated on Raspberry.
I'm happy to help testing but my coding abilities extend only marginally further than "Hello, World" at the moment!
My android branch has an opengl ES2 renderer, which can also be used on desktop openGLs.
You can try to compile it but you'll probably need to screw around with the configure script, such that it searches for opengl ES libraries instead of opengl.
Let me know what happens if you try that.
You can try to compile it but you'll probably need to screw around with the configure script, such that it searches for opengl ES libraries instead of opengl.
Let me know what happens if you try that.
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
That sounds like it might be a viable way of doing things, Botje!
I was trying to get it to compile but kept running into make not knowing where to find gl2.h and later khrplatform.h.
Eventually I traced the issue to libgles2-mesa-dev and libegl1-mesa-dev. It didn't want to install due to assorted dependency issues so after much swearing I smushed it into the distro by force:
Once I got it compiled it ran but I couldn't seem to enable anything other than the TinyGL software renderer. Is there something I'm missing?
Did I not make the right changes to the configure file?
Here's a pastebin of the version I used.
I was trying to get it to compile but kept running into make not knowing where to find gl2.h and later khrplatform.h.
Eventually I traced the issue to libgles2-mesa-dev and libegl1-mesa-dev. It didn't want to install due to assorted dependency issues so after much swearing I smushed it into the distro by force:
Code: Select all
sudo apt-get download libgles2-mesa-dev libegl1-mesa-dev
sudo dpkg --force-depends -i libgles2-mesa-dev
sudo dpkg --force-depends -i libegl1-mesa-dev
Did I not make the right changes to the configure file?
Here's a pastebin of the version I used.
Setting opengles2 like that is probably okay, but you also need to enable the opengl shaders. (--enable-opengl-shaders or _opengl_shaders in the file.)
If you configured it correctly the build process should then compile and use engines/grim/gfx_opengl_shaders.o instead of engines/grim/gfx_opengl.o.
If you configured it correctly the build process should then compile and use engines/grim/gfx_opengl_shaders.o instead of engines/grim/gfx_opengl.o.
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
Here's what the compilation looks like. I can give the output of make -d if it would help.Botje wrote:If you configured it correctly the build process should then compile and use engines/grim/gfx_opengl_shaders.o instead of engines/grim/gfx_opengl.o.
Is there anything else I'm missing? I enabled the shaders in the configure file but the only renderer available stayed as the TinyGL one.Botje wrote:Setting opengles2 like that is probably okay, but you also need to enable the opengl shaders. (--enable-opengl-shaders or _opengl_shaders in the file.)
Hmm. Looks like configure does not allow ES2 on desktops yet.
Check the result of the configure:
config.h should "#define USE_GLES2" and "#define USE_OPENGL_SHADERS"
config.mk should have "USE_GLES2 = 1" and "USE_OPENGL_SHADERS = 1" without a # in front.
Finally, try removing the game from your games list and re-adding it. I recall having issues with that when switching between engines.
Check the result of the configure:
config.h should "#define USE_GLES2" and "#define USE_OPENGL_SHADERS"
config.mk should have "USE_GLES2 = 1" and "USE_OPENGL_SHADERS = 1" without a # in front.
Finally, try removing the game from your games list and re-adding it. I recall having issues with that when switching between engines.
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
Cheers for your persistence and patience, Botje, this must be annoying for you I know.
From what I could see the files look right:
I'm afraid my ignorance is showing here, sorry.
From what I could see the files look right:
Contents of config.hBotje wrote:config.h should "#define USE_GLES2" and "#define USE_OPENGL_SHADERS"
Contents of config.mkBotje wrote:config.mk should have "USE_GLES2 = 1" and "USE_OPENGL_SHADERS = 1" without a # in front.
I'm not quite sure what that means. Doesn't it have the options for it?Botje wrote:Hmm. Looks like configure does not allow ES2 on desktops yet.
I'm afraid my ignorance is showing here, sorry.
Just tried that to be certain. Sadly it still started up with the software renderer (with no option to change that).Botje wrote:Finally, try removing the game from your games list and re-adding it. I recall having issues with that when switching between engines.
No problem, I'm just as curious to see whether it works
I re-checked the renderer initialization and you _also_ need USE_OPENGL set (again in both config.h and config.mk).
Then it will actually try to create the ES2 renderer.
If you still get software rendering without a choice, we should meet up on IRC to debug this a bit more interactively.
I re-checked the renderer initialization and you _also_ need USE_OPENGL set (again in both config.h and config.mk).
Then it will actually try to create the ES2 renderer.
If you still get software rendering without a choice, we should meet up on IRC to debug this a bit more interactively.
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
So here's the config files I used:Botje wrote:I re-checked the renderer initialization and you _also_ need USE_OPENGL set (again in both config.h and config.mk).
Then it will actually try to create the ES2 renderer.
If you still get software rendering without a choice, we should meet up on IRC to debug this a bit more interactively.
config.h
config.mk
Here's how the compile went down.
I first ran ./configure after making the changes (here's the configure file) but when I checked the config.* files they didn't seem to reflect the changes so I edited them by hand. After that I ran make. See the link above for how that worked out
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
After tinkering with my repos to get around the whole forcing packages to install I tried again.
In the two config files OpenGL, GLES2, and OpenGL_shaders were enabled.
Sadly it didn't work out.
So I ran the make again, this time with verbose output (that's not the full output, it was too big, the full output is here).
In the two config files OpenGL, GLES2, and OpenGL_shaders were enabled.
Sadly it didn't work out.
So I ran the make again, this time with verbose output (that's not the full output, it was too big, the full output is here).
I really meant "make VERBOSE_BUILD=1", as that prints the commands it executes. You don't need to put the entire trace either, just build it once normally, then make VERBOSE_BUILD=1 a second time so I can see the failing ld command.
Edit: I just looked at your config.mk again, its LDFLAGS do not try to link GLESv2 *at all*. add "-lGLESv2" to LDFLAGS and see what happens.
Edit: I just looked at your config.mk again, its LDFLAGS do not try to link GLESv2 *at all*. add "-lGLESv2" to LDFLAGS and see what happens.
- Flamekebab
- Posts: 13
- Joined: Wed Sep 18, 2013 6:12 pm
Ah! Gotcha. Here's how that went.Botje wrote:I really meant "make VERBOSE_BUILD=1", as that prints the commands it executes. You don't need to put the entire trace either, just build it once normally, then make VERBOSE_BUILD=1 a second time so I can see the failing ld command.
Here's the amended config.mk file. Hopefully I did that right?Botje wrote:Edit: I just looked at your config.mk again, its LDFLAGS do not try to link GLESv2 *at all*. add "-lGLESv2" to LDFLAGS and see what happens.