comments fell behind the code. In this case, it's better to use a better
name than "iSize" which indicates units, eg. "iBytes" or "iFrames", than
to explain the units in a comment.
LoadingWindow_SDL. (This is still marginally useful, since we don't have a native
X11, non-GTK loading window yet. But using SDL at all is a hassle, and it hasn't
been active in a long time, so let's remove this and add a native loading
window later if wanted instead of keeping this around.)
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.
Glenn Maynard