**In "Simple Pong" I eliminated the problem of the bouncing ball erasing the bottom wall of the field, created a means of scoring points (when the ball gets past a paddle and hits the "back wall", the other player scores a point -- one point each time the ball gets past the paddle, so that multiple impacts that typically occur don't count a point each), and allowed the possibility of equiangular bouncing off the paddles, instead of always just bouncing straight back along the same trajectory.
Also, this game isn't really suited for "paddle"-type control on this platform, as there is typically just one mouse for that purpose, not practical for two players. However, with key-control, the comments cited a problem of needing to be able to handle multiple keystrokes. As it was, when one player pressed a directional key, their paddle would start moving and not stop until it hit its upper/lower limit. It would stop, though, if a non-operational key were pressed, or one of the other player's keys. This latter meant that one player hitting a key to move their paddle would stop the other player's paddle from moving, which was where the real problem occurred. Underlying this was the fact all movement was controlled by the single last key pressed. I changed it by introducing variables to control the movement of each paddle which would be set by the appropriate keystrokes. I also added a specific key for each player to stop their paddle's motion, as well as duplicate directional keys so that each player's key group would be suitable for either the left or right hand: with either hand they could press "down" with the index finger, "stop" with the middle finger, and "up" with the fourth finger.
***With "Hangman", I did the usual random-seeding, avoided the initial-keystroke-termination problem, and simplified the word-choosing algorithm, and set it to go through all words in a difficulty-group, then continue by choosing among the 9 words in that group least-recently used. I also incorporated level-change options in the new-game menu, and I greatly reduced the code for the circle-drawing routine (while still utilizing principles of geometry), and re-organized the parts-drawing routines so the "smiley face" routine could be simplified.
***Next is the "Door Detector" game program. Its problems were subtle ones, principally that it would occasionally crash with an "Illegal quantity error in line 320". This concerned the value of "G" that was assigned as COLOR. This crash was quirky, as the program maintained the value of G between 0 and 15 in some places, but not others, while supposedly the value given to COLOR is not "Illegal" unless it's outside the byte-range 0-255; within that range the value merely has its lower nybble isolated to serve as the COLOR value. I put in a tweak to print the value of G to be used in line 320, and upon a crash it was shown as 50. I'm not sure why it occurred this way, but I figured that a way to be safe would be to just *always* ensure that G is kept in the range 0 to 15.
The program also had the "standard" problem that it didn't seed the random-number generator, so it always played an identical "game sequence" every time, instead of different permutaions as you'd normally expect with "random numbers".
Another "subtle" shortcoming I noticed concerned the fact that in successive "rooms" within a game, the "Death Zone" is an incrementally "thick" border region around the room, and in any given room the "exit" could be randomly placed right next to the "Death Zone's" edge, and as the player would start the next room where the previous room's exit was, a next-to-Death-Zone exit would mean the player would start the next room IN the Death Zone (its innermost layer). As it happened, in the one game-sequence that occurred, the final room's exit in the first game was along the Death Zone's edge, but as it was the FINAL room anyway, the next-room starting location was not an issue. I figured, though, that with the game properly randomized, the issue COULD come up, so I now use line 50 (commented in 40) to bump the player out of the Death Zone if they're starting a room within the Zone.
***With "Columns" there was the usual lack of random seeding, and again a rather drab color scheme for the lower number of colors. I also reduced the maximum number of colors by one, so that it would never use both of the indistinguishable grays. Also a comment on line 2840 mentioned a "Future animated splash screen", so I created one.
***The primary problem with "Chase" was lack of random seeding, so it always played the same sequence of games, which would wear out quickly. There were also a few duplicate line numbers I eliminated. The game presentation could also be improved by simply VTABbing up to display each new board layout over the old one, rather than scrolling up for new diagrams. Also, I documented in the instructions how a player should expect to encounter impossible situations frequently, and just move on when that happens; and I generally streamlined the code considerably, including cleaning up messy text displays.
***With "Gaussian distribution 2D", trying an example resulted in an "Illegal quantity in line 160". This was caused by the hires X coordinate just exceeding the maximum 279, apparently due to imprecise calculations. Reducing the designated maximum (assigned to 'w') in line 30 to a value of 278 seems to clear this up. I also reduced the maximum Y a bit so the diagram would not butt against the text on screen-line 21. In addition, there were a few (i.e. redundant) explicit expressions of the value of PI, all then multiplied by 2 to obtain 2PI; I replaced these with one derivation of PI/4 via ATN(1), multiplied by 8 to obtain 2PI, and stored it in variable 'p2' (for "PI * 2").
***With "Original Series Enterprise" I created a much more accurate depiction of said entity. To be honest, it really isn't Gil Keidar's anymore, it's mine...
***Finally, with "Prime Factors", the old version, in a number of cases, did not produce the correct results. I have fixed that problem. I also replaced its series of like multiplications (e.g. 2x2x2x2x2x2) with a base^exponent exprression (2^6).
See the new sample for details/example.
Note that reading 12/24-hour time formats that have colons will not
currently work, as the colons will terminate input and result in
invisible ?EXTRA IGNORED errors.
Fixes#44
* Create sample.aritm.txt
* Update index.html
* Added "01", ",1", and ".1" as alternatives to "-1"
* Updated year to 2022
* Initialze text mode & fix possible roundoff error
* Switched subroutines to functions & improved seed
* Create sample.aritm.txt
* Update index.html
* Added "01", ",1", and ".1" as alternatives to "-1"
* Updated year to 2022
* Initialze text mode & fix possible roundoff error
* Switched subroutines to functions & improved seed
The TTY module stores top/height but the Apple monitor stores
top/bottom. If top changes, bottom should remain unchanged.
Improve the POKE 34 shim, and add a test.
