Request: Add an Instant Transition [SOLVED]

[Hex]

@Capeman Do you mean No animatons? I was planning to do that

[cafarellidigital]

I'd like to see this option as well. Not sure if I'd use it, but I can see where it'd be useful. Plus it's always good to have more options with transitions, and this sounds like an easy one.

Although I have a feeling the reason why it hasn't existed so far is because the transitions are hiding image loading, which might become really apparent when there's no transition. Hopefully I'm wrong!

Also, obligatory

[TMNTturtlguy]

@cafarellidigital you are correct, the transitions help with image loading. Now that @pjft has dramatically improved how ES reads and remembers the backgrounds, there may be additional opportunities to do something as requested. I am imagining however that to make this work the theme background would have to be identical for every theme, just like carbon is. We probably would also be limited to only having the carousel change, meaning other images probably won't be able to be present on the system selection view, otherwise there would be some flashing and black image boxes while the new graphics load. But who knows, with the newest improvements it might work, i just worry that we just fixed an issue, and now we might try to push the limits of ES once again!

[cafarellidigital]

@TMNTturtlguy ahh, yea thought so.

What might also be interesting is if there can be an option where a theme or user can define whether the system view background changes between systems. If the goal is to use the same background for every system, why not just define a single background and then reuse that for everything? That would certainly cut down on loading images. Also for those themes that use custom help legends on the bottom of the screen, it always a little sad to see it slide or fade out of view just to come back on the next selection. I'd love to be able to define certain elements that didn't change between systems (background, help legends, perhaps a special logo, etc).

[Capeman]

@cafarellidigital This would definitely accomplish the goal i was hoping to achieve.

[cafarellidigital]

What if you could do something like this...

<view name="system">
	<image name="background" extra="true" static="true">
	</image>
</view>

With "static" meaning that it does not move or change from system to system (no new image loading). Whichever system encounters the static first, that's the one it uses. You could use it on any element in any view (I'd use it for the help legend).

I'm sure this isn't as easy as it sounds to implement, just thought I'd give the concept a try. Thoughts?

[TMNTturtlguy]

@cafarellidigital said in Request: Add an Instant Transition:

Whichever system encounters the static first, that's the one it uses.

If you were going to have a static image, you would not have more than one background specified. In the main .xml for the theme you would have the system background called out one time to a single location in the .art folder, or wherever theme creator places it. You would not call this out again anywhere in the theme, so you wouldn't need a static tag. This is true for any element you would want to stay in the same location for every system. Simply call it out once in the main .xml and it won't move. This is how it works now, but ES reloads the same image The only thing that needs to be done is to have Emulationstation not reload the image when system is switched so that it does not fade or slide. I agree with you, not sure how to do it, or how easy that might be?

[cafarellidigital]

@TMNTturtlguy said in Request: Add an Instant Transition:

@cafarellidigital said in Request: Add an Instant Transition:

Whichever system encounters the static first, that's the one it uses.

If you were going to have a static image, you would not have more than one background specified. In the main .xml for the theme you would have the system background called out one time to a single location in the .art folder, or wherever theme creator places it. You would not call this out again anywhere in the theme, so you wouldn't need a static tag. This is true for any element you would want to stay in the same location for every system. Simply call it out once in the main .xml and it won't move. This is how it works now, but ES reloads the same image The only thing that needs to be done is to have Emulationstation not reload the image when system is switched so that it does not fade or slide. I agree with you, not sure how to do it, or how easy that might be?

I agree, you won't have more than one background specified because you would put it in the main/common xml, but technically that main/common xml is "included" in each system xml, so that line of code would appear on any and every system.

The reason I would want a static tag is because it might be useful to have this happen with only one or a few elements in the view. Without a tag, you could not specify only certain elements to have this function.

For instance, in the system view, say I had a background and a custom help legend that never changed, no matter what system you were on. However, I also have an outline of the system controller above the system logo, which obviously changes for every system.

What I would want is for the background and help legend to not slide/fade when you change systems, but the controller outline would. You could only do this if you could define which elements were static and which were not. By default no elements would be static.

[TMNTturtlguy]

@cafarellidigital so your not really asking for a new transition at all, you still want some elements to transition, you just want some elements static and not to be effected by the transition.

[cafarellidigital]

@TMNTturtlguy correct. At first thought the idea of a new "instant" transition was great, then as I thought about it, I realized what I really wanted was a new function/tag that elements could have. So I guess I hijacked the thread a bit didn't I?

[Capeman]

@cafarellidigital Hijack away! It's the same goal in the end.

[Hex]

@Capeman Would you be interested in testing ?

I have pushed changes correspoding to No Transition/Animation to my repo:

https://github.com/hex007/EmulationStation

[TMNTturtlguy]

@Hex can you provide me with some more information on what is in your build? How up to date is it with the main ES build? Thanks

[Hex]

As of now it is 4 commits behind. Those commits were pushed today i guess.

The build is optimised for Pi zero and 1. Has problems with video as the program sleeps till user input.

Has music player incorporated for which you have to follow some instructions to get running. If you are testing on Linux and not Pi then you will have to change "audio-server/player.py" file to change music directory.

I have added None as a Transition today.

Thats all

[TMNTturtlguy]

@Hex Right now all of my gamelists have video, should i avoid testing at this point?

[Hex]

@TMNTturtlguy You can test it. Just that I dont know how it might behave. Only two options either the video continues playing or it stops after some time. It certainly wont crash or damage your lists/data

On the plus side if it works I will put it on the Readme that videos work

[TMNTturtlguy]

@Hex I just ran through your build. I have to say the theme transition NONE, is pretty slick. My only question is if it would be possible to allow the carousel to still transition. I like the static background, but and the carousel images pop up really fast, so it isn't an issue, but i think it would look really cool if the carousel logos could slide or fade over the static backdrop. As for videos, the videos played for 2 seconds and just paused. No other performance issues, they just paused.

I would seriously consider making a branch of the main ES Build and only incorporating the NONE transition into it. Like I said, if he carousel could still transition, it would be perfect. If you isolate this update and submit a PR, a lot of people would be really excited about it.

Thanks for the awesome work

[pjft]

@Hex would you consider bringing your changes over to the main repository? The optimizations could come either as a compilation option (if compiled on a pi zero or 1), emulationstation option (for users to select) and/or command line option (and have RetroPie Setup add that option on a pi zero or 1 to the emulationstation startup script).

The rest could come as normal options for everyone.

I suspect that'd be the best to avoid fragmentation, bring your work to a wider audience and bring another good emulationstation developer to the project.

Do consider that. Happy to help.

Also, you could certainly make videos work by forcing the screen to refresh in the video view only, which I agree isn't needed for anywhere else on emulationstation as everything is static.

Oh, and that won't be an issue with OMX player, as rendering is handled in a separate process.

Still, good work!

[Hex]

@TMNTturtlguy I will try that tomorrow. Also read ahead.

@pjft If you have a Pi Zero or 1, I would appreciate if you can measure CPU consumption of Emulation station (mine and stock) when doing nothing on Carousel.

ssh into Pi
top

I noticed a constant ~60% usage on the stock on pi zero

[pjft]

@Hex I don't have one, but I notice similar regular CPU consumption (unsure if at 60%, but certainly not idle) when emulationstation is idle. I haven't read your code but from what you described you're avoiding refreshing the screen - including reading and processing the textures - unless there's an input. That's a wise change, as very little of it is animated. You probably have a few seconds of buffer to accommodate animations, inferring from the fact that videos play for a few seconds.

The reasons video views would need to be refreshed is because they are rendered in a normal texture, so if emulationstation doesn't refresh the screen it won't render more frames.

But for the time being that's the only exception that comes to mind.