From 76a78be634429f3593a4a1f6958d36b9cfa122b6 Mon Sep 17 00:00:00 2001 From: "B. Watson" Date: Sat, 9 Jan 2016 17:10:23 -0500 Subject: code shrinkage --- README.txt | 39 ++++++++++++++++++++++++++++++++++----- 1 file changed, 34 insertions(+), 5 deletions(-) (limited to 'README.txt') 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. -- cgit v1.2.3