if( m_iBufferBytesFilled > m_iWriteAhead )
int iNumBytesEmpty = m_iWriteAhead - m_iBufferBytesFilled;
if( iNumBytesEmpty < iChunksize )
The latter, manipulated a bit, is actually:
if( m_iBufferBytesFilled+iChunksize >= m_iWriteAhead )
These do almost the same thing. This isn't what was intended. The
former checks whether we *want* to write another buffer (based on our
preferred writeahead). The latter was meant to check whether it's *possible*
to fit another chunk into the buffer. It should check against m_iBufferSize,
not m_iWriteAhead.
This fixes writeahead: 4096 means "write if we have less than 4096 frames
buffered", not "write if writing the new chunk would result in still having
less than 4096 frames buffered". This is important on slower devices, like
USB headsets.
D3D has the best response to these reference leaks ever: on shutdown, some
part of window closing or screen mode resetting will freeze for about five seconds,
depending on the window mode. No indication why is given.
is much less unintrusive, and fixes crashes on most "retry" theme dialogs due
to reloading and resetting Lua and other things unexpectedly in the middle of
a screen load.
into one theme. I'm not sure why this was done originally, but it was probably
related to the ugly "fallback themes can fork Fallback" behavior that was
removed recently.
This is simpler, and reduces overhead in looking up theme metrics.
aligned by default; we add the value of GetLineWidthInSourcePixels to right-
align (and n/2 to center-align). This causes left-alignment to be flush, with
overdraw over the alignment (correct), but right-alignment to align against
the overdraw. This causes fonts with borders to align with the border over
the edge on the left and against the edge on the right.
If we only include overdraw for cropping and scaling, and not positioning, then
we're inconsistent. For example, if we have a border with 100 pixels of space,
and we scale to 100 pixels in this way, the text will be scaled to exactly 100
pixels, but if left- or right-aligned against the border, will overlap the border
and not actually use the whole space. We need to be consistent: either consider
the overdraw part of the character or don't.
Ultimately, the overdraw was intended to not be considered part of the character
itself. It's intended for use with fonts with borders/strokes/glow around lettering.
That causes every character in a font to be widened, usually uniformly. This
tends to not increase the subjective width of the character: if aligning hard
against a border, these features should be ignored. So, let's go back to the
original intent, and don't consider overdraw part of the character.
common case. Normally, most songs in most courses are static. Previously,
in those cases, the filtered song list would never be generated; now it's
generated for every course. Optimize the filtering (erase() on a vector is
slow).
Remove m_bgOptionsOut, m_bgNoOptionsOut; these were only used for delays, which
we can do by sleeping on the options message commands. Remove SM_TweenOffOptionsMessage;
treat that as part of FadingOut.
(Not sure whether to use the choice name or the GameCommand m_sName.
The GameCommand name is used to identify asset names. However, we
already have a Choice name here, and it's weird having two names: the
GC name just seems like a confusing extra layer of indirection. Hmm ...)
Glenn Maynard