![]() ![]() ![]() * And, from my perspective the worse: Anytime you have a problem with there is few hope it would be fixed if the orginal maintainer is not there anymore, letting code that would possibly became dirty with years making any tiny code refactor very hard.Your browser does not seem to support JavaScript. * It complexify the code (because mupen64plus does support many platform). So the most prolific improvement would be ARM7 specific optimization but those are complex code: * its very unlikely RPi would ever had a Vulkan driver The more I see Vulkan the more I think some RDP tasks would require quite less hacks if someone would start a graphic plugin based on this but: This is not something doable hobbying project per se. I've dig into the RPi GPU code (thanks to Eric Anholt presentation and code) and what I can say is: If you want good performance to emulate N64 RDP on RPi, you would have to write a whole driver with it's own API. There is a lot of things RDP was doing you can't do today in a portable way and which require _massive_ (using this word I mean: "Impacting the whole emulator graphic plugin code design") _hacks_ (aka: "far more than 1") to be properly emulated. ![]() Even GPU tasks need a lot of CPU activity (texture decoding, vertex processing.) while RDP (N64 GPU) was doing this in hardware. If I can add: mupen64plus (as many emulators) is highly CPU based. > Le Mardi 17 février 2015 2h53, " a lot William! > specific to RPi 2 but also RPi 1 and ARM devices in general. > What I said is that issues you've reported doesn't seems to be > On Tue, at 10:33 AM, 'Dorian FEVRIER' via mupen64plus > here may have, or if a new version of mupen64 may be released sooner ![]() > should do it flawlessly but it just came out and updates down the > really gotten the RPI to play N64 emulation well. > Ah, well that's for the most part true. > On Wednesday, Februat 9:54:45 PM UTC-5, whywilson11. > multithreading to the other 3 cores we'd see a world of difference. Still, if mupen64plus could be optimized to handle > without utilizing multiple cores, it should still run better than a 1st My understanding is the pi 1 was arm6, whereas the pi 2 is arm7. > it, I noticed on top that 1 CPU was completely pegged out. > optimized to take advantage of the Pi 2's multiple cores. From the best I can tell, the problem stems from mupen64plus not being ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |