From 82d926e62b1d40551457c9e7e03607d59a1c038a Mon Sep 17 00:00:00 2001
From: Glenn Maynard <gmaynard@users.sourceforge.net>
Date: Sat, 19 Apr 2003 09:07:40 +0000
Subject: [PATCH] If a message is delayed at all, always delay it at least two
 frames beyond the time given.

Explanation for one of those frames is in the comments.  I'm not sure why
the second frame is needed, but it seems to get rid of cases where actors
occasionally don't tween completely off screen.
---
 stepmania/src/Screen.cpp | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/stepmania/src/Screen.cpp b/stepmania/src/Screen.cpp
index a4bdf51846..049dc0d045 100644
--- a/stepmania/src/Screen.cpp
+++ b/stepmania/src/Screen.cpp
@@ -66,7 +66,34 @@ void Screen::Update( float fDeltaTime )
 	
 	unsigned i;
 	for( i=0; i<m_QueuedMessages.size(); i++ )
-		m_QueuedMessages[i].fDelayRemaining -= fDeltaTime;
+	{
+		/* Hack:
+		 *
+		 * If we simply subtract time and then send messages, we have a problem.
+		 * Messages are queued to arrive at specific times, and those times line
+		 * up with things like tweens finishing.  If we send the message at the
+		 * exact time given, then it'll be on the same cycle that would be rendering
+		 * the last frame of a tween (such as an object going off the screen).  However,
+		 * when we send the message, we're likely to set up a new screen, which
+		 * causes everything to stop in place; this results in actors occasionally
+		 * not quite finishing their tweens.
+		 *
+		 * Let's delay all messages that have a non-zero time an extra frame. 
+		 *
+		 * XXX: For some reason, I had to make this delay messages for *two* frames to
+		 * make this effect go away.  (SMMAX2 menu header tweens.)  I'm not sure why.
+		 */
+		if(m_QueuedMessages[i].fDelayRemaining > 0.0001f)
+		{
+			m_QueuedMessages[i].fDelayRemaining -= fDeltaTime;
+			m_QueuedMessages[i].fDelayRemaining = max(m_QueuedMessages[i].fDelayRemaining, 0.0001f);
+		} else {
+			/* Two 0.00008 delays add up to at least one 0.0001 delay, but don't count
+			 * Update(0)s.  This is hacky, until I figure out why the second frame
+			 * delay is needed ... */
+			m_QueuedMessages[i].fDelayRemaining -= max(fDeltaTime, 0.00008f);
+		}
+	}
 
 	/* Now dispatch messages.  If the number of messages on the queue changes
 	 * within HandleScreenMessage, someone cleared messages on the queue.  This