Sun, 10 Feb 2019 15:45:01 -0500 cmake: Special build target names ("dist" "docs" "uninstall") can be renamed.
Ryan C. Gordon <icculus@icculus.org> [Sun, 10 Feb 2019 15:45:01 -0500] rev 1654
cmake: Special build target names ("dist" "docs" "uninstall") can be renamed.
Sat, 26 Jan 2019 03:00:29 -0500 Allow builds to opt-out or opt-in to specific archivers, whichever's easier.
Ryan C. Gordon <icculus@icculus.org> [Sat, 26 Jan 2019 03:00:29 -0500] rev 1653
Allow builds to opt-out or opt-in to specific archivers, whichever's easier.
Wed, 28 Nov 2018 00:23:08 -0500 Fixed some compiler warnings.
Ryan C. Gordon <icculus@icculus.org> [Wed, 28 Nov 2018 00:23:08 -0500] rev 1652
Fixed some compiler warnings.
Tue, 27 Nov 2018 23:53:33 -0500 PHYSFS_flush() shouldn't call PHYSFS_Io::flush(). stable-3.0
Ryan C. Gordon <icculus@icculus.org> [Tue, 27 Nov 2018 23:53:33 -0500] rev 1651
PHYSFS_flush() shouldn't call PHYSFS_Io::flush(). The former is meant to send PhysicsFS-buffered data to the PHYSFS_Io's implementation, the latter is meant to tell the OS to definitely make sure the data is safely written to disk (or at least, that's what it does in practice). This was making PHYSFS_setBuffer()'d handles _slower_, since they would end up blocking whenever the buffer was full until the data made the full trip to physical media, instead of just letting the OS do its own buffering. Now we still PHYSFS_Io::flush() on PHYSFS_close(), like this has always worked. That might also be overkill, but that remains a historical artifact of trying to keep the underlying file handle usable if pending writes fail for possibly-recoverable reasons (which isn't guaranteed if you just close() it, at least as far as I remember). (transplanted from 8b3cc36531c6ac09dbac98d3774921bdf14b240d)
Tue, 27 Nov 2018 23:53:33 -0500 PHYSFS_flush() shouldn't call PHYSFS_Io::flush().
Ryan C. Gordon <icculus@icculus.org> [Tue, 27 Nov 2018 23:53:33 -0500] rev 1650
PHYSFS_flush() shouldn't call PHYSFS_Io::flush(). The former is meant to send PhysicsFS-buffered data to the PHYSFS_Io's implementation, the latter is meant to tell the OS to definitely make sure the data is safely written to disk (or at least, that's what it does in practice). This was making PHYSFS_setBuffer()'d handles _slower_, since they would end up blocking whenever the buffer was full until the data made the full trip to physical media, instead of just letting the OS do its own buffering. Now we still PHYSFS_Io::flush() on PHYSFS_close(), like this has always worked. That might also be overkill, but that remains a historical artifact of trying to keep the underlying file handle usable if pending writes fail for possibly-recoverable reasons (which isn't guaranteed if you just close() it, at least as far as I remember).
Wed, 17 Oct 2018 23:44:02 -0400 Added PHYSFS_setRoot().
Ryan C. Gordon <icculus@icculus.org> [Wed, 17 Oct 2018 23:44:02 -0400] rev 1649
Added PHYSFS_setRoot().
Wed, 03 Oct 2018 22:45:05 -0400 Fixed Win10's GetUserProfileDirectory() bug in stable-1.0 branch. stable-1.0
Ryan C. Gordon <icculus@icculus.org> [Wed, 03 Oct 2018 22:45:05 -0400] rev 1648
Fixed Win10's GetUserProfileDirectory() bug in stable-1.0 branch.
Wed, 03 Oct 2018 22:44:29 -0400 Fix Win10's GetUserProfileDirectory() problem in stable-2.0 branch. stable-2.0
Ryan C. Gordon <icculus@icculus.org> [Wed, 03 Oct 2018 22:44:29 -0400] rev 1647
Fix Win10's GetUserProfileDirectory() problem in stable-2.0 branch.
Wed, 03 Oct 2018 22:40:57 -0400 windows: Workaround GetUserProfileDirectory's API change in Win10 build 1809.
Ryan C. Gordon <icculus@icculus.org> [Wed, 03 Oct 2018 22:40:57 -0400] rev 1646
windows: Workaround GetUserProfileDirectory's API change in Win10 build 1809. (transplanted from ece6769c0676c2d4e8a5893a1acebd0f65456817)
Wed, 03 Oct 2018 22:40:57 -0400 windows: Workaround GetUserProfileDirectory's API change in Win10 build 1809. stable-3.0
Ryan C. Gordon <icculus@icculus.org> [Wed, 03 Oct 2018 22:40:57 -0400] rev 1645
windows: Workaround GetUserProfileDirectory's API change in Win10 build 1809.
(0) -1000 -300 -100 -10 +10 tip