Originally Posted by frwololo
Hey Gravox, let me respectfully disagree here.
I know it's completely off topic, but on any platform, the gui can be easily separated from the actual features. The result is that the GUI of any "loader" (emu) could be loaded/unloaded at will, in order to free the resources for the applications.
In other words:
- loader backend lives in ram, takes only a few kb
- loader backend loads the GUI to navigate through features
- user selects something to run with the gui
- the gui communicates the user's choice to the backend
- backend unloads the gui, and loads whatever app/rom the user requested
- when the app exits, backend gets notified with a hook and loads the GUI again.
No magic involved. Somebody who says their loader can't have a nice GUI because it would take resources away from whatever other process the gui is supposed to launch, is someone who does not really know what they are talking about.
It's possible I'm missing some context here, just saw your name in a sea of comments and I like to read what you write, so when I saw something that sounds fundamentally wrong to me I couldn't resist the urge to reply 
Also, just to confirm I'm not talking out of my a##, this is how HBL works on the PSP and the Vita. We can load whatever gui we want for the loader menu, it can be as complex as we want, eat up all the ram if it wants, we don't care, because it is of course unloaded before loading other applications.
Of course, if the gui needs to be dynamically loaded while playing a game (something quite frequent with emus), then maybe a minimal gui needs to be done at that point, but even here I could picture a system where 1) the backend takes a screenshot of the ongoing game, does a savestate somewhere on the disk, unloads the game, reloads the gui while showing the screenshot (to make it look like the game is still "paused" in the background), then once the gui is closed again and unloaded, reload the savestate from the disk.
Of course that's lot of work just for eye candy, which is not really the goal of emulators' menus. But saying it is not doable because of technical limitations of the machine is incorrect.
|
RetroArch has an extensive argument parsing system that GUI frontends like Multiman can take advantage of. The main guy I'm developing RetroArch with - Maister - is a UNIX coder who doesn't care or have any interest in fancypants GUIs. Neither do I.
So therefore, what you get for RetroArch PS3 is simple - you get a menu shader which applies a background to the screen - you get some debug fonts overlaid on top of it - I try not to make it look too ugly - if you load a game and then go back to the menu, it gets applied as an overlay alpha blended image onto the screen - overall,it looks good enough and there's a minimum amount of resources being used.
This is good enough for me, and it's good enough for a lot of people it seems.
I never claimed that something like RetroArch couldn't be made to have the Multiman GUI or Showtime GUI built into it, so I'd appreciate it if people didn't put words in my mouth on that front - it's just that I elect not to. RetroArch's repo needs to be low on fluff and big on functionality - and all those fancy images and backgrounds are going to take up a lot of space on the repo and a lot of time loading using the PS3's built-in image loading routines.
Simply put, I don't know what it's going to take for people to accept that I'm not willing to go down the road of GUI bloat. I've seen some emulators in the PSP camp (such as Exophase's gpSP) - seriously, if you consider my GUI 'minimal' - what would you consider that? Not to cast aspersions but what you're getting in RetroArch PS3 is 'good enough'. If people want something better - go for it - you can plug into RetroArch's argument parsing system and built a GUI around it - more power to anyone who does it.
BTW - I'm also in charge of a Wii, 360 and Xbox 1 port of RetroArch - and let me tell you, memory resources are very much a serious, serious problem. Case in point - VBA-M alone sets up a 32MB ROM buffer at startup because the original codebase did not have the foresight to check the filesize of the ROM it's loading - so that means you take out almost half of your available system RAM on Wii/Xbox 1 ( because the Wii might have about 88MB of segmented RAM available to it, but realistically you only get 48MB free out of that total amount - that, and there are latency disparities between MEM1 and MEM2 too - so realistically you might not even WANT to use the upper parts of memory to begin with because it would be much slower). Then you add to that whatever else needs to be loaded and you start to appreciate having a very lightweight GUI that takes up almost nothing.
RetroArch is not just my emulator frontend - it's for everyone who elects to make a libretro port, it's for everyone who elects to port it to their favorite system of choice. It's my job as the second lead developer and the main developer of the PS3/360/Xbox 1/Wii ports to ensure that the codebase is as reusable as possible between all console ports AND that I don't burden any future devs that would like to use RetroArch as a base for their own ports with an excessive memory-hungry GUI.
BTW - just in case you like to debate this - Ekeeke has elected to slim down his GUI in Genesis Plus GX 1.7.0 too because he said he was running into memory limitations on the Wii when adding Sega CD and other additional features - so no, this is not a myth - I'm drawing a line in the sand -we don't want bloated codebases, we don't want shoddy code, I don't want bloated GUI code, and I don't want quick and dirty SDL ports. We have had too much of that in these scene already. RetroArch and libretro are about doing it right once and for all. The codebase needs to be an object lesson in why you would want to port this to [insert platform of choice] - code quality is of the utmost importance, code clarity is of the utmost importance, and code reusability and portability is of the utmost importance. Writing a lot of platform-specific and bloated - non-essential GUI code around it is not my idea of furthering that goal - and it's not Maister's goal either. That's not the task of the backend - that's the task for a frontend to deal with.
I strive for minimal memory usage, I strive for the best performance possible on each host system, and I strive for the best portability imaginable on each host system.
And seriously, I don't see anyone else right now taking so many systems under his/her belt at the moment - do you see anyone else developing simultaneously for Xbox 1/PS3/360/PC/Wii with the same emu cores, the same frontend codebase? I sure don't.
Trust me, I know what I'm doing and I get a bit tired of having to continually defend my position on this. When I say 'no, I'm not interested' - it means 'no' - it means, if you want it, go write your own GUI frontend. I want as minimal memory footprint as possible and I dislike all this bling bling nonsense - it's the same reason why my Windows XP install is in Windows Classic mode.
If a GUI comes prebaked with an SDK or console that I target (such as XUI on 360), then I don't hesitate to use it (and am in fact using it). When it comes to systems that don't come with any-built in GUI, though, I go for lightweight and minimal GUIs that get the job done.
And as I said again, as of right now (for everyone who has tried out the Sega CD RetroArch PS3 build), I think people who say the current GUI looks so bad they can't use RetroArch need to either have their eyes examined or stop using RetroArch then.
The main thing that is wrong with a lot of these emu ports on consoles in my opinion is that they go for the quickest, shoddiest ports imaginable (most of the times a straight SDL port with subpar performance), and then try to ice it over with some frivolous fluff GUI - and after that never update them. I resent that - I go the opposite way. - I update often, focus everything on core functionality, and if somebody wants to have bling-bling, go write a frontend around it - that's it Even Exophase agreed that this fixation with GUIs for emu ports on consoles was quite frankly nonsensical.
Of course, if the gui needs to be dynamically loaded while playing a game (something quite frequent with emus), then maybe a minimal gui needs to be done at that point, but even here I could picture a system where 1) the backend takes a screenshot of the ongoing game, does a savestate somewhere on the disk, unloads the game, reloads the gui while showing the screenshot (to make it look like the game is still "paused" in the background), then once the gui is closed again and unloaded, reload the savestate from the disk.
|
Actually, this is exactly what I'm doing of sorts - except I'm not even writing a screenshot to disk - the emulation frame is simply 'freezed' and overlaid on top of the screen.
http://www.logic-sunrise.com/images/...machines-2.png
And still I get crap about how this is oh so awful looking. Mind you, this screenshot is already outdated next to the GUI improvements I've already pushed forth for the next release.
Perhaps people should just try it out before they base their opinions on outdated standalone PS3 emulators that I've stopped supporting since over a year.