faster-game-launch

[Mikhailzrick]

Launch the game before/during the animation instead of waiting until the animation finishes. In my testing even on slower devices it essentially shaves off the length of the animation time from the total over-all game launch time. Measured from input to existing process.

Before:
start=684.96 end=689.04 latency=4.080
start=721.44 end=725.67 latency=4.230
start=742.62 end=746.63 latency=4.010
After:
start=1002.79 end=1005.99 latency=3.200
start=1018.35 end=1021.64 latency=3.290
start=1032.22 end=1035.50 latency=3.280

Using the default fast slide setting.

Currently blocked off for linux only unless tested and verified there's a potential benefit for windows. And kept the legacy behavior in case for some reason the wait file can't be created, or there's some other failure.

Required change in batocera-linux is to add a wait loop in emulatorlauncher.py before the run command until the wait file does not exist. (No PR for this yet, still in the review stage)

Also found an issue with original codes usage of deltatime with animations. Deltatime can be inflated by the time the animation starts, so updating it before the first animation frame ensures the animation plays smoothly.

See batocera-linux PR as an example of how it could be handled there: batocera-linux/batocera.linux#16275

[nadenislamarre]

ok, i think i get the point.
the aim is to split the configgen execution part in 2 :

• the part that generate commands, like changing resolution, executing the emulator, executing the evmapy, executing the virtual wheels, display the bezels, ...
• the part purely calculating execution depending on options : like computing the bezels, analyzing options

to compute the part 2 during the animation.
at first point of view:

• it seems a negligeable win cause computing option is supposed to be very fast. but i guess that computing the bezel image in some cases is interesting mainly on some weak boards.
• it seems a bit dangerous cause on the configgen part, it must be done at the correct point (i may hope it will not require adaptations)
• sync between es and configgen (via the file for now) requires to add a check, but it can be done in a better way than a loop.

so, in short, it adds complexity and possible bugs at boot, so i would like to understand more what we win.
i've not understood the table with times in the pr (Before/After)
For the moment, my guess is that we win only when computer a new adapted bezel, the rest of configgen code is negligeable as far as it was some times ago.
Can we measure the time won if we run 2 times the same game for example ?

[nadenislamarre]

• an implementation could be that configgen give 2 calls to start a game (like prepare and run), but it requires to save informations between the 2 calls.
• an other point is that configgen has an option to display time consumed to see more precisely where it takes time.

[Mikhailzrick]

ok, i think i get the point. the aim is to split the configgen execution part in 2 :

• the part that generate commands, like changing resolution, executing the emulator, executing the evmapy, executing the virtual wheels, display the bezels, ...
• the part purely calculating execution depending on options : like computing the bezels, analyzing options

to compute the part 2 during the animation. at first point of view:

• it seems a negligeable win cause computing option is supposed to be very fast. but i guess that computing the bezel image in some cases is interesting mainly on some weak boards.
• it seems a bit dangerous cause on the configgen part, it must be done at the correct point (i may hope it will not require adaptations)
• sync between es and configgen (via the file for now) requires to add a check, but it can be done in a better way than a loop.

so, in short, it adds complexity and possible bugs at boot, so i would like to understand more what we win. i've not understood the table with times in the pr (Before/After) For the moment, my guess is that we win only when computer a new adapted bezel, the rest of configgen code is negligeable as far as it was some times ago. Can we measure the time won if we run 2 times the same game for example ?

Sorry, all times were taken launching the same game, exiting, launching the same game again, 3 times before and 3 times after booting with the changed ES binary. Old towers since it’s an included freeware, and all settings on default. To keep things consistent.

It was intentionally done on a slow device so that timing would be easier to track. An h700 1.5ghz quad core.

[Mikhailzrick]

also worth mentioning, I did not profile emulatorlauncher.py because my goal was not to shorten or improve that timing, so much as finding a beneficial way to use the time currently used to show the user the game launch animation. Depending on the animation it’s anywhere from about 0.5 seconds to 1.5 seconds. But why not do work while the animation is playing in the first place? That was my thought.

[Mikhailzrick]

In the emulatorlauncher.py change that would be needed. I used a simple loop for testing. But a better implementation could be something like checking if the file exists, and if so use inotifywait with a timeout failsafe. Unless someone has a better idea.

I was trying to incorporate this with as minimal changes as needed on the batocera-linux side.

[nadenislamarre]

for this one there is some work on configgen first to separate part in 2. no correct idea of how to do for the moment.

[Mikhailzrick]

for this one there is some work on configgen first to separate part in 2. no correct idea of how to do for the moment.

I don’t think it’s required to do that to gain a benefit. But it’s optional if you want to do that. I’ve tested it with the configgen stack as it is now and there’s still a benefit to be had.

See batocera-linux/batocera.linux#16275 as an example.