finishing touches of compression, attempt to fix damage calc issue

1 files changed, 58 insertions, 0 deletions

diff --git a/README.txt b/README.txt
index 9c8f1f7..bf03aab 100644
--- a/README.txt
+++ b/README.txt
@@ -215,6 +215,64 @@ I've made a few changes to the UI, compared to the Apple version:
 
 Other things that need doing to the code:
 
+- Decide what to do about integer overflow. Possibilities:
+
+  - Use a "bigint" library (e.g. 64-bit ints). Would still be
+    possible to overflow, but it would take a really determined
+    player. Disadvantage: slow. Maxes out at:
+    40-bit:   1,099,511,627,776 (1 trillion)
+    48-bit: 281,474,976,710,656 (281 trillion)
+    64-bit: 1.84467440737096e+19 (beaucoup!)
+
+  - Use the ROM floating point routines. Nobody's likely to ever
+    overflow them. But, would have to write wrapper code to call
+    them from C and convert longs to floats and back. And it'll
+    be slower than bigints even. Maxes out at 1.0e+97
+
+  - Use packed BCD (base 100) like the FP ROM, but as an integer (no
+    magnitude). Maxes out at:
+    6 bytes:      1,000,000,000,000 (1 trillion)
+    7 bytes:    100,000,000,000,000 (100 trillion)
+    8 bytes: 10,000,000,000,000,000 (10 quadrillion)
+    Advantage: as above, but more so: "1.2 million" gets even easier
+    to calculate. Math would be faster than FP, slower than 64-bit ints,
+    but conversion to/from longs would be slower.
+
+  - Use a hybrid data format: one long for the bottom 5 decimal digits,
+    range 0 to 99,9999 (value % 100000) and the other for the high part
+    (value / 100000). Advantage: the game prints strings like "1.2
+    million", this would be faster/easier than a regular bigint.
+    Maxes out at 429,496,729,600,000 (429 trillion).
+
+  - Leave it as-is. Obviously the easiest option, but not very satisfying.
+    Maxes out at a measly 4.2 billion.
+
+  Whatever format we pick, we'll run into limitations. The "Cash" area
+  of the display is only so wide, we can only fill it with so many
+  characters. At some point, we need artificial limits:
+
+  - If your debt maxes out: "Taipan, you have been assassinated!" and
+    the game is over.
+
+  - If the bank maxes out, stop calculating interest. On deposit,
+    "Taipan, the bank's coffers are full!"
+
+  - If cash maxes out, forcibly retire the player. "Taipan, you are now
+    so rich that you own the entire continent of Asia!" or maybe "Taipan,
+    your ship has sunk under the weight of your massive fortune!"
+
+  Tricky part about these limits is checking for overflow without
+  actually overflowing. E.g. instead of "cash += amount" we have to
+  write "if(cash + amount < cash) overflow(); else cash += amount".
+  Also, backing out of the call tree will be a PITA. longjmp() anyone?
+  cc65's implementation seems to work OK. If I use ROM floats, I
+  won't worry about this at all.
+
+  For display, "million" can become "billion" if needed... then "trillion"
+  but without a space in front ("1.2trillion"). We have enough room for
+  4 digits there, 9999trillion would be the max. Or, abbreviate "billion"
+  as "bil", allowing 4 more digits. "99999999 bil" would be 99 quadrillion.
+
 - Size optimization. Right now, the executable is almost 27K of code. I'd
   like it to at least fit on a 16K cartridge. A lot of the C code is
   redundant, and some things can be rewritten in asm if need be. I've