What's wrong with my program experiment?
A month-ish ago I posted about my Applesoft learning experiment in which I figured out how to make a point (in lo-res and hi-res alike) move around the screen with the joystick. At the time I couldn't figure out how to keep other images stationary (vs. redrawing themselves every time the joystick-checking code looped). Last night I solved that by (duh!) drawing a stationary point first and then looping back only as far as the joystick code. At first it left a trail, but then I added a line to immediately re-draw the same coordinates in black. 10 GR:COLOR=2 20 PLOT 10,10 30 X=PDL(0):Y=PDL(1) 40 X=X/6.4:Y=Y/6.4 50 X=X+0.5:Y=Y+0.5 60 X=INT(X):Y=INT(Y) 70 IF X>39 THEN X=39:IF Y>39 THEN Y=39 (because at one point I got an illegal quantity error when I moved the stick to the right) 80 PLOT X,Y:PRINT INT(X),INT(Y) 90 FOR W=1 TO 50: NEXT W 100 COLOR=0:PLOT X,Y:COLOR=2 110 GOTO 30 This works: the point at 10,10 remains solid while only the stick-controlled point moves. (I don't want to hear any snobby insults about "spaghetti code". This is not the actual application I'm working on. It's just a code snippet for the learning experiment.) (The results are the same if I eliminate lines 50 and 60. Those lines only exist to round up the numbers on .5, because INT only rounds down, and to eliminate remainders when it prints the coordinates.) However there may be a problem with the joystick or maybe a bug that I'm not seeing. All four corners are reporting the correct values: 0,0; 0,39; 39,0; and 39,39. When the stick centers I get 21,12. :( But if I adjust the trim wheels then the corners aren't right. Is this a joystick problem or a software bug?
Disregard my entire post from earlier today. :) Here's a smarter post: I'm using the Apple joystick A2M2002. Ran this test program: 10 X=PDL(0):Y=PDL(1) 20 PRINT X,Y 30 GOTO 10 The four corners report correctly (0,0; 0,255; 255,0; 255,255) but when the joystick centers it shows 130,89. If I adjust the trim knobs then the corners would be wrong. How do I fix this?
We're dealing with probably worn analog potentiometers; 130 is close enough to 127 that it shouldn't matter. Check how much of a dead zone you have first by wiggling the stick around lightly and seeing what the minimum and max for x and y are without engaging the springs at all. There's not much you can do to fix this dead zone, if present, short of finding another joystick, its equivalent to machinist equipment backlash. The problematic direction is Y, so adjust the trimmer until it is near 127 when centered in the 'middle' of the dead zone, and then pull it to 255,255 corner and adjust slightly until it just barely hits 255,255. That's pretty much the best you can do, short of replacing the Y potentiometer with one which acts more linear. On 4/5/2017 6:26 PM, Evan Koblentz via vcf-midatlantic wrote:
Disregard my entire post from earlier today. :) Here's a smarter post:
I'm using the Apple joystick A2M2002.
Ran this test program:
10 X=PDL(0):Y=PDL(1) 20 PRINT X,Y 30 GOTO 10
The four corners report correctly (0,0; 0,255; 255,0; 255,255) but when the joystick centers it shows 130,89. If I adjust the trim knobs then the corners would be wrong.
How do I fix this?
-- Jonathan Gevaryahu jgevaryahu@gmail.com jgevaryahu@hotmail.com
Evan wrote: "All four corners are reporting the correct values: 0,0; 0,39; 39,0; and 39,39. When the stick centers I get 21,12. :( But if I adjust the trim wheels then the corners aren't right. Is this a joystick problem or a software bug?" The joystick output does not necessarily match the screen size, nor is it necessarily linear. You usually have to scale the joystick, and possibly ask the user to put the joystick in the upper left and lower right corners and press a button to "calibrate" the joystick vs the screen. Touch screens have often had such a calibrate routine -- the Palm Pilot comes to mind. Bill Dudley This email is free of malware because I run Linux. On Wed, Apr 5, 2017 at 2:21 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
A month-ish ago I posted about my Applesoft learning experiment in which I figured out how to make a point (in lo-res and hi-res alike) move around the screen with the joystick.
At the time I couldn't figure out how to keep other images stationary (vs. redrawing themselves every time the joystick-checking code looped). Last night I solved that by (duh!) drawing a stationary point first and then looping back only as far as the joystick code. At first it left a trail, but then I added a line to immediately re-draw the same coordinates in black.
10 GR:COLOR=2 20 PLOT 10,10 30 X=PDL(0):Y=PDL(1) 40 X=X/6.4:Y=Y/6.4 50 X=X+0.5:Y=Y+0.5 60 X=INT(X):Y=INT(Y) 70 IF X>39 THEN X=39:IF Y>39 THEN Y=39 (because at one point I got an illegal quantity error when I moved the stick to the right) 80 PLOT X,Y:PRINT INT(X),INT(Y) 90 FOR W=1 TO 50: NEXT W 100 COLOR=0:PLOT X,Y:COLOR=2 110 GOTO 30
This works: the point at 10,10 remains solid while only the stick-controlled point moves. (I don't want to hear any snobby insults about "spaghetti code". This is not the actual application I'm working on. It's just a code snippet for the learning experiment.)
(The results are the same if I eliminate lines 50 and 60. Those lines only exist to round up the numbers on .5, because INT only rounds down, and to eliminate remainders when it prints the coordinates.)
However there may be a problem with the joystick or maybe a bug that I'm not seeing.
All four corners are reporting the correct values: 0,0; 0,39; 39,0; and 39,39. When the stick centers I get 21,12. :( But if I adjust the trim wheels then the corners aren't right.
Is this a joystick problem or a software bug?
Mike Willegal suggested putting a delay in line 30 between checking each paddle. That fixed it! Now it works without line 70 or any other of the correction methods that I thought were needed. The simplified program: 10 GR:COLOR=2 20 PLOT 10,10 30 X=PDL(0):FOR W=1 TO 25:NEXT W:Y=PDL(1) 40 X=X/6.4:Y=Y/6.4 50 PLOT X,Y:PRINT INT(X),INT(Y) 60 FOR W=1 TO 50: NEXT W 70 COLOR=0:PLOT X,Y:COLOR=2 80 GOTO 30 Hi-res version: 10 HGR:COLOR=2 20 HPLOT 10,10 30 X=PDL(0):FOR WE=1 TO 25:NEXT W:Y=PDL(1) 40 X=X/6.4:Y=Y/6.4 50 PLOT X,Y:PRINT INT(X),INT(Y) 60 FOR W=1 TO 50: NEXT W 70 COLOR=0:PLOT X,Y:COLOR=2 80 GOTO 30
Mike Willegal suggested putting a delay in line 30 between checking each paddle. That fixed it!
PS. Why does it work? Mike, Dan R., etc. say paddle cross-talk is the reason why a delay is needed. See the paddle section at http://www.easy68k.com/paulrsm/6502/AAL/AAL8209.TXT. Further discussion in the Apple II Enthusiasts group on Facebook...
On Wed, Apr 5, 2017 at 11:00 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Mike Willegal suggested putting a delay in line 30 between checking each
paddle. That fixed it!
PS. Why does it work? Mike, Dan R., etc. say paddle cross-talk is the reason why a delay is needed. See the paddle section at http://www.easy68k.com/paulrsm/6502/AAL/AAL8209.TXT. Further discussion in the Apple II Enthusiasts group on Facebook...
some other guy mentioned cross-talk, that's why I posted that link to the 1982 issue which explains how that operates. It also mentions a work around in Assembly code, since adding more delay defeats the purpose of using assembly code. But I'm not sure yet if there's a work around for Basic code, maybe there is, perhaps using the same Kernal Rom Calls. But then your game isn't really time critical as in an assembly program. So you most likely won't suffer any lag.
some other guy mentioned cross-talk, that's why I posted that link to the 1982 issue which explains how that operates. It also mentions a work around in Assembly code, since adding more delay defeats the purpose of using assembly code. But I'm not sure yet if there's a work around for Basic code, maybe there is, perhaps using the same Kernal Rom Calls. But then your game isn't really time critical as in an assembly program. So you most likely won't suffer any lag.
Yeah I'm happy with how it works now. Primitive collision detection 101: I added a line that if X=10 and Y=10 (where I'd made a plot) then switch to text mode and print something. It didn't work and I wasn't sure why. Then I remembered the joystick is never * exactly * at 10,10, but rather at 10.(lots of decimals). So I put in another line saying X=INT(X):Y=INT(Y) to force the whole number. Now when I move the joystick to the plot of 10,10 it works. Per a suggestion at http://www.vcfed.org/forum/showthread.php?57097-Joystick-problem&p=455221#po... I'll probably make a version of the game where the plot location is random and if you hit it then you found the kitten. :) Non-kitten plot locations could be (gasp) educational: you found a minicomputer, you found a tape library, etc., and each one would teach you something about that artifact. ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)(3) educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation instagram.com/vcfederation
On 04/06/2017 05:38 PM, Evan Koblentz via vcf-midatlantic wrote:
some other guy mentioned cross-talk, that's why I posted that link to the 1982 issue which explains how that operates. It also mentions a work around in Assembly code, since adding more delay defeats the purpose of using assembly code. But I'm not sure yet if there's a work around for Basic code, maybe there is, perhaps using the same Kernal Rom Calls. But then your game isn't really time critical as in an assembly program. So you most likely won't suffer any lag.
Yeah I'm happy with how it works now.
Primitive collision detection 101: I added a line that if X=10 and Y=10 (where I'd made a plot) then switch to text mode and print something. It didn't work and I wasn't sure why. Then I remembered the joystick is never * exactly * at 10,10, but rather at 10.(lots of decimals). So I put in another line saying X=INT(X):Y=INT(Y) to force the whole number. Now when I move the joystick to the plot of 10,10 it works.
Much goodness. This is a classic input qualification/range bounding problem. It's generally considered to be much safer to just check to see if X>10, rather than look for equality. This handles the fractional data as well of course. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
On Thu, Apr 6, 2017 at 5:38 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
some other guy mentioned cross-talk, that's why I posted that link to the
1982 issue which explains how that operates. It also mentions a work around in Assembly code, since adding more delay defeats the purpose of using assembly code. But I'm not sure yet if there's a work around for Basic code, maybe there is, perhaps using the same Kernal Rom Calls. But then your game isn't really time critical as in an assembly program. So you most likely won't suffer any lag.
Yeah I'm happy with how it works now.
Primitive collision detection 101: I added a line that if X=10 and Y=10 (where I'd made a plot) then switch to text mode and print something. It didn't work and I wasn't sure why. Then I remembered the joystick is never * exactly * at 10,10, but rather at 10.(lots of decimals). So I put in another line saying X=INT(X):Y=INT(Y) to force the whole number. Now when I move the joystick to the plot of 10,10 it works.
Per a suggestion at http://www.vcfed.org/forum/sho wthread.php?57097-Joystick-problem&p=455221#post455221 I'll probably make a version of the game where the plot location is random and if you hit it then you found the kitten. :) Non-kitten plot locations could be (gasp) educational: you found a minicomputer, you found a tape library, etc., and each one would teach you something about that artifact.
yea that's all what collision detection amounted to on the Apple, just a bunch of IF/THEN's to check the coordinates each time you move Basically one IF/THEN for each object you place on the grid, And then if you have walls, that's some more, but those involve ranges because the wall extends over many pixels, either for X or Y So you would use some boolean logic in your IF/THEN's to check these ranges once you get some practice with that, then you can try using a 2 dimensional array, this would help you keep track of the objects on the grid, this will reduce the amount of changes to your code with your IF/THEN's whenever you change or move the objects at the beginning of the code you would fill up the array with your objects, walls, etc Then you only need one IF/THEN for everything, just compare the current x,y position to the 2-D array If the contents of the 2-D array is occupied, ie "not zero", then you hit the object This also allows assigning hit values to each object, within the array eg, if one object has a bigger value, you get a bigger bonus if you hit that one Dan
On Fri, Apr 7, 2017 at 7:01 AM, Dan Roganti <ragooman@gmail.com> wrote:
On Thu, Apr 6, 2017 at 5:38 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
some other guy mentioned cross-talk, that's why I posted that link to the
1982 issue which explains how that operates. It also mentions a work around in Assembly code, since adding more delay defeats the purpose of using assembly code. But I'm not sure yet if there's a work around for Basic code, maybe there is, perhaps using the same Kernal Rom Calls. But then your game isn't really time critical as in an assembly program. So you most likely won't suffer any lag.
Yeah I'm happy with how it works now.
Primitive collision detection 101: I added a line that if X=10 and Y=10 (where I'd made a plot) then switch to text mode and print something. It didn't work and I wasn't sure why. Then I remembered the joystick is never * exactly * at 10,10, but rather at 10.(lots of decimals). So I put in another line saying X=INT(X):Y=INT(Y) to force the whole number. Now when I move the joystick to the plot of 10,10 it works.
Per a suggestion at http://www.vcfed.org/forum/sho wthread.php?57097-Joystick-problem&p=455221#post455221 I'll probably make a version of the game where the plot location is random and if you hit it then you found the kitten. :) Non-kitten plot locations could be (gasp) educational: you found a minicomputer, you found a tape library, etc., and each one would teach you something about that artifact.
yea that's all what collision detection amounted to on the Apple, just a bunch of IF/THEN's to check the coordinates each time you move Basically one IF/THEN for each object you place on the grid, And then if you have walls, that's some more, but those involve ranges because the wall extends over many pixels, either for X or Y So you would use some boolean logic in your IF/THEN's to check these ranges
once you get some practice with that, then you can try using a 2 dimensional array, this would help you keep track of the objects on the grid, this will reduce the amount of changes to your code with your IF/THEN's whenever you change or move the objects at the beginning of the code you would fill up the array with your objects, walls, etc Then you only need one IF/THEN for everything, just compare the current x,y position to the 2-D array If the contents of the 2-D array is occupied, ie "not zero", then you hit the object This also allows assigning hit values to each object, within the array eg, if one object has a bigger value, you get a bigger bonus if you hit that one Dan
oh, I left out the Hi-Res graphics options, since I saw you wanted to use this too using Shape Tables with the DRAW command and checking the Collision counter Applesoft can let you automate the collision detection with this too There was a good writeup in NIBBLE magazine back in the early 80s http://www.appleii-box.de/APPLE2/CollisionCounter/CollisionCounter.pdf Dan
oh, I left out the Hi-Res graphics options, since I saw you wanted to use this too using Shape Tables with the DRAW command and checking the Collision counter Applesoft can let you automate the collision detection with this too There was a good writeup in NIBBLE magazine back in the early 80s http://www.appleii-box.de/APPLE2/CollisionCounter/CollisionCounter.pdf
Good to know. Decided to stick with lores for now. It's much easier for kids (and Evans...) to program/understand.
On Wed, Apr 5, 2017 at 2:21 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
At the time I couldn't figure out how to keep other images stationary (vs. redrawing themselves every time the joystick-checking code looped). Last night I solved that by (duh!) drawing a stationary point first and then looping back only as far as the joystick code. At first it left a trail, but then I added a line to immediately re-draw the same coordinates in black
That's cool how you discovered a trick used in the early days of programming these computers!
However there may be a problem with the joystick or maybe a bug that I'm not seeing.
You didn't include the code for the joystick. This may help de-bug it.
All four corners are reporting the correct values: 0,0; 0,39; 39,0; and 39,39. When the stick centers I get 21,12. :( But if I adjust the trim wheels then the corners aren't right.
Is this a joystick problem or a software bug?
I'm not sure I understand what the problem is exactly. You were able to move the image and have it erased. Does it not continue to move and erase? Is the problem with the coordinates resetting when the stick centers? I assume that "IF X>39 THEN X=39:IF Y>39 THEN Y=39" means that you want to keep the image on the screen and not go off the screen. If this is the case, then you also want to do it for the left side of the screen when it is 0. "IF X<0 THEN X=0:IF Y<0 THEN Y=0". -- Jeff Brace - ark72axow@gmail.com Sent from my Commodore 64 ========================================================
participants (7)
-
Dan Roganti -
Dave McGuire -
Evan Koblentz -
Evan Koblentz -
Jeffrey Brace -
Jonathan Gevaryahu -
William Dudley