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
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. For an acceptable framerate, you'll probably have to wait for a port to OpenGL ES, which is hardware accelerated on Raspberry.
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.
Ooh, interesting stuff. There's a fair bit I don't know about the way the RPi handles stuff.
YakBizzarro wrote:For an acceptable framerate, you'll probably have to wait for a port to OpenGL ES, which is hardware accelerated on Raspberry.
No worries. Is there any sort of timeline for that or is it just "before the heat death of the universe" sort of thing?
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.
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:
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.
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.
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.)
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.
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.
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.
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.
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
That's already pretty close. Those linker errors are probably due to not finding libGLESv2.so or something. make VERBOSE_BUILD=1 should tell you the exact command used, otherwise.
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.
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.
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.