search

mjrgh / PinballY

A table browser and launcher ("front end") for virtual pinball cabinets.
Other
47 stars 22 forks source link

Adds options to allow views to transition in parallel #84

Closed byancey closed 4 years ago

byancey commented 5 years ago

EXPERIMENTAL: By default, PinballY loads each view sequentially, with playfield first, followed by Backglass, DMD, Topper, and finally Instruction cards. This approach results in smoother individual transitions, as all the videos aren't trying to load at once. The side effect of this approach is that there is a perceptible delay between views loading, particularly between when the playfield is observed to load, and when the topper and instruction card are are observed to load at the end of the sequennce.

This commit adds a "LoadViewsInParallel" config item that, when set, will override this sequential behavior and begin loading all secondary views in parallel as soon as the transition anmiation for the playfield starts. This config value defaults to false, retaining the original behaviour if it is not set, or set to 0.

Note that this option has not been added to the in game options dialog. To enable, you must directly add the following entry to settings.txt file:

LoadViewsInParallel = 1

This commit also adds the ability to tweak the transition times for the playfield and secondary view fade animations. Adjusting these values can help the timing of fades between playfield and secondary views to blend a bit better when used in conjunction with the LoadViewsInParallel setting.

Again, these options have not been added to the in game options dialog. To enable, you must add the following lines directly to settings.txt:

PlayfieldCrossfadeTime = 120 SecondaryCrossfadeTime = 120

These values represent the time in ms for the playfield and secondary views to crossfade between videos or images. If not specified, the default setting is 120ms, retaining the exisiting transistion behavior.

byancey commented 5 years ago

I've observed a couple of random crashes this afternoon, which I suspect are probably tied to this change. It's not easily reproducible, so likely some type of a race condition resulting from the removal of the synchronization of the views. This was just the result of me experimenting, so I really haven't gone through all the code getting executed when each of these views starts up to identify any concurrency problems.

I've disabled the feature in my own build and will monitor to see if the crash re-occurs. For now, I'm going to close this Pull Request. If somebody really wants this change to play around with, they can pull it directly from my fork, but probably shouldn't be considered for inclusion in main release in it's current state.

byancey commented 5 years ago

I observed the random crash I've been seeing even with the "LoadViewsInParallel" feature disabled, so perhaps this was not the root cause after all. I'm leaving the pull request closed for the time being, but wanted to note my observations.

byancey commented 5 years ago

The root cause of the crashes that led me to initially close this pull request has been tied to an issue in my video drivers (see issue #88). Since fixing that issue, I've actually been running with this change enabled for quite some time with no crashes.

As this change is working quite nicely in my cabinet to eliminate any visible delay between views, I felt that I should re-open it for consideration to be included in the master branch.

mjrgh commented 4 years ago

Do we really need both the "sync in parallel" and crossfade time options? Isn't it enough to just have the crossfade time option, since you can set it to zero if you want simultaneously updates?

Oh, wait, never mind - I was thinking that was the delay time between fades.

byancey commented 4 years ago

Do we really need both the "sync in parallel" and crossfade time options? Isn't it enough to just have the crossfade time option, since you can set it to zero if you want simultaneously updates?

Oh, wait, never mind - I was thinking that was the delay time between fades.

True, the CrossFadeTime is the duration of the fade, not the delay between fades, but you can indeed get pretty close to the same seamless transition by leaving LoadViewsInParrallel off and simply setting CrossFadeTime all the way to 0. I ran this way for quite a while. Having both just gives a bit more flexibility to add some actual fade back in, and still have things load up in parallel.