code shrinkage

1 files changed, 34 insertions, 5 deletions

diff --git a/README.txt b/README.txt
index e361781..8bf0349 100644
--- a/README.txt
+++ b/README.txt
@@ -121,10 +121,11 @@ arcade game).
 
 Bugs! At least these:
 
-- When exiting to DOS and reloading, the title screen graphics are
-  messed up. The playtester who reported this was running on real
-  hardware (not an emulator). I can't see how this is happening, but I
-  expect it's related to this:
+- Semi-fixed: When exiting to DOS and reloading, the title screen
+  graphics are messed up. The playtester who reported this was running
+  on real hardware (not an emulator). Getting the BSS below $9000 seems
+  to have fixed it. I can't see how this is happening, but I expect it's
+  related to this:
 
 - The BSS can overlap the start of the title screen (it's very close
   anyway). Consequences: There is a momentary graphics glitch when the
@@ -178,7 +179,9 @@ Bugs! At least these:
 - After a fight, "Arriving at Manila" or such would sometimes appears on the
   fight screen without clearing it first (if you ran away, you can still
   see ships). I *think* this is fixed, but I don't understand what caused
-  it so I'm leaving it in this list in case I'm wrong.
+  it so I'm leaving it in this list in case I'm wrong.... and I'm wrong,
+  because it just happened to me again. sea_battle() is returning something
+  unexpected, but how?
 
 Differences between the Apple II original and Linux port:
 
@@ -252,6 +255,22 @@ Other things that need doing to the code:
 
 - Decide what to do about integer overflow. Possibilities:
 
+  - This one seems like the best solution to me. The rest of the
+    stuff listed here is left for reference (for now). Here we go: Keep
+    using unsigned long for cash and debt, and use a ROM float for the
+    bank only. If you try to make a sale, borrow from wu, or withdraw an
+    amount that would overflow 32-bit cash, "Taipan, you cannot carry so
+    much cash! Your ship would sink under the weight of your riches!". If
+    pirate booty would overflow, don't award it. If debt interest would
+    result in overflow, the player gets assassinated instead. Advantages
+    of this: less code has to be changed, and the FP stuff is limited
+    so we don't need a good API for it, just a few functions that can
+    call the ROM directly, as needed: bank_deposit(), bank_withdraw(),
+    bank_interest(), bank_compare(). These will need a common ul_to_fp().
+    Also need a would_overflow(unsigned long value, unsigned long amount)
+    to return true if adding value + amount would overflow... actually it
+    can return MAX_LONG - value (still true, but also useful as a value).
+
   - 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:
@@ -279,6 +298,16 @@ Other things that need doing to the code:
     million", this would be faster/easier than a regular bigint.
     Maxes out at 429,496,729,600,000 (429 trillion).
 
+  - Another hybrid idea, might be faster: one long ranging up to
+    999,999,999, or 1 billion - 1, and an unsigned int for the top
+    bits. Existing cprintfancy() can handle the bottom part, if the
+    top is 0. If not, we only ever need the top digit of the bottom
+    (e.g. the .2 in "1.2 billion"), and then only if the top int is
+    less than 10. Maxes out at 65.535 trillion, meaning we'll need
+    to be able to print "Trillion", perhaps with no space. This is
+    approximately equivalent to a 46-bit int, but uses 48 bits of
+    storage.
+
   - Leave it as-is. Obviously the easiest option, but not very satisfying.
     Maxes out at a measly 4.2 billion.