Grid View Theme Ideas

[mattrixk]

@herb_fargus
Are you able to change how many rows and columns of games are shown? I notice in your screenshots that Carbon has a 5x3 grid, but Material has a 5x4 grid.

Landscape covers and screenshots are fine 5 across, but portrait covers could maybe go 6 across. Also, are you able to change the size of the images with the <size> property like a normal image?

[herb_fargus]

@mattrixk the grid layout is defined in the selector. You essentially define the area the grid will be in in the theme and then in the emulationstation menu you can change the scales roughly so diff numbers of images show up depending on the scale you choose

[lilbud]

Vertical view in ES. This will be the default grid view

[herb_fargus]

@lilbud heres my attempt at it:

I do like the simplicity of your version. did you do away with titles altogether or is the first one just not loaded yet?

[lilbud]

@herb_fargus I merged your pull request. The first one is not loaded yet.

[mattrixk]

@herb_fargus, @lilbud Those both look great. I can't wait to get my virtual machine running so I can play with Grid View too.

[lilbud]

@herb_fargus I did have an idea. Put all of the metadata in the sidebar. I tried it and soon realized some logos would be too big to fit.

[herb_fargus]

@lilbud logos like publishers? I have another idea that I'm trying out, just getting a screenshot ready to post

[herb_fargus]

@lilbud even more minimalist:

[lilbud]

@herb_fargus I think the logo should be smaller

[herb_fargus]

@lilbud yeah I was thinking so too, was trying to centre it proper.

[herb_fargus]

@lilbud something more like this?

Personally this is my favourite rendition thus far. There are really only two issues with this version:

• if your game name is too big it goes a bit off the screen because I don't believe the text values have an origin setting

• it is very clashy if you leave on the on screen help, so just turn it off (who uses it anyways?)

gists with xmls:

https://gist.github.com/HerbFargus/6c041c9793202d03930b49b7e4bc721a

https://gist.github.com/HerbFargus/1d861addd335da50e2bfc2ecb29a1d18

tbh for my personal build I think I'll just take out titles altogether. thats what boxart is for anyways

[mattrixk]

@herb_fargus Where did you get the title screens for your games? Did you replace each of your box art images with title screens for every game you have, or just select ones? Is there a repository or website I can go to get them, are they all on thegamesdb, or do I have to do some google-fu for each title, one at time?

[herb_fargus]

@mattrixk I made them myself with my swanky script see here: https://retropie.org.uk/forum/topic/3353/take-and-scrape-your-own-screenshots

[herb_fargus]

I also kinda like removing the title altogether - as long as you have a complete scraped list.

[Arcuza]

@herb_fargus This is of course a fabulous idea. However, I think we miss a lot if we group our roms up by system. It's of course the first thing you would think about, but I would really like to push the idea that genre, developer, year or number of players are equally "important" groupings. Of course Console should be one as well.

What if that vertical bar said "Racing", "Konami", "1985" or "4 players". That would be awesome.

Shouldn't we be working on that directly? Then, we could skip two kind of menues (the side scrolling and the game select list) and just have one big grid view with all roms filtered by what you prefer at the moment.

The Retropie menu would of course be accessible from the ES options menu.

Simplify and make it better in my opinion.

(We would also have to find graphics as the developer logos)

[herb_fargus]

@Arcuza that is way beyond theming functions. What you're talking about is a whole new platform, new dB backend, completely diff coding, not to mention all of RetroPie is coded specifically to a system based concept.

It's not a bad idea as I would prefer an attribute based sortable kodiesque game selector, but it's outside of the scope of the current codebase.

[Arcuza]

@herb_fargus It does not require a DB. And it shouldn't be that tough. The most challenging part would be to do a graphical selector within a category, (i.e. showing all developer logos and let you select one of those). Bypassing the system selector should be quite easy. I've skimmed through Aloshis code, and it would take some time to reverse engineer his code.

When you talk about system based concept, do you mean that menues and such are changing based on which system your currently have selected, or is ES stateless system-independant until you fire a game?

What inhibits the gridview (or rom selector) to show roms for different systems in the same list?

[herb_fargus]

@Arcuza What inhibits them is the runcommand configs that are hardcoded to each system so that when you install an emulator with retropie it automatically generates the specific code in the es_systems.cfg for that system, so it will only launch snes games from the snes system menu.

and yes I suppose you could do it with xmls but a db would be more effective for querying based on metadata.

[Arcuza]

@herb_fargus Ok, got that. Still think using a db won't improve things. For filtering and sorting static data, just reading the data from a file into memory will be much faster, less memory usage, and more reliable (less applications and services). If the Retropie would be expanded to expose network services for multiple users altering data simultaneously and we need to have transactional integrity, I understand. Just don't think that you need a db for filtering and sorting...