Variable Support in Themes in EmulationStation

ruckage

@ectoone
Hi @EctoOne, I did consider that as an option but unfortunately it's not viable on my current theme as it uses so many layers. I've had to optimise it carefully as it is so adding even 1 more full-screen layer would sadly result in too much slowdown.

jdrassa

@ruckage I will need to think some about the best way to approach this. The way variables are processed, they are are resolved well before the values are passed to the actual gui components (i.e. ImageComponent, TextComponent, ...). As such, the components are unaware of variables.

I am leaning towards adding something like the following:

<image>
  <path>./${system.name}.png</path>
  <defaultPath>./default.png</defaultPath>
</image>

This would make the behavior very specific and deliberate.

jdrassa

@ruckage Also just to note. I see you are using ${system.name}. I would recommend using ${system.theme} instead.

ruckage

@jdrassa
Thanks for the reply. Having a default path sounds perfect to me.

Regarding the use of ${system.name} I'll change that to ${system.theme}.
What's the difference between them as ${system.name} seems to work perfectly and the only systems I noticed which didn't work as expected were all/favorites/recent.

jdrassa

@ruckage The values are derived from es_systems.cfg.

  <system>
    <name>nes</name>  <!-- ${system.name} -->
    <fullname>Nintendo Entertainment System</fullname> <!-- ${system.fullName} -->
    <path>/home/pi/RetroPie/roms/nes</path>
    <extension>.nes .zip .NES .ZIP</extension>
    <command>/opt/retropie/supplementary/runcommand/runcommand.sh 0 _SYS_ nes %ROM%</command>
    <platform>nes</platform>
    <theme>nes</theme> <!-- ${system.theme} -->
  </system>

While generally, name and theme are the same, there are some cases where they are not. It also helps for systems like megadrive/genesis and pce/tg16 where the user may have changed the theme.

ruckage

@jdrassa
Thanks, obvious really if I'd thought about it.
I've changed all instances of ${system.name} to ${system.theme}. Thanks for the advise.

jdrassa

@ruckage I have implemented default image support. I ended up naming the new field default since that was what video was already using.

<image>
  <path>./${system.name}.png</path>
  <default>./default.png</default>
</image>

It also occurred to me that this could work well for the missing.png you use. You could set it as the default for md_image and then it would only show if the selected game does not have an image.

Windows build available here:
https://ci.appveyor.com/project/jrassa/emulationstation/build/2.6.4-201746011746/artifacts

ruckage

@jdrassa

That's great, I'll give it a test. Is this part of the main branch yet?
edit: Yes it definately would be perfect for the missing .png. It's currently removed as it was sometimes visible when not needed so this would fix that.

EctoOne

@jdrassa Is the default thing also possible within the carousel?
It seems stupid to cover the text for unthemed systems but since we can pull the system name with system.Fullname and format it like we want, i can see some use for it.

Edit: Nvm, i totally forgot that it's based around the image tag, so it should be possible. For some reason i thought that the logos were defined by the carousel tag.

jdrassa

@ectoone The carousel is a bit of a special case. There is logic there that determines if it should show the image vs. text. I did not make any changes to that logic, so the default image doesn't currently work for the carousel. I am not sure that I see the use case where a default image would be better then text, since the user wouldn't be able to tell what system it.

EctoOne

@jdrassa Oh, thanks for the answer.
My Invaders Theme would be an example where text would break the design and that uses <text>${system.fullName}</text> to show which system is selected.
So there are cases where it would be useful, but it depends on the Theme creator to avoid confusion. So i understand why you didn't change that.

ruckage

@jdrassa
Regarding the default carousel image I agree with @EctoOne , it's something that could be useful in certain circumstances so I think it would be worth adding. For my theme I had considered it as having just text breaks the look of my theme as well - however in my case it wouldn't be ideal as you couldn't tell what system was selected so instead I'm going to generate basic icons/logos for every supported system and use the default image option for the backgrounds.

I've tested the default images in the version you posted and all seems to be working perfectly. Thanks for all your hard work.

jdrassa

@ruckage @EctoOne default images is now in the main branch. Also I did implement default images support for the carousel logos as well.

ruckage

@jdrassa
Thanks, that's great news.

ruckage

@jdrassa
Hi. I just tried you latest continuous build for windows and the automatic variable system.theme isn't working so my snes mini theme no longer displays any icons/backgrounds. Has something changed or is this a bug?

The version I was using previously was from 1st October (I think when you added default image support) and the variables all work perfectly in that version.

Thanks in advance for your help.

jdrassa

@ruckage Looks like a recent change introduced a bug where only the first variable is being resolved. Should have a fix out in a day or two.

ruckage

@jdrassa said in Variable Support in Themes in EmulationStation:

@ruckage Looks like a recent change introduced a bug where only the first variable is being resolved. Should have a fix out in a day or two.

That's good, thanks in advance for fixing it.

jdrassa

@ruckage Latest build should have the fix.

ruckage

@jdrassa
Perfect, working again now. Thanks for fixing it so quickly :) .

Was this something just affecting your build or was it a problem in the main branch as well?

jdrassa

@ruckage It was a problem on the main branch as well (or would have been). RetroPie's repository now uses 2 branches, master and stable. RetroPie-Setup now has an ES dev module that pulls from master, while the main ES module pulls from stable. The change was present on master, but hadn't made it to stable yet.