From 7ac76fb4e4117887f6fd80ca7d6659be88209313 Mon Sep 17 00:00:00 2001 From: "B. Watson" Date: Wed, 6 Jan 2016 17:38:48 -0500 Subject: finishing touches of compression, attempt to fix damage calc issue --- README.txt | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'README.txt') 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 -- cgit v1.2.3