Updated EmulationStation for Windows

[dukeblooders]

@f-caruso I use two config, one for test, but I have the same issue on both

• Config 1 : 16/9 screen (1920x1080), 4/3 image (800x600)
• Config 2 : 16/9 screen (3840x2160), 4/3 image (1280x960)

And I use video with snapshot image :
< video name="md_video" />
< origin>0.5 0< /origin>
< pos>0.555 0.32< /pos>
< maxSize>0.385 0.55< /maxSize>
< delay>2.00< /delay>
< showSnapshotNoVideo>true< /showSnapshotNoVideo>
< showSnapshotDelay>true< /showSnapshotDelay>
< /video >

For translations, I looked into emulationstation2.po but I didn't find those entries :

• Various : when developer/genre is different in the same collection
• This collection contains X games… : description of the collection

[f.caruso]

@LiveFreeDead I tried something about your pad issue in my last version try it and tell me if it is better for you ( with further testings : I reproduced it too with jrassa's version )

@dukeblooders Fixed in the last version

@ThePlagueIsBack Fixed the shutdown in my version + added a option to determine if you want the full quit menu or only the simple quit function.

@jdrassa I just did a PR with the fixed shutdown just like I described. I'm new to github, so I don't understand everything yet : I had to create a second account/fork of Retropie to do this.
If you want me to propose other PR, I'm fine with it. The thing is : I was about to start the menu theming when I saw you started a branch called "menu-theming" in your fork containing the code. As you already started it... I don't really know now what interests you ( and what are you gonna accept )...

[jdrassa]

@f-caruso I saw your PR. You shouldn't have needed to create a new github account. You should have been able to create PR on the RetroPie repository even though you originally forked my repository. If you would prefer to clean it up and resubmit from you main account, I can step you through it.

I looked at the implementation from Recalbox previously and didn't really like the approach. The various generic GUI components used in the menus are tightly coupled to the menus and the menu theming. I am not really sure if there is a better approach so I am going to experiment to see if I can come up with something better.

If you haven't already seen it, you should check out https://github.com/RetroPie/EmulationStation/pull/584. One of the other developers has been refactoring the rendering code.

[LiveFreeDead]

@f-caruso Perfect Bud, got that bug licked.... EWWWW - anyway I can now crash RetroArch and ES doesn't suffer (from controllers being disabled). Thanks again.

[dukeblooders]

@f-caruso Awesome ! Thanks.

[f.caruso]

@jdrassa I didn't manage to create a branch in my fork from your (or retropie's) master in my main Fork. I can only create a branch from my own master, but if I try to PR with it, it pushes my entire changes. The only way I found would be to delete my fork, recreate it and import back my changes into a branch keeping my master in sync with yours... I didn't find another way. So I prefered to create a new account to keep my history and create a new fork, added my main account as contributor, in order to work for you. Unless you know a better way, I'm totally fine with it : I have my Fork with my own version and I can continue my experiments into it, and this another fork in which I can do things for you. It's fine.

I suppose you are taking about the menu theming in the second part : What I did is largely inspired from Recalbox implementation, the main idea was to make their menu theming 100% compatible. I didn't try to change the way they coupled things or refactor. I agree, gui components are now coupled with menu theming, but they already are all coupled to ThemeData anyway, so I'm fine with it. The true thing I don't like at all & I wanted to change in the future is the MenuIconElement structure -> The list of icons is hardcoded in this structure and in ThemeData's declarations, it makes it complex to declare another icon in a menu. MenuIconElement should be a dynamically loaded map, and icons should be handled by "tags" in menu items.

Yes, I've seen the tomaz82's refactoring about the renderer.
I don't know why you talk to me about it. Do you want my opinion or a review ?

@LiveFreeDead @dukeblooders My pleasure...

[jdrassa]

@f-caruso said in Updated EmulationStation for Windows:

Unless you know a better way, I'm totally fine with it : I have my Fork with my own version and I can continue my experiments into it, and this another fork in which I can do things for you. It's fine.

I 'll post some instructions later in case you would like to combine them.

What I did is largely inspired from Recalbox implementation, the main idea was to make their menu theming 100% compatible.

Personally, I'm not overly concerned about maintaining compatibility. Would rather have the best implementation.

I agree, gui components are now coupled with menu theming, but they already are all coupled to ThemeData anyway, so I'm fine with it.

I would consider the gui components to be loosely coupled to ThemeData in that they are just passed the ThemeData by the view, where as the components used in the menu are directly requesting the ThemeData. Ideally, the menus would work similarly where only the root menu object was accessing the ThemeData and passing it to the child components.

Yes, I've seen the tomaz82's refactoring about the renderer.
I don't know why you talk to me about it. Do you want my opinion or a review ?

Just giving you a heads up since it is a big change that effects a lot of the code.

[jdrassa]

@f-caruso

Add branch fixed-shutdown from new repository to your original repository:

# add your new repository as an alternate remote repository
git remote add alternate git@github.com:fabricecaruso72/Retropie-EmulationStation.git
# fetch branches from alternate repository
git fetch alternate
# checkout branch from your alternate repository
git checkout -b fixed-shutdown alternate/fixed-shutdown
# push branch to your primary repository
git push -u origin fixed-shutdown

Similarly, if you want to start a new branch for other work based on the master RetroPie repository:

# add RetroPie remote repository as 'upstream'
git remote add upstream git@github.com:RetroPie/EmulationStation.git
# fetch branches from upstream repository
git fetch upstream
# create new branch based on master from upstream repository
git checkout -b new-branch upstream/master
# push branch to your primary repository
git push -u origin new-branch

[f.caruso]

@jdrassa Thx for your instructions, I'll give it a try.

I'm not overly concerned about maintaining compatibility

This is a real debate ! Users don't care about implementation, but care about functionnality & compatibility. I'm sure some users would like to use recalbox's themes !!! I did !! Some of them are truly awesome but don't work with Retropie ES, so it was totally impossible for a recalbox user to find a Windows version loading his recalbox themes ( except my version now ). This is one of the reasons why I started working on ES.

Developpers sometimes don't care about compatibility but implementation -> This often leads to lot of frustration for the users.

Both are important... Well architectured code is more maintable, and more efficient.
But user's satisfaction is always more important.

Concerning tomaz82's refactorings : it's a very good idea to isolate GL code. It's a good first step.
Still : it remains as a set of apis in a namespace. As you say you are looking for the best implementation you will agree with me : Doing things this way is not ideal for making future DX/Vulkan/GL3 renderers, or it will be a set of #define or switches at build time, and won't be configurable by users for runtime.
The best implementation would have been to create an "interface", implement it in each renderer, and inject it... Next step I imagine...

[jdrassa]

@f-caruso said in Updated EmulationStation for Windows:

@jdrassa Thx for your instructions, I'll give it a try.

I'm not overly concerned about maintaining compatibility

This is a real debate ! Users don't care about implementation, but care about functionnality & compatibility. I'm sure some users would like to use recalbox's themes !!! I did !! Some of them are truly awesome but don't work with Retropie ES, so it was totally impossible for a recalbox user to find a Windows version loading his recalbox themes ( except my version now ). This is one of the reasons why I started working on ES.

Developpers sometimes don't care about compatibility but implementation -> This often leads to lot of frustration for the users.

Both are important... Well architectured code is more maintable, and more efficient.
But user's satisfaction is always more important.

I didn't intend for this to come off so callous. Let me provide a bit of background. In the few years now that I have been involved with RetroPie, there have many theme improvements (some minor, some major) that have originated in RetroPie. In some cases these have been added to recalbox as is (i.e. carousel themeing, z-index), some have seen similar but incompatible features added (i.e. variable support, video) and some have not been adopted at all (i.e. default themes, datetime enhancements).

From my perspective, if recalbox is not maintaining compatibility with RetroPie themes, I don't feel a strong need to maintain compatability with recalbox themes. Especially if that comes at the expense of potentially providing a better solution.

I would also argue that while a more maintainable, efficient code base may potentially come at a cost (temporary lower user satification), in the long run it will result in overall higher user satisfaction as it will better enable the development of new features.

[f.caruso]

@jdrassa Sorry if I like to debate and seek contradiction ;-)
The thing is I do agree with you. Your last sentence is just so much true !

I have a pending PR on Recalbox Gitlab because I tried make their version buildable on Windows & begin remove boost for them, so I know their version very well too.
Finally, I prefered working on Retropie's ES because the code is cleaner, more maintainable & efficient (certainly thanks to you).

Retropie code is so much cleaner, there was a real big effort removing boost which is a very good thing, some refactorings, and a permanent effort to make it buildable on every platform including Windows.
Recalbox has an old basecode never refactored, still using boost, no grid ( or the 1st unusable version which is hidden ), it was late on videos until recently (they use ffmpeg i don't know why they choosed a different lib).
But Retropie is a bit late on functionnalities like themings, localisation, music, OSK...

What I was looking for before working on my fork is a "unified" version, in french, compatible with all themes & having every functionnalities of both versions ( + specifics for Windows like not showing desktop or true portable version ). And I didn't find it...

You have the best "basecode" in the "market" you should also have the highest level of functionnality & compatibility ( even If I totally understand your point of view about recalbox )

But, If you'd be interested in having theme loading compatibility, I'd be ready to do the work for you...
Plus : In my Fork I added a "customView" mecanism. Did you look at it ? Are you interested in it ?

And, still, sorry to be annoying with my debates & contradictions..

[f.caruso]

@jdrassa I've just added 3 news PRs to Retropie :

• Avoid too many reloadings of SVGs by fixing SVG size calculations
• Fix Reloadables : Don't reload useless textures that were not loaded at unload time.
• Add --home command line to set custom home path + make windows version natively portable by detecting if .emulationstation is a subfolder of the exe.

[paffley]

@jdrassa are any of the grid updates your adding available in es-dev for the pi?

[f.caruso]

@jdrassa Hi, I've just added a new PR for Retropie :

• Added a progressbar during loading + threaded loading for systems.

Loading optimization is not complete because it would also need a refactoring of metadata & filedata. I'll do a PR for it in a second time.

[jero]

I've been a while without using ES and now, it doesn't work for me. I have the latest update and launch some game I have no problem leaving retroarch closes ES.

Is there something in the configuration or something that changed and I don't know

[f.caruso]

@jero Strange, never had that kind of problems. Is "hide when launch" ON ? Is it the same with the option OFF ? Do you have musics (It's the only big thing that I added this summer ) ? Do you use my Pad2Key feature ? Maybe Retroarch has been configured to close itselft when you press hotkey+start and my pad2key too (for every processes), so the close message happens two times and emulationstation receives it.
PS : I've just commited fixes in AudioManager & music management, I may be related.

[jero]

@f-caruso I have tried to launch game with the hidden mode in OFF and ON, in ON it goes well and returns to is, but when selecting another game it closes. In OFF, launch the game and close the game close everything. I tried to launch game and then close retroarch from retroarch and it doesn't come back to it, it closes everything. About the goodbye I don't know what it can influence I don't know how to play background music.

[f.caruso]

@jero I don't know what happens and I don't have enough informations to help. What theme do you have, what's your system config, what's your emulationstation config, is there something in logs... ? Is there a crash in windows application logs. What's in it ?
I ran a lot of tests and I didn't have a single problem. I know I had a problem days ago in the audiomanager but it is fixed now.
Also : did you update using the "full pack" containing all Dlls ? I had to update some components to add music support.
I'm truly sorry, but I can't help without reproducing and without informations.

[PittStone]

@jdrassa If i have a transparent Window for the videosnaps behind my theme ( z- ) The Background is now grey and not black like on latest Versions. Thats mean, on a 16:9 Window has a 4:3 Video grey borders left and right. With Black that was better before.

[jero]

@f-caruso Finally I have time to try, I changed the theme and it happens the same. With your theme if it works well. But with others, not all that I use is a modification of the Ruckge snes theme. Also with the original ruckage theme it gives me problems and closes when I leave a game. If you need more info I tell you.