This will basically mix how FSD3 handles caching with how aurora handles caching. Long story short, if all goes well, in the future, it should be possible to do something like this, but wont happen in 0.7b, and will probably be 0.8+.
This creates handle issues with the code, and would require a dynamic based cache limits.
I only asked, because with password protection, I have it set up to block the game settings, so the children in the house arent messing with those settings, and wanted to move the rom browser out of that scene, to a new tab on main.xur. He was saying something about creating a widget sort of interface where you can write your own widgets, and add them to the skin(possibly), or a widget scene. i think that would be annyoing to code lolĮdit: folder structure would be like this.Īfter talking to MaesterRowen about this, it doesnt look like it would be possible at this point in time, to pull this off. then have custom cover per version to indicate rom.Įxample: have nes core launch rom.nes, and then you have several copies of the same build, each with its own specific game renamed to rom.nes.īut yeah. one could possibly edit the existing code in swizzy's github, and have the retroarch core launch a generic name. just how to manipulate it to do how the rom browser option is. which could show up in coverflow for fsd/aurora. Quickboot mate xex's for use on stock dash. There other emulators worked great though. Love64 showed some promise, but was never released, and then Team XElove disappeared. It would be better to port those emulators to the XDK, but that is a lot of work. Used to use it for Mplayer, and occasionally use it for Zelda OOT, but that is it. A lot of work, for apps most people dont use though. It is a quick dirty hack, that would need to be implemented in Aurora, Xell, and the libxenon based app, but in therory it would work.
0 kommentar(er)
