Added animation for notification popout.

[schmurger]

Added spacing between multiple notifications Implemented notification animation with duration in emu config

@otavepto For some reason the notification duration lasts more than 0.5s as configured in the file. I'm not sure how the clock ticks in this program. Do you have any insights?

[otavepto]

Regarding the timing, this is the relevant code, it's checking for elapsed time in millisec By the way, this was implemented by ce20fdf2 so don't blame me 😄 (tons of thanks to them of course, just kidding) https://github.com/otavepto/gbe_fork/blob/5adf83ee109f0a599922236e551b799fdefebdfc/overlay_experimental/steam_overlay.cpp#L924-L926

Which is triggered from the ingame overlay project library (polling whenever the game presents a frame) https://github.com/otavepto/gbe_fork/blob/5adf83ee109f0a599922236e551b799fdefebdfc/overlay_experimental/steam_overlay.cpp#L1161-L1163

And these are the builtin timings https://github.com/otavepto/gbe_fork/blob/5adf83ee109f0a599922236e551b799fdefebdfc/overlay_experimental/overlay/steam_overlay.h#L65-L68

• 2 sec fading in
• 6 + 2 + 2 = 10 sec show time
• 10 - 2 = 8 sec fading out

(I hope my math didn't fail me)

Try using the debug build and call the macro PRINT_DEBUG to print the current time, elapsed time, etc... until you see where it's failing to behave as expected. The new button Test Achievement will help a lot

Edit: I might have misunderstood your question, after looking at the code I assume you're asking about your new implementation. I'll pull the code sometime in the upcoming days and see what could be the problem, thanks for your contributions nonetheless

[otavepto]

@schmurger Found the problem, the notification start_time was using std::chrono::seconds so it was always loosing precision. Now the sliding in and out animations are working as expected, previously the sliding in animation was being skipped on my end. I've made also some other changes, please pull the new code, review it, and test it. If all are good for you, I'll merge it 👍 Thanks for your contributions.

[schmurger]

Now it all makes sense. I couldn't figure it out why sometime the sliding in animation would play and other times it would not. I though it has to do with some overlay initialization. Thanks for finding the bug. The new changes work well in my testing, feel free to merge.

[otavepto]

@schmurger Wanted to let you know I changed the way aggregated/stacked notifications are handled. Previously there was an increasing counter, separate for each position.

This worked because the height was always fixed, so it was just a matter of determining the index of the current notification, then the vertical distance = notification_index * fixed_height

Since things are now dynamic this became somewhat broken especially for chat messages. To solve it, I decided to save the last notification's screen coordinates and build the next one relative to that. This is actually much easier since we have all the required info:

• Each notification height
• The coordinate/height of the last notification

So now the vertical distance = total_screen_height - last notification_coordinate

The are subtle differences here and there since each position is easier to handle if the 0-point of the y-axis is assumed to be either at the top or bottom, but nonetheless ImGui defines the screen top as y=0 Also each position either builds notifications upwards or downwards, this also introduced a minor inconvenience.

https://github.com/otavepto/gbe_fork/blob/b3d7778747b2843e0835303c788aa9a9ed76b6d3/overlay_experimental/steam_overlay.cpp#L910-L915 As an example, in this position, we are building upwards, and remeber ImGui defines the top of any window as y=0, so the vertical distance = screen height (we end up at the very bottom of the screen now) - our notification height (the notification is visible now) - the last coordinate/height (and we are now above the last notification as required)

When we save this position for the upcoming notification, we want to save the total consumed height, which would be total screen height - our y-coordinate/height which we just calculated (remember top is y=0, so our current y-coordinate is counting down from the max value, which is screen height!)

l <<< y = 0
l ^
l ^
l ^
l ^
l ^
l <<< our notification is here with y-coordinate = 900, so total consumed height so far = 920 - 900 = 20 px
l ^
l ^
l <<< screen height = 920 px