EmulationStation Grid View v1 ready for wider testing
-
Great news, will be getting my themes updated to support it hopefully by next weekend.
Big thank you to @A12C4 -
@cloudlink There is 3 themes I modified for testing : a modified version of the classic carbon theme and a update for new theming syntax of @lilbud 's material and moderntv themes. You can find the links below :
-
@a12c4 wanna send a PR to my branch?
-
@lilbud It's not complete, I half added the "custom collection", and I was too lazy to change all the system specific theme.xml so the color of the selector is based on the system color :)
You can find my changes here :
-
I just installed emulationstation-dev from source. I also installed the new Carbon theme. In ES, when I sect the Carbon theme and Grid gamelist view style, then click Back, it just freezes and I have to reboot.
Am I missing a step? -
Hello @cloudlink , I'm sad to hear that you have troubles enabling the grid view.
What is your system running ES ? Can you detail a bit more what you are doing step by step (are you changing both the game list view style and the theme at the same time for example ?)
I am unable to completly reproduce your problem. When I switch theme and game list view style to the grid view on my pi 3B, it freeze for about 4~5 seconds but after that it work perfectly.
-
@a12c4
Thanks for the reply.
Sorry, I should have included more detail.
I'm running the latest version of Retropie, upgraded from the latest official image, on a Raspberry Pi 3 B+.
The only custom changes I've made that I can think of that might interfere are a few emulator entries I manually added to es_systems.cfg. Those are unthemed right now as I'm using the new version of Carbon with no customizations.
Could that cause an issue?
I've tried changing to the Carbon theme first then enabling the grid view. It changes to the Carbon theme just fine, but freezes indefinitely when changing to grid view. -
@A12C4 I updated my main Pi which has a lot more games on it and saw the same hanging. I did some testing and traced the delay back to here. I believe at one point you explored having the ImageGridData holding the image path vs. a TextureResource. At a minimum we probably need a way to defer the creation of the TextureResource until they are first needed.
-
@jdrassa Define "first needed".
Yes I explored instantiating the TextureResource while navigating in the grid and it gave really poor results, with huge fps drops.
Another solution could be to instantiate them only for the currently selected system, but that way you may experience big loading time if you switch to a system with a lot of games for the first time.
This 9000+ games collection ain't gonna get loaded by itself.
-
@a12c4 said in EmulationStation Grid View v1 ready for wider testing:
@jdrassa Define "first needed".
Yes I explored instantiating the TextureResource while navigating in the grid and it gave really poor results, with huge fps drops.Not entirely sure. My first thought was to load only the textures needed to fill the grid tiles and then load more as they are needed, maybe with some sort of predictive loading ahead based on scroll direction/speed. I assume that is along the lines of what you already tried.
After thinking about it further, it may be that the check for for file existence that happens before loading the texture may be contributing to the delay. I know that the auto-discovery of images was disabled on the stable branch due to the delay checking for the image existence was causing.
-
@jdrassa Sorry for the late answer, I had some troubles with my computer that I needed to fix first.
So, after taking a look with callgrind, it look like the check for file existence have nearly no cost compared on the TextureResource instantiation. (btw if you have a better method than using callgrind to profile C++ code, I'm interested, as it's far from perfect and I would like to focus on the grid optimization along with debug in the next weeks).
I think we have 2 bottlenecks here : the TextureRessource instantiation and the TextureData loading.
The 2nd one can be easily delayed by loading only texturedata for the selected system instead of all system at the same time. This is actually something that I had already made in the first version of the "dynamic image loader" feature but didn't reimplemented when I restarted the final version from scratch.
I think this should help a lot here : Since the modified carbon theme that I shared display 15 grid tiles per system, this mean ES will load up to 15 texture per system (ofc it will load only 2 if you have only 2 games for a system), so if you have let's say a 30 system game collection, ES will load up to 15*30=450 texture at the same time, thus hanging a little bit ... With that modification, ES will only load the texture for the selected system, so if you change system using left/right shoulder button, it will take a little more time to load, but it should completely solve our problem with big game collections.
-
Hi, is there an up to date version for windows that matches the raspberry pi as the version currently on your continuous build doesn't seem to be working correctly, setting the grid to <scrollDirection>horizontal</scrollDirection> results in no grid being displayed and if you try to activate grid through the menu or change the theme ES crashes.
Thanks in advance for your help.
-
@ruckage Hi, I'm aware of this 2 issues and working on a fix for both of them. This is taking a bit longer than expected, as I said in the comment right above yours. Once both fixes are released, jrassa should come with a new version anytime soon. Thanks for your patience.
-
-
Hmmm....
-
@lilbud Can you give some context to this image ? Are you reporting a bug or do you just want to show your last creation ?
-
@a12c4 yes
Showing off a mockup I've been working on
-
@lilbud do you even need grid view for that? I mean it's just a single image above an frame with some Metadata. You can do that in detailed view.
-
@ectoone Like I said, just the result of me screwing around in photoshop. I just wanted to see what different views looked like.
-
@lilbud Yeah sure, asking for feedback is fine but I don't understand why you posted it here with no context.
I thought that you wanted to use grid view to show only one image. Which makes no sense to me, because it can be done without grid view. Also I find it has even less accessibility then my suggestion to have an opinion to fix the selector on one side (I posted an image of that in one of the other threads).
Also it would be OK if you had posted more images of the different views, but then I would still ask myself: why is that here?
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.