Update README.txt.

1 files changed, 14 insertions, 16 deletions

diff --git a/README.txt b/README.txt
index c0d1e11..c29188f 100644
--- a/README.txt
+++ b/README.txt
@@ -32,7 +32,7 @@ e.g. in an emulator or with an SIO2PC cable on real hardware.
 
 At startup, you're asked "How many particles?". The more particles you
 enter here, the longer it will take to generate the image. The default
-(if you just press Return) is 1000, which generally takes 7 to 9
+(if you just press Return) is 1000, which generally takes 6.5 to 8
 minutes. For a quick test just to see what the result will look like,
 try 300, which should take less than a minute. The maximum is 65535,
 which takes around 18 minutes to run... but more than about 2000 is
@@ -51,15 +51,15 @@ generator by holding down the Start key. This will show the work in
 progress, but it will slow things down noticeably.
 
 After the image is finished generating, the screen DMA will be turned
-back on, so you can see it. The bottom line shows a menu, from which you
-can choose to:
+back on, so you can see it. The bottom line shows a menu, from which
+you can choose to:
 
-- Save: Save the image to disk. You'll be prompted for a filename, which
-  must be a complete filespec (examples: D:TEST.DLA, D2:THING.DLA).
-  The file will be the raw pixels, 8 per byte, 256 pixels (32 bytes)
-  per line, 192 lines. Size will be 6144 bytes, or 50 sectors on a
-  single-density disk. If an error happens while saving, you'll get
-  the chance to retry the save.
+- Save: Save the image to disk. You'll be prompted for a filename,
+  which must be a complete filespec (examples: D:TEST.DLA,
+  D2:THING.DLA). The file will be the raw pixels, 8 per byte, 256
+  pixels (32 bytes) per line, 192 lines. Size will be 6144 bytes,
+  or 50 sectors on a single-density disk. If an error happens while
+  saving, you'll get the chance to retry the save.
 
 - Redo: Run the generation process again, with the current particle count
   and seed type settings.
@@ -100,16 +100,14 @@ Notes
 It should be possible to optimize this a bit further, maybe shave
 another 5% to 10% off the run time.
 
-It might be nice to include several built-in seeds, besides the single
-dot in the middle of the screen. Possibilites: line, plus, 4 dots in a
-square pattern...
-
 There might be a quick way to limit the particles' movement outside
 the initial circle's radius. Right now, it's limited to a square area;
 width and height are the diameter of the circle plus 10 pixels. The
-corners of this square waste a lot of time; it'd be better to come
-up with a way to do an octagon (the square with the corners cut off),
-which shouldn't slow down the inner loop too much.
+corners of this square waste a lot of time; it'd be better to come up
+with a way to do an octagon (the square with the corners cut off),
+which shouldn't slow down the inner loop too much... I actually did
+implement this, but it was too slow (the time spent in calculations
+was longer than the time saved by doing them).
 
 Tech stuff: rather than calculate points on a circle in asm code,
 the tables of points for the 4 circle sizes are pre-calculated by a