I had an idea for a game. You'd use the joystick to control the physical Lego robot against on-screen challenges such as places you must hit and other places (evil robots) you must not hit, within a certain time, in order to win. There would be penalties for going out-of-bounds (colliding with the square around the screen). I never wrote a BASIC game. This is a first for me. I figure it's a good idea to start by determining some (ahem) "basic" concepts. After all I'm using the extent of 7th-grade formal programming education combined with 30 more years of brainpower + improved understanding of programming logic. Starting by keeping it simple: sticking with Applesoft's lo-res mode. I already knew the screen is 0 through 39 horizontally/vertically (40x40) in lo-res mode. And I knew the joystick goes 0-255 each way. So, I figured 256/40 is 6.4, so if I divide the status of paddle 0 or 1 by 6.4 then I can say that's my plot point, right? Time for a science experiment... I came up with this: 10 X=PDL(0) : Y=PDL(1) 20 X=X/6.4 : Y=Y/6.4 Then I realized some positions would give me remainders. No good. Googled for how to round off numbers and discovered Applesoft's INT command. Also found a tip explaining that INT rounds off * no matter what the decimal may be *, so the trick is to always add 0.5 before doing the INT function. Okay, that makes sense. 10 X=PDL(0) : Y=PDL(1) 20 X=X/6.4 : X=X+0.5 30 Y=Y/6.4 : Y=Y+0.5 40 PRINT INT(X), PRINT INT(Y) : REM (so I get numeric confirmation in the bottom text area of the screen) 50 GR:COLOR=1 60 PLOT X,Y 70 GOTO 10 This worked fine going up and left, but not when going down and right. When I moved the joystick all the way down, the plot point turned into an exclamation mark. When I moved it all the way right, the computer beeped and said ILLEGAL QUANTITY ERROR IN 60. I have some vague ideas of what caused this, but my instinct was to fix it this way: Ran it that way. Holy moly, it worked! Thus the full code for my little experiment: 10 X=PDL(0) : Y=PDL(1) 20 X=X/6.4 : X=X+0.5 30 Y=Y/6.4 : Y=Y+0.5 40 PRINT INT(X), PRINT INT(Y) 50 GR:COLOR=1 60 IF X>39 THEN X=39 70 IF Y>39 THEN Y=39 80 PLOT X,Y 90 GOTO 10 Now I can move a plot point around the screen by using the joystick and without having to redraw a black point over the previous point each time. Then I had an epiphany... drum roll please... I ACCIDENTALLY JUST PROGRAMMED MY FIRST SPRITE! Cool. As I posted a few weeks ago when making the Lego robot code work, you guys can tease me if you like :) but this is a milestone. I stumbled onto how to code a sprite in BASIC. Granted, it's only lo-res graphics, but I would think the same exact method should work in hi-res graphics mode. Also some things aren't perfect -- when I run the program without touching the centered joystick, it reports a plot position of 18,23 -- so I'll experiment with the physical trim knobs. Low-quality video (to accompany lo-res graphics...) is here: http://www.snarc.net/EK_first_sprite.mp4 (It plays fine in VLC but appeared too tall in the default Linux Mint player.) _______________________________ 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
Also some things aren't perfect -- when I run the program without touching the centered joystick, it reports a plot position of 18,23 -- so I'll experiment with the physical trim knobs.
Quick update: small trim adjustment did the job. Now it defaults to 20,20 when I run the program.
but I would think the same exact method should work in hi-res graphics
Confirmed. :) Full-screen mode is 280x192, so I adjusted the line 20 divisor to 0.914 (256/280) and the line 30 divisor to 1.333 (256/192): 10 X=PDL(0) : Y=PDL(1) 20 X=X/0.914 : X=X+0.5 30 Y=Y/1.333 : Y=Y+0.5 40 PRINT INT(X), PRINT INT(Y) 50 HGR2:HCOLOR=1 60 IF X>279 THEN X=279 70 IF Y>191 THEN Y=191 80 HPLOT X,Y 90 GOTO 10 I appreciate that a single point, regardless of lores/hires mode, is hardly a real sprite. :) How do I move around something more complicated? I assume the process is much more involved.
Last post for tonight. Quick search on Google indicates that Applesoft doesn't do traditional sprites. So what's the Apple II approach to moving graphics around the screen, assuming I want more than just a plot point?* Looking forward to responses. -EK * I am asking ONLY about doing it in Applesoft BASIC. Yes, I understand assembly is much more powerful. Please do not fork my thread.
Last post for tonight.
I lied. :)
* I am asking ONLY about doing it in Applesoft BASIC. Yes, I understand assembly is much more powerful. Please do not fork my thread.
Found this helpful article: http://www.atarimagazines.com/compute/issue19/Animating_Applesoft_Graphics.p... .... skimmed it (I'll read it in full another time) .... sounds like I'll at least have to use some CALL commands to flip between screens 1 and 2, rather than watching everything redraw with each movement. Using a CALL would have made me skittish a month ago, simply because I'd never done it, but then I used the ultra-simple CALL -198 for the robot's backup alarm :) and got some warm/fuzzy gratification. Fear of the unknown is conquered! Bedtime for Bonzo.
participants (1)
-
Evan Koblentz