Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attract Mode Layout Freezes after aprox month of inactivity. #582

Closed
OzFalcon opened this issue Oct 5, 2019 · 10 comments

Comments

@OzFalcon
Copy link

commented Oct 5, 2019

Attract Mode Layout Freezes after approx month of inactivity.
This happens with or without screensaver enabled.
Tested with Grid & Attrac-Man Layout but I suspect any Layout will do the same.
ie. Attrac-Man ghosts etc will stop moving.
Or the screensaver will stop cycling images.
Layout/Menu input is lost. (One must switch out and manually kill the process).

This is a definite problem when onsite (Workplace or Entertainment room).
Testing is time consuming as you need a machine sitting idle for a month!!!

Attract mode itself is still running as a Date/Time display added to the Layout or Screensaver keeps ticking over (See attached DateTime.nut).
DateTime.nut.zip

@OzFalcon

This comment has been minimized.

Copy link
Author

commented Oct 5, 2019

It's also noted that Attrac-Man ghosts etc become more jerky the longer it is left running.
ie. It initially starts with smooth movement and progressively becomes jerky.

@oomek

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2019

May we know on what platform you're experiencing those freezes? We could try to make Attract Mode run without vsync, so we can investigate it without waiting a month.

@OzFalcon

This comment has been minimized.

Copy link
Author

commented Oct 5, 2019

May we know on what platform you're experiencing those freezes? We could try to make Attract Mode run without vsync, so we can investigate it without waiting a month.

It's running on Linux (Debian 10 Buster).
Is there a vsync option to use in attract.cfg?

@oomek

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2019

There isn't. We would have to prepare a test build for this purpose.

@OzFalcon

This comment has been minimized.

Copy link
Author

commented Oct 5, 2019

There isn't. We would have to prepare a test build for this purpose.

Would that require modifying a couple of lines or a temporary git branch?
I have two machines spare for testing that I could compile a non vsync version for.
(Dell OptiPlex 360 with onboard Intel G31 Express video & Intel Core 2 Duo CPU's)
Both running Debian 10.1 Buster. No desktop installed - Just X display server & ALSA.

@OzFalcon

This comment has been minimized.

Copy link
Author

commented Oct 6, 2019

Layouts are using "title.png" files, No Movie or Audio Clips.
Each "title.png" is 320x240 resolution for a total of 200 titles.
So it's a pretty lightweight load on the layout in general.
And compile is with: make EXTRA_CFLAGS=-march=core2

@oomek

This comment has been minimized.

Copy link
Collaborator

commented Oct 6, 2019

Currently ticktime is timer based which is not a good option for keeping animations smooth when you have multiple frame buffers. I was planning for a while to switch to frame based ticktime. Maybe now is the time to do it. @mickelson, what do you think about that?

@mickelson

This comment has been minimized.

Copy link
Owner

commented Oct 14, 2019

Currently ticktime is timer based which is not a good option for keeping animations smooth when you have multiple frame buffers. I was planning for a while to switch to frame based ticktime. Maybe now is the time to do it. @mickelson, what do you think about that?

I'd prefer not to change, as that would break everybody's existing layouts etc. and isn't the cause of the problem here.

I've had a chance to look at this issue, and the Attrac-Man layout freezing is due to an integer overflow once the layout time (passed to scripts in ms) exceeds 2,147,483,647.

The jerkyness that develops as the layout runs for a really long time is due to a loss of floating point precision in the calculations that the Attrac-Man layout does, because it was simply reusing layout time when trying to calculate precise placement.

I've got fixes for both of these problems that I'm just about to commit. I'm adding code to the frontend that will essentially force a layout that has been running for about a month to reset, to avoid the integer overflow. The fix for the jerky motion of the ghosts is specific to the Attrac-Man layout.

mickelson added a commit that referenced this issue Oct 14, 2019
- There was an integer overflow in the layout time being passed to
  layouts with each tick() call.  This overflow happened once the
  size of a 32 bit integer was reached (2,147,483,647).  The fix is
  that the frontend will now force the layout to reset right before
  this point, so a reset after about a month of running straight

- This patch also fixes jerky movements in the Attrac-Man layout
  that occur after it has been running for a significant period of
  time.  This was due to a loss of floating point precision in how
  the layout calculated ghost and player placements.
@mickelson mickelson closed this Oct 14, 2019
@oomek

This comment has been minimized.

Copy link
Collaborator

commented Oct 14, 2019

I've explained the benefits of frame based timing somwhere, some time ago. Can't find it on the phone now. In simple terms, the layouts wouldn't feel any difference, apart from more even timing. When you freeze redraws due to inactivity in transitions AM pushes all remaining buffers to the driver and when you resume drawing first 2-3 framses have 0-2 ms delta of tick time which is the side effect of not feeding the frame queue constantly as games do.

The idea is to measure the frame time and instead on relying on a timer we can keep incrementing tick time with frame time, if frame takes longer we fall back to the timer.

@oomek

This comment has been minimized.

Copy link
Collaborator

commented Oct 14, 2019

There is another thing that affects the smoothness of the animations, a low precision of tick time. At 60Hz you get 16, 17, 16, 17... ms delta.
By adding an optional parameter to tick function that returns frame time, but in microseconds like 16667 you could do better animations in the animation module or developers could handle animations using that directly. I can post the test layout which has 2 moving bars. One tick time based and another frame based so you can see the difference for yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.