[frwololo]

Originally Posted by GraVoX959 I find it.. well, stupid to say the least that you have the most feature rich, fastest and most optimized emulators you will find on any system (PC included). Yet you complain about a menu to load the ****in thing. Especially when the man who is maintaining them has said that flashing it all up will sacrifice features and speed. Do you know how much RAM it takes to load a simple text editor on this machine? Do you wonder why there are no multitasking apps on here? The PSP has the best multitasking app of all time, the PS3 is a lot bigger so should be able to do more right? No, not right. Its not a simple process of thinking, "its big it can do this"

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.

[Rautz]

Originally Posted by Squarepusher2 It might have occurred to you that you that I don't give a rat's ass about any fancypants GUI code. I don't give a **** - what you get is functional enough, and if you don't consider that enough, then I don't care - get lost and use something else. Helping me out? I don't want your 'help' - nor do I recall ever asking your 'help' or needing anybody's help - because I dont' feel that anything is broken. If you don't like lightweight functional GUIs, that's your problem. I need an attitude adjustment - really now??? And you say this in the PS3 scene? Honey, I might think you'll find I'm the most swell guy around in this joke of a 'scene'. Good for you - ask me if I give a ****. Kindly go **** yourself. Oh, and you can ram that GUI fetish so far up your ass it hurts your cheeks - that's how much of a **** I give about GUI fetishists.

After reading this, I wish I could share this blunt with you right now. That was some epicness in a post!!! LOL

[Squarepusher2]

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.

[Wolfie708]

Originally Posted by Squarepusher2 it's the same reason why my Windows XP install is in Windows Classic mode.

That one line says it all for me

If you want something with bells and whistles then fine, but if you want something that works cleaner then get rid of them.

[GraVoX959]

@Squarepusher2 sorry for putting words in your mouth.. I just had vague recollections of you saying way back when (psxscene days).
That importing libs etc to handle the previews and other crap. Like what can be seen on the XBOX1 emulators would come at a sacrifice to emulator performance. I'm most likely wrong but I rolled with it. Again, sorry for putting words in your mouth.

@frwololo Correct me as much as you like I'd rather be corrected after a couple posts and look like an ass for a brief period. Than go on ranting on and look like an ass for a long time..
That's enough of a battle for me anyway.. you may not have noticed but I have an ass where my face should be..


Sent from my GT-I9100 using Tapatalk 2

[Squarepusher2]

Originally Posted by GraVoX959 @Squarepusher2 sorry for putting words in your mouth.. I just had vague recollections of you saying way back when (psxscene days). That importing libs etc to handle the previews and other crap. Like what can be seen on the XBOX1 emulators would come at a sacrifice to emulator performance. I'm most likely wrong but I rolled with it. Again, sorry for putting words in your mouth. @frwololo Correct me as much as you like I'd rather be corrected after a couple posts and look like an ass for a brief period. Than go on ranting on and look like an ass for a long time.. That's enough of a battle for me anyway.. you may not have noticed but I have an ass where my face should be.. Sent from my GT-I9100 using Tapatalk 2

It still doesn't change the fact that using lots of statically linked bloated libs and incorporating a GUI into your main emulator frontend/backend binary DOES increase memory bloat and DOES increase the memory footprint - it's the same reason why ekeeke elects not to use every user library under the sun for his Genesis Plus GX port and why he is continuing to strip down GUI images and additional fluff out of the GUI - because he's running into memory problems now. I'd rather approach this issue from Day One - by not even going overboard with pictures and lots of fluff in the first place.

frwololo 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.

This is not the case for us - what you're describing here is what Multiman would do when - say - doing an exitspawn to RetroArch and supplying it with a few arguments.

The 'GUI' in this case is baked into the main RetroArch binary - and it's done that way to facilitate easy back-and-forth switching between the menu and in-game. I could have gone the 'GUI-less' route, but that would have been even more of a drag from an end-user perspective. Therefore, it needs to be lightweight, and it needs to be fast, while still looking reasonably good.

So yes, the 'limited resource usage' that this lightweight GUI approach allows for still holds for this particular use case I'd say . And I'd say what Gravox said about RetroArch and its stance on GUIs is still correct in the overall scheme of things - given the description I just provided.

Anyway, this is going so offtopic by now I'm sure hellsing6 will be pissed - so I'll leave it at this.

[4218kris]

whats up with all the download links first i try to get preloader then cex2dex app, all lead nowhere... $0ny shutting this shard down?

[nuzz]

Can someone post a new mirror or pm me with one thx

[ZeusCronos]

Can some1 upload a new mirror Please, Thanks

[Mistawes]

CEX2DEX Gunner54

http://mir.cr/1NDLOR8H

JC Preloader 3.1

http://mir.cr/RQOJE3BE