It might just be my setup but I noticed that if you assign 64mb to the GPU then you can get some missing textured in emulationstation with Retropie. For example backgrounds will be blank (white) logos can sometimes be missing.welshy wrote:whise
Not to worry, at least your now aware! Most programs only require a maximum of 64MEG applied to the GPU (in certain instances 128) and then ONLY if the software uses OpenGLES rendering. As a general rule 64MEG should be sufficient in most cases.
Yup, that's why I said "In Certain Instances", the RetroArch Psx_ReARMed Core also requires 128MEG applied to prevent flickering (although the standard Binary doesn't) and strangely only with a 512MEG RPi.KitchUK wrote:It might just be my setup but I noticed that if you assign 64mb to the GPU then you can get some missing textured in emulationstation with Retropie. For example backgrounds will be blank (white) logos can sometimes be missing.
It works with the correct settings, but very, very, slowly! (i.e. not worth playing).ric_rpi wrote:I would have thought Mupen64plus is too slow to play Perfect Dark
Okay. So where would I start poking around in order to see how it ticks? esUtil.o seems to be the problem child here, but I can't find it in the file tree after a build attempt in order to snip the bcm_host reference out.welshy wrote:moocow1452
I would think the BBB should be capable of a improved port given the newer, faster ARM rev and the GPU is supposed to be superior for polygon generation, although, the optimizations ric_rpi has used may negate this advantage.
Code: Select all
debian@arm:~/mupen64plus-rpi$ sh m64p_build.sh ************************************ Building core library make: Entering directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix' Makefile:101: Architecture "armv7l" not officially supported.' rm -f -r libmupen64plus.so.2.0.0 libmupen64plus.so.2 _obj make: Leaving directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix' make: Entering directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix' Makefile:101: Architecture "armv7l" not officially supported.' CC _obj/api/callbacks.o CC _obj/api/common.o CC _obj/api/config.o CC _obj/api/debugger.o CC _obj/api/frontend.o CC _obj/api/vidext.o ../../src/api/vidext.c: In function ‘VidExt_GL_GetProcAddress’: ../../src/api/vidext.c:268:5: warning: implicit declaration of function ‘glXGetProcAddress’ [-Wimplicit-function-declaration] ../../src/api/vidext.c:268:5: warning: return makes pointer from integer without a cast [enabled by default] CC _obj/api/esUtil.o ../../src/api/esUtil.c:35:23: fatal error: bcm_host.h: No such file or directory compilation terminated. make: *** [_obj/api/esUtil.o] Error 1 make: Leaving directory `/home/debian/mupen64plus-rpi/source/mupen64plus-core/projects/unix'
It can make a big difference! An obvious example is MAME, if we take puddings PiMAME4ALL (which is OpenGLES rendered, thus utilising the GPU) it is 250-300% faster than AdvanceMAME (which is SDL rendered, where the GPU cannot be accessed). The easiest analogy is to think of the GPU as a 'Co-Processor' taking the burden of graphics rendering from the CPU. One thing is clear, ric_rpi's N64 emulator would not be possible (at a playable frame rate) if it was SDL rendered!moocow1452 wrote:Does the unlocking of the GPU code make any difference in Emulation?