Common file interface class, RageBasicFile, shared by RageFile
and RageFileObj. This makes most uses of these objects interchangeable.
RageFile is now just a simple wrapper for RageFileObj, to create
files in FILEMAN's namespace; file objects can also be created
independently. This means that, for example, IniFile can be used
to write a file to a CString, without having to jump through hoops,
and without having to use a separate file access wrapper; just do
something like:
RageFileObjMem string_file;
ini.WriteFile( string );
const CString &sString = string_file.GetString();
often simpler than seeking; that some drivers may only support rewinding;
and that, if supported, rewinding should never fail. However, there's really
no reason for it to be a separate API call.
object to a just-initialized state. deflateEnd() is correct (no comment
needed for that; it's obvious, I don't know why I used deflateReset to
begin with).
zlib doesn't appear to do anything special with allocations; running
the following:
#include <zlib.h>
main()
{
z_stream z; z.zalloc = NULL; z.zfree = NULL;
inflateInit2( &z, -MAX_WBITS ); inflateReset( &z );
}
under Valgrind shows:
==17033== 7080 bytes in 1 blocks are possibly lost in loss record 1 of 1
==17033== at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
==17033== by 0x1B91D4B4: zcalloc (in /usr/lib/libz.so.1.2.1.2)
==17033== by 0x1B91D608: inflateInit2_ (in /usr/lib/libz.so.1.2.1.2)
==17033== by 0x80485A4: main (in /home/glenn/a.out)
didn't make it work, since there was no cast overload to bool&, etc; it
just forced the (non-POD) type to that type, which resulted in the struct
being clobbered.
- eventually, this will reduce the gargantuan PrefsManager
- adding prefs doesn't require modifying PrefsManager.h and recompiling a lot
- starting with these options because they aren't in ScreenOptionsMaster
re-locking it. In some threads implementations (Linux 2.6), this causes the
mount thread to hog the lock, which causes SetMountThreadState to hang. Move
the "check and delay" part of the mount thread outside of the lock, so other
threads have opportunity to get the lock.
"DisableRadar=0 // turn this to 1 if you are experiencing trouble with the groove radar (voodoo3's)"
Theme metrics are not the correct place for dealing with driver bugs; users
can't be told to hack metrics.ini to make their system work. (I havn't seen
any reports of problems here in a long time, anyway.)
last input isn't a style button (StyleI.player isn't valid in that case).
StyleI is tied to "columns"; it's only used in screens that deal with columns:
gameplay, editor, name entry. Maybe we can derive it on demand in these
functions and not pass it around to dozens of functions that don't use it ...
to map to more than one column (useless), allow more than one button
to map to a column. This allows handling both UP and DOWN inputs for
a single SCRATCH column. (more work still needed for correct scratch
handling; also, due to the massive number of styles we have, some of these
entries may be incorrect)
Glenn Maynard