2020-06-20 22:36:17 +00:00
|
|
|
1 REM Newsgroups: comp.sys.apple2
|
|
|
|
|
2 REM From: mad.scientist.jr@gmail.com
|
|
|
|
|
3 REM Message-ID: <1193160910.224728.270640@z24g2000prh.googlegroups.com>
|
|
|
|
|
4 REM Subject: Re: woz' original "brick out" - source code , paddles
|
|
|
|
|
5 REM Date: Tue, 23 Oct 2007 17:35:10 -0000
|
|
|
|
|
|
|
|
|
|
10 REM APPLE II SIMPLE PONG V4
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
20 REM PASTE INTO Joshua Bell's EMULATOR AT inexorabletash.github.io/jsbasic/
|
2020-06-20 22:36:17 +00:00
|
|
|
25 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
30 REM TITLE SCREEN + PROMPT FOR CONTROLS
|
|
|
|
|
35 REM ++++++++++++++++++++++++++++++++++++++++
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
40 TEXT : PR#0 : HOME : REM ENTER TEXT MODE, CLEAR SCREEN
|
|
|
|
|
45 DEF FN pd(k) = (26 * pdl(k)) / 255 + 2 : REM DEFINE PADDLE-READING FUNCTION
|
|
|
|
|
46 REM DEF FN pr(k) = SGN(INT((pdl(k) - 55) / 146)) : REM (non-absolute) paddle function
|
|
|
|
|
49 PRINT "APPLE II SIMPLE PONG V4.1"
|
2020-06-20 22:36:17 +00:00
|
|
|
50 PRINT
|
|
|
|
|
51 PRINT "version 1 by aiiadict"
|
|
|
|
|
52 PRINT "tweaks by Mad Scientist Jr"
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
53 PRINT "and Alan Ratliff (2020)"
|
2020-06-20 22:36:17 +00:00
|
|
|
54 PRINT
|
|
|
|
|
55 PRINT "During game press Q to quit."
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
56 PRINT : HTAB 18 : PRINT "^ # ^" SPC(5) "^ # ^"
|
|
|
|
|
58 PRINT "TYPE K FOR KEYS" SPC(2) "A/S/D" SPC(5) "J/K/L" : HTAB 19 : PRINT "Z/X" SPC(7) "M/,"
|
|
|
|
|
59 PRINT " (# = STOP)" TAB(19) "v v" SPC(7) "v v" : PRINT : PRINT "OR P FOR PADDLES OR Q TO QUIT? ";
|
|
|
|
|
60 GET C$ : IF C$ <> "K" AND C$ <> "P" AND C$ <> "Q" GOTO 60
|
|
|
|
|
62 IF C$ = "Q" THEN VTAB 22 : GOTO 9000
|
2020-06-20 22:36:17 +00:00
|
|
|
65 REM
|
|
|
|
|
70 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
75 REM DRAW FIELD AND INITIALIZE GAME
|
|
|
|
|
80 REM ++++++++++++++++++++++++++++++++++++++++
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
85 HOME : GR: REM ENTER GRAPHIC MODE
|
2020-06-20 22:36:17 +00:00
|
|
|
90 COLOR= 7: VLIN 0,39 AT 0: VLIN 0,39 AT 39
|
|
|
|
|
95 HLIN 0,39 AT 0: HLIN 0,39 AT 39
|
|
|
|
|
100 bx = 10:by = 10:ox = 10:oy = 10: REM BALL START POSITION
|
|
|
|
|
102 dx = 1: dy = - 1: REM BALL DIRECTION
|
|
|
|
|
104 p1 = 10: o1 = 10: REM PLAYER 1 START POSITION
|
|
|
|
|
106 p2 = 10: o2 = 10: REM PLAYER 2 START POSITION
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
120 v1 = 0 : v2 = 0 : s1 = 0 : s2 = 0 : u1 = 0 : u2 = 0 :
|
|
|
|
|
125 PL = 8: REM PADDLE LENGTH
|
2020-06-20 22:36:17 +00:00
|
|
|
130 REM
|
|
|
|
|
145 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
150 REM BEGIN MAIN GAME LOOP
|
|
|
|
|
155 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
196 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
197 REM DRAW PADDLE1
|
|
|
|
|
198 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
200 IF o1 <> p1 THEN COLOR= 0: VLIN o1,o1 + PL AT 3
|
|
|
|
|
210 COLOR= 7: VLIN p1,p1 + PL AT 3
|
|
|
|
|
296 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
297 REM DRAW PADDLE2
|
|
|
|
|
298 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
300 IF o2 <> p2 THEN COLOR= 0: VLIN o2,o2 + PL AT 36
|
|
|
|
|
310 COLOR= 7: VLIN p2,p2 + PL AT 36
|
|
|
|
|
399 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
400 REM DRAW AND MOVE BALL
|
|
|
|
|
401 REM ++++++++++++++++++++++++++++++++++++++++
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
402 IF ox <> bx OR oy <> by THEN COLOR= 0: VLIN oy,oy + 1 AT ox
|
|
|
|
|
410 COLOR= 11: VLIN by,by + 1 AT bx
|
|
|
|
|
420 ox = bx : oy = by : bb = 1
|
|
|
|
|
470 bx = bx + dx
|
|
|
|
|
490 IF SCRN( bx,by) OR SCRN( bx, by + 1) THEN dx = -dx : k = (bx=3)*p1+(bx=36)*p2 : IF bx*2=39-dx*33 AND ((k>0)*by-PL/2-k+1)*dy > 0 THEN bb = 0
|
|
|
|
|
500 IF bx = 7 THEN u1 = 1
|
|
|
|
|
510 IF bx = 33 THEN u2 = 1
|
|
|
|
|
520 IF bx = 1 AND u1 THEN s2 = s2 + 1 : u1 = 0 : VTAB 22 : HTAB 41 - LEN(STR$(s2)) : PRINT s2;
|
|
|
|
|
530 IF bx = 38 AND u2 THEN s1 = s1 + 1 : u2 = 0 : VTAB 22 : HTAB 1 : PRINT s1
|
|
|
|
|
540 by = by + dy
|
|
|
|
|
840 IF (SCRN( bx,by) OR SCRN( bx, by + 1)) AND bb THEN dy = -dy
|
2020-06-20 22:36:17 +00:00
|
|
|
850 IF bx < 1 THEN bx = 1
|
|
|
|
|
860 IF bx > 38 THEN bx = 38
|
|
|
|
|
870 IF by < 1 THEN by = 1
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
880 IF by > 37 THEN by = 37
|
|
|
|
|
890 o1 = p1 : o2 = p2
|
2020-06-20 22:36:17 +00:00
|
|
|
900 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
901 REM GET PLAYER INPUT
|
|
|
|
|
902 REM ++++++++++++++++++++++++++++++++++++++++
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
903 IF PEEK ( - 16384) > 127 THEN GET K$: IF K$ = "Q" GOTO 9000 : REM SEE IF KEY PRESSED/Q FOR QUIT
|
2020-06-20 22:36:17 +00:00
|
|
|
904 IF C$ <> "K" THEN GOTO 921
|
|
|
|
|
905 REM
|
|
|
|
|
906 REM ----------------------------------------
|
|
|
|
|
907 REM KEYBOARD INPUT
|
|
|
|
|
909 REM ----------------------------------------
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
912 IF K$ = "A" OR K$ = "D" THEN v1 = -1
|
|
|
|
|
913 IF K$ = "S" THEN v1 = 0
|
|
|
|
|
914 IF K$ = "Z" OR K$ = "X" THEN v1 = 1
|
|
|
|
|
916 IF K$ = "J" OR K$ = "L" THEN v2 = -1
|
|
|
|
|
917 IF K$ = "K" THEN v2 = 0
|
|
|
|
|
918 IF K$ = "M" OR K$ = "," THEN v2 = 1
|
|
|
|
|
920 K$ = "" : p1 = p1 + v1 : p2 = p2 + v2 : GOTO 955
|
2020-06-20 22:36:17 +00:00
|
|
|
921 IF C$ <> "P" THEN GOTO 947
|
|
|
|
|
922 REM
|
|
|
|
|
923 REM ----------------------------------------
|
|
|
|
|
925 REM PADDLE INPUT
|
|
|
|
|
927 REM ----------------------------------------
|
|
|
|
|
930 REM simple (non-absolute) paddle input:
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
932 REM p1 = FN pr(0) + p1
|
|
|
|
|
934 REM p2 = FN pr(1) + p2
|
|
|
|
|
940 REM realtime (absolute position) paddle input:
|
|
|
|
|
944 p1 = FN pd(0)
|
|
|
|
|
945 p2 = FN pd(1)
|
2020-06-20 22:36:17 +00:00
|
|
|
947 REM
|
|
|
|
|
955 REM ++++++++++++++++++++++++++++++++++++++++
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
956 REM MAKE SURE PADDLES DON'T GO OFF SCREEN
|
2020-06-20 22:36:17 +00:00
|
|
|
958 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
960 IF p1 < 2 THEN p1 = 2
|
|
|
|
|
970 IF p1 > 28 THEN p1 = 28
|
|
|
|
|
980 IF p2 < 2 THEN p2 = 2
|
|
|
|
|
990 IF p2 > 28 THEN p2 = 28
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
999 GOTO 150
|
2020-06-20 22:36:17 +00:00
|
|
|
9000 REM
|
|
|
|
|
9010 REM ++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
9020 REM QUIT GAME
|
|
|
|
|
9030 REM ++++++++++++++++++++++++++++++++++++++++
|
Several sample fixes/improvements by Alan Ratliff
**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).
2024-02-19 19:03:15 +00:00
|
|
|
9040 TEXT : REM HOME
|
|
|
|
|
9045 PRINT
|
|
|
|
|
9050 PRINT "FINISHED APPLE II SIMPLE PONG V4.1"
|