@cyperghost said in RetroFE on RetroPie:

@pjft Haha ... Well my next was intended to have the same saying.

You all know it, success of a software depends strongly on the acceptance of the users. I'm not sure whose development staff got more members ... maybe ES maybe RetroFE. But up to now the system ES is much better accepted by the users. Time will show ... @phulshof please feel encouraged to try a port and if you let users get the option to install and try out your creation via RetroPie-Update-Scripts then I think the chances are good for a growing community. I think if you find a way to convince our theme creators then the chances for acceptance are multiplied :)

I have no intention of "convincing" anyone. :) I too enjoy choice, and I've always been active to make material as widely usable as possible. That's one of the reasons I maintain the MAME meta XML files for HyperSpin, even though RetroFE doesn't use them, and even though I've never used HyperSpin myself.

RetroFE is a front-end for people who enjoy the "pretty" graphics of front-ends like HyperSpin. It caters to people who often use full rom sets, and who like to combine special collections, like e.g. all Gradius games from different systems. That also implies that it's generally heavier on the resources than e.g. EmulationStation; I wouldn't recommend running RetroFE with heavy video usage on something slower than a pi3. I'm sure there are RetroFE themes that will make even the pi3 cry. :) Some themes even require many MBs of art to be loaded for each game, making the use of an SDD very tempting; the external HDD I use on my Linux PC is already quite slow for some themes.

There's something for everyone here; I'm just hoping to provide a bit more choice by porting a front-end already available on Windows, MacOS and Linux to RetroPie. Whether other people will use it is up to them. :)

@pjft said in Adding RetroFE: emulator launches behind the front-end:

@phulshof Sounds good.

Can you manage your way around the ES code?

What you're looking for may start on the Window class (init and deinit functions). I imagine it'll then go to the Renderer code as well, but that's probably the best place to start. :)

Yes, thanks, that's no problem. :) I'm used to searching through large amounts of code, and ES is well structured, so it wasn't too hard. My main problem is the enormous amount of textures RetroFE leaves on the stack, so I have to unload it all, and then reload it when the game returns. I'm not yet sure what impact that will have on performance.