You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add in ISaveRam implementation for C64, using the deltas of disks.
Add in better docs for `DeltaSerializer`.
Fix C64 not remembering disk changes when swapping disks (swapping disks essentially just reset the disk previously)
Copy file name to clipboardExpand all lines: src/BizHawk.Common/DeltaSerializer.cs
+30-18Lines changed: 30 additions & 18 deletions
Original file line number
Diff line number
Diff line change
@@ -5,30 +5,42 @@ namespace BizHawk.Common
5
5
{
6
6
/// <summary>
7
7
/// Serializes deltas between data, mainly for ROM like structures which are actually writable, and therefore the differences need to be saved
8
-
/// Uses simple RLE encoding to keep the size down
8
+
/// Uses a simple delta format in order to keep size down
9
+
/// DELTA FORMAT DETAILS FOLLOWS
10
+
/// The format comprises of an indeterminate amount of blocks. These blocks start with a 4 byte header. This header is read as a native endian 32-bit two's complement signed integer.
11
+
/// If the header is positive, then the header indicates the amount of bytes which are identical between the original and current spans.
12
+
/// Positive headers are blocks by themselves, so the next header will proceed immediately after a positive header.
13
+
/// If the header is negative, then the header indicates the negation of the amount of bytes which differ between the original and current spans.
14
+
/// A negative header will have the negated header amount of bytes proceed it, which will be the bitwise XOR between the original and differing bytes.
15
+
/// A header of -0x80000000 is considered ill-formed.
16
+
/// This format does not stipulate requirements for whether blocks of non-differing bytes necessarily will use a positive header.
17
+
/// Thus, an implementation is free to use negative headers only, although without combination of positive headers, this will obviously not have great results wrt final size.
18
+
/// More practically, an implementation may want to avoid using positive headers when the block is rather small (e.g. smaller than the header itself, and thus not shrinking the result).
19
+
/// Subsequently, it may not mind putting some identical bytes within the negative header's block.
20
+
/// XORing the same values result in 0, so doing this will not leave trace of the original data.
0 commit comments