51 replies to this topic

[orion1052003]

Thanks for your help, all. I've got a lot of questions. How can you set up JOYST control and input with CALL LOCATE? Would this be a better method then using CALL MOTION with CALL JOYST as in the XB manual?

Say you have a running sprite figure which must change sprite patterns to animate :

CALL SPRITE(#1,96,16,130,1,1,1) :: CALL MAGNIFY(4)

CALL JOYST(1,X,Y)


675 CALL MOTION(#1,-Y*2.5,X*2.5)

680 CALL PATTERN(#1,-Y*3+X+88)
700 FOR K=1 TO 50 :: NEXT K

710 CALL PATTERN(#1,-Y*3+X+124)

How might you change this work with CALL LOCATE instead?

Would this cause more precise joystick control?

[matthew180]

If you want the sprites to move via your program's control, then use LOCATE. The MOTION subroutine puts the sprite motion under control of the Interrupt Service Routine (ISR), which is triggered every 60th of a second (on NTSC, every 50th of a second on PAL) and written in assembly language, so the sprite motion is very smooth. The problem is, the 99/4A's BASIC (and XB) is very slow, so any kind of sprite control is going to be slow, which makes it painful for action games.

If you are trying to get a sprite to frame-animate as it moves, for example a running "guy", and have the "guy" under joystick control, then an example pseudo code might be:

while game is running
  read joystick
  update player
  do other stuff
wend
 
read joystick
  if up, dec y : set frame up
  if down, inc y : set frame down
  if left, dec x : dec frame
  if right, inc x : inc frame
end
 
update player
  CALL PATTERN frame
  CALL LOCATE x,y
end

[RXB]

I have CALL GMOTION in RXB so why not have a formula to look at any Sprite headed the direction of the other sprite?
I mean if it is -25,15 and the other sprite is -35,35 then eventually they will collide right?

Motion is the direction and speed so trajectory would indicate a collision. With only 49152 pixels the math should not be that bad.
I am not that good at math but does it make more sense scanning every single pixel as that is slow as heck. For all 32 sprites?

It both sprites are parallel then they will never collide and should never be checked. Only those that have opposite directions should be checked.

Edited by RXB, Mon Oct 3, 2011 2:20 PM.

[orion1052003]

Frames mean character redefinitions that like pictures of different stages of a game character's motion?(ship,man,horse)
Matthew, is this what you mean by using CALL LOCATE? If so, how would the second "frame" be shown to give the illusion of movement? These are the equations I used previously to show redefinitions(frame)1 and (frame)2....
CALL PATTERN(#1,-Y*3+X+88) CALL PATTERN(#1,-Y*3+X+124)
this came out to : center=88 up=76 down=100 left=84 right=92 FRAME 1
center=124 up=112 down=136 left=120 right=128 FRAME 2
--------------------------------------------------------------------------------------------------------
DR=130 DC=1

CALL JOYST(1,X,Y)
IF Y=0 AND X=0 THEN DR,DC=0 :: FRAME=88!CENTER
IF Y=4 THEN DR=DR-1 :: FRAME=76!UP
IF Y=-4 THEN DR=DR+1 :: FRAME=100!DOWN
IF X=-4 THEN DC=DC-1 :: FRAME=84!LEFT
IF X=4 THEN DC=DC+1 :: FRAME=92!RIGHT

CALL PATTERN(#1,FRAME)
CALL LOCATE(#1,DR,DC)

[matthew180]

For animation, like a walking sequence, you need to have multiple frames for each direction. Then you need to decide how to "flip" through the frames as the sprite moves to give the illusion of walking, running, or whatever. To keep it simple for now, make 4 walking frames in the left and right directions. Then when the joystick is pushed left or right, the X coordinate changes (either increments or decrements), and you need to select the "next" frame in the current sequence. You also need to know which direction the player is facing so you can switch which frame sequences you cycle.

There is a lot of overhead managing all this, which is why it is really nice to have a language that supports the idea of "structures" or "objects". You can make things easier by deciding that the player can only take 1 "step" when they move, i.e. run the full frame sequence (auto incrementing or decrementing the X or Y) before polling the joystick again. This means you will always "stop" at the start of the frame sequence, but it also means you always move a minimum of 4, 8, or however many number of pixels. If that works for you game, then it is an option.

Basically you probably need to track:

base_frame (pattern of first frame)
curr_frame (0 to max, added to base_frame)
max_frame

Another problem is trying not to hard code pattern numbers and such into the routines so your sprite management can be more generic (so you can use it for all animated objects in the game.)

Some pseudo code for the above ideas might be:

init:
  base_frame = 128
  curr_frame = 0
  max_frame = 4
 
while game loop
  player_input
  draw_player
wend
 
player_input:
  if no joystick
    return
  end if
 
  if left
    x -= 1
    curr_frame -= 1
    base_frame = 128
 
  else if right
    x += 1
    curr_frame += 1
    base_frame = 132
  end if
 
  if curr_frame < 0
    curr_frame = max_frame - 1
  else if curr_frame >= max_frame
    curr_frame = 0
  end if
end
 
draw_player
  pattern base_frame + curr_frame
  locate x,y
end

That does not track which way the player is facing, so when you reverse directions you will probably be in mid-step in the sequence, which may or may not look funny depending on what you are animating. Also, you may need to adjust X by more than 1 pixel to make the animation look right, etc. But basically the idea is that you update the animation frame in response to the user input. If you use MOTION, then chances are the sprites will be moving faster or out of sequence with your frame updating code and user input, so it will be a mess. XB just can't keep up in that way.

[orion1052003]

Although I copied it down to study, I honestly didn't understand any of the response. I think not understanding it has to do with the topic of frame rate. However slow, I was just doing a "mr. bojangles" alternating chars to create the illusion of movement, which I guess would be 2 frames. So let's say, imagine the intellivision man with legs in 2 poses alternating, moving back and forth, appearing to run however crudely. And a bit slowly but not so bad.

It took most of the character sets to do this at 4X! To have 2 pictures or redefinitions for each of the 8 directions and 1 standing there for the center when the man is not moving, took up 8 character sets. With the method I am using, there would be no more room for a third frame or picture of a position.

Would CALL LOCATE work with JOYST using this below method of CALL PATTERN I wrote in post 4?

CALL PATTERN(SPRITE#,equation) (equation - that equals a CHAR number that has been redefined as a picture position.) Where, say, 88 may be a man running in position 1 and 92 could be a man running in position 2.

[sometimes99er]

100 CALL SCREEN(6)::CALL CLEAR::CALL MAGNIFY(3)::DISPLAY AT(4,6):"WALK AND TALK DEMO"
110 DISPLAY AT(9,3):"SPRITE GRAPHICS BASED ON"::DISPLAY AT(11,7):"ZX SPECTRUM GAME"
120 DISPLAY AT(13,8):"""SIR LANCELOT"""::CALL SAY("#TEXAS INSTRUMENTS#")
200 CALL CHAR(36,"0000211311080B060C0606030100070360F038F8F8F0B8DC6CDCD89050D8ECEC")
210 CALL CHAR(40,"0008090B09080B060C0606030100070360F038F8F8F0B8DC6CDCD8B070DECEDC")
220 CALL CHAR(44,"0000010381601B060C0606030D0F070360F038F8F8F0B8DC6CDCD8BC47871E1C")
230 CALL CHAR(52,"060F1C1F1F0F1D3B363B1B090A1B3737000084C88810D060306060C08000E0C")
240 CALL CHAR(56,"060F1C1F1F0F1D3B363B1B0D0E7B733B001090D09010D060306060C08000E0C")
250 CALL CHAR(60,"060F1C1F1F0F1D3B363B1B3DE2E17838000080C08106D860306060C0B0F0E0C")
260 CALL SPRITE(#1,36,2,140,122)::DISPLAY AT(24,5):"USE JOYSTICK TO WALK"
300 ANIM=ABS(ANIM-4)::CALL JOYST(1,X,Y)::CALL MOTION(#1,0,X*2)
310 IF X<>0 THEN CALL PATTERN(#1,ANIM+X*2+48)::FACE=SGN(X+4)::GOTO 300
320 CALL PATTERN(#1,FACE*16+36)::GOTO 300

[orion1052003]

That is a great little demo. I was trying to understand 300,310, & 320. Could you give me a little line by line breakdown like they have in the Miller's Sprites book?

I also sent this demo to a friend and he had a few questions on it as well. "I also have problems with Karsten's program. He is an excellent programmer and no doubt his program works. In line 300 he starts using a variable named ANIM but I cannot see where this is given a value earlier in his program so the initial value must be 0. ANIM=ABS(ANIM-4) subtracts 4 from 0 to give us -4 and then ABS makes this +4. Why did he not just replace ANIM with 4? Also in line 310 FACE=SGN(X+4) captures the sign of X+4. Why add 4 to X when SGN can only return +1, -1 or 0. This is the same method that I was going to use to have my JUMP routine jump in the direction that the man was facing."

[orion1052003]

I started this topic to try and figure out how to use CALL JOYST with CALL LOCATE instead of the usual CALL MOTION. Made this program to try and figure it out. It shows when the stick and button is moved, but it doesn't move the black square with the joystick using CALL LOCATE.


20 !TEST PROGRAM-USE CALL LOCATE WITH JOYST
25 P1=15 :: P2=10
30 CALL CLEAR :: CALL SCREEN(6) :: CALL COLOR(9,2,2)
40 A$="FFFFFFFFFFFFFFFF" :: B$="FFFFFFFFFFFFFFFF"
42 C$="FFFFFFFFFFFFFFFF" :: D$="FFFFFFFFFFFFFFFF" :: E$="FFFFFFFFFFFFFFFF"
50 CALL CHAR(96,A$,104,B$,112,C$,120,D$,128,E$)
60 CALL SPRITE(#1,96,2,89,121,1,1)
70 CALL JOYST(1,X,Y)
75 CALL COLOR(10,P1,6,11,P1,6,12,P1,6,13,P1,6)
80 R=R-Y/4 :: C=C+X/4
90 DR=R*8-7 :: DC=C*8-7
100 DR=INT(R*8-7) :: DC=INT(C*8-7)
110 CALL POSITION(#1,DR,DC)
120 CALL LOCATE(#1,DR,DC)
130 CALL KEY(1,K,S)
140 DISPLAY AT(16,1):"SAME KEY=0 NEW KEY=1 NO KEY PRESS=-1"
145 DISPLAY AT(18,5):"KEY= ";K;"STATUS= ";S
150 DISPLAY AT(20,1):"X= ";X;"Y= ";Y
160 DISPLAY AT(21,1):"R= ";R;"C= ";C
170 DISPLAY AT(22,1):"DR= ";DR;"DC= ";DC
180 CALL HCHAR(1,16,104)!UP
190 CALL HCHAR(24,16,112)!DOWN
195 CALL HCHAR(12,3,120)!LEFT
198 CALL HCHAR(12,30,128)!RIGHT
200 IF Y=4 AND X=0 THEN CALL COLOR(10,P2,6)
210 IF Y=0 AND X=4 THEN CALL COLOR(13,P2,6)
220 IF Y=-4 AND X=0 THEN CALL COLOR(11,P2,6)
230 IF Y=0 AND X=-4 THEN CALL COLOR(12,P2,6)
250 GOTO 70

[sometimes99er]

orion1052003, on Thu Oct 6, 2011 7:39 PM, said:

That is a great little demo. I was trying to understand 300,310, & 320. Could you give me a little line by line breakdown like they have in the Miller's Sprites book? I also sent this demo to a friend and he had a few questions on it as well. "I also have problems with Karsten's program. He is an excellent programmer and no doubt his program works. In line 300 he starts using a variable named ANIM but I cannot see where this is given a value earlier in his program so the initial value must be 0. ANIM=ABS(ANIM-4) subtracts 4 from 0 to give us -4 and then ABS makes this +4. Why did he not just replace ANIM with 4? Also in line 310 FACE=SGN(X+4) captures the sign of X+4. Why add 4 to X when SGN can only return +1, -1 or 0. This is the same method that I was going to use to have my JUMP routine jump in the direction that the man was facing."

I'll try as best as I can.

First we have to understand the animation frames. The top are of course facing left (36, 40 and 44) and the bottom facing right (52, 56 and 60). The first frame is the standing still frame (36 and 52). The next 2 are the walking frames (40, 44, 56 and 60).

All you can do in the demo is walk right, left or stand still. So when I use CALL JOYST, I only need the X value. X will always return the value -4, 0 or 4.

The line
CALL JOYST(1,X,Y)::CALL MOTION(#1,0,X*2)
will take care of movement of the sprite. That's movement left, right or no movement. That should work on its own. The sprite will move left, right or stand still according to the joystick. Now we can concentrate on how to animate the sprite, that's changing the frames using CALL PATTERN.

Now if you stop walking, I want the character to face the direction that you were just walking. The constant update of the variable X using CALL JOYST, will loose the information. I know that the character has stopped walking, but which way is it facing. I introduce the variable FACE to help me remember. FACE should only have a value of left or right. Any variable not assigned is initially assign the value of 0. I choose to have 0 mean facing left and 1 mean right.

Now if X has the value 0, the joystick is centred, the character should not walk. In line 310 I simply avoid updating the variable FACE using IF X<> THEN ...

So if X has the value of -4 or 4, the rest of line 310 is executed. So you're pulling the joystick either left or right, and I want to update the variable FACE accordingly. I want to go from X=-4 to FACE=0, or go from X=4 to FACE=1. Of course I could do this using IF, but usually this will lead to IF THIS THEN DO THAT ELSE DO SOMETHING ELSE structures. Using bit manipulation or math and maybe careful planning and layout of characters, can often reduce the size of things, but also, things will become not so easy to just change. It is an optimization.

Again I want -4 to become 0 and 4 to be 1. If I add 4 to X I'll have -4 becoming 0, and 4 becoming 8. And now simply using the sign function, makes the 8 become 1. It's done. Now how did I come up with this. I guess it's years of training, solving and reducing equations, seeing patterns, and knowing which functions are available.

When walking I have 2 frames. It doesn't matter what they are, could be left foot first and right foot first, all we have to do is alternate between the 2. Is going to be a bit like marching, left, right, left, right or n our case I want 0, 1, 0, 1 ...

For this I want a variable named ANIM. As I said it is going to hold the value 0 or 1. And whenever I loop (GOTO 300), I want the value to change. 0 has to become 1, and 1 has to become 0. This could be done like this ANIM=ABS(ANIM-1). Now the spacing between the frame are 4. That's 40 and 44, or 56 and 60. So instead of later having to have ANIM*4, I have ANIM hold the value of 0 or 4 instead by simply subtracting 4 instead of 1, this ANIM=ABS(ANIM-4) will make it flick between 0 and 4.

To work with, correct or see these effects of variable manipulation, and also see consequences of variables not initialized, one can often make small program like this

300 ANIM=ABS(ANIM-4)
310 PRINT ANIM
320 GOTO 300

[orion1052003]

Thanks for that last post. I changed the CALL LOCATE program a bit, but still can't get the JOYST control part. *BAD VALUE IN 120. DR,DC starting out at zero could be why, but then when I gave them values outside the loop, the black dot to be controlled by the joystick is stuck at that set of coordinates.


20 !TEST PROGRAM-USE CALL LOCATE WITH JOYST
25 P1=15 :: P2=10
30 CALL CLEAR :: CALL SCREEN(6) :: CALL COLOR(9,2,2)
40 A$="FFFFFFFFFFFFFFFF" :: B$="FFFFFFFFFFFFFFFF"
42 C$="FFFFFFFFFFFFFFFF" :: D$="FFFFFFFFFFFFFFFF" :: E$="FFFFFFFFFFFFFFFF"
50 CALL CHAR(96,A$,104,B$,112,C$,120,D$,128,E$)
60 CALL SPRITE(#1,96,2,89,121,1,1)
70 CALL JOYST(1,X,Y)
75 CALL COLOR(10,P1,6,11,P1,6,12,P1,6,13,P1,6)
80 !=R-Y/4 :: C=C+X/4
90 DR=DR-Y/4 :: DC=DC+X/4
100 !R=INT(R*8-7):: DC=INT(C*8-7)
110 !ALL POSITION(#1,DR,DC)
120 CALL LOCATE(#1,DR,DC)
130 CALL KEY(1,K,S)
140 DISPLAY AT(16,1):"SAME KEY=0 NEW KEY=1 NO KEY PRESS=-1"
145 DISPLAY AT(18,5):"KEY= ";K;"STATUS= ";S
150 DISPLAY AT(20,1):"X= ";X;"Y= ";Y
160 DISPLAY AT(21,1):"R= ";R;"C= ";C
170 DISPLAY AT(22,1):"DR= ";DR;"DC= ";DC
180 CALL HCHAR(1,16,104)!UP
190 CALL HCHAR(24,16,112)!DOWN
195 CALL HCHAR(12,3,120)!LEFT
198 CALL HCHAR(12,30,128)!RIGHT
200 IF Y=4 AND X=0 THEN CALL COLOR(10,P2,6)
210 IF Y=0 AND X=4 THEN CALL COLOR(13,P2,6)
220 IF Y=-4 AND X=0 THEN CALL COLOR(11,P2,6)
230 IF Y=0 AND X=-4 THEN CALL COLOR(12,P2,6)
250 GOTO 70

Attached Files

•  DR,DR=1.jpg   32.98K   1 downloads

Edited by orion1052003, Sat Oct 8, 2011 2:33 PM.

[sometimes99er]

Try changing line 60 to
60 CALL SPRITE(#1,96,2,89,121)
and add
65 DR=100::DC=100

[sometimes99er]

This should be fine too
40 A$="FFFFFFFFFFFFFFFF"
50 CALL CHAR(96,A$,104,A$,112,A$,120,A$,128,A$)
The value of the string (A$) is copied to the character definition area. Previous definitions are overwritten. After the CALL CHAR, you can use A$ for whatever.

Actually you don't have to define the characters if all pixel are on or off, if you're not using any of the other characters in a set. You can simply set all pixel to the same color by using the same foreground and background color. Like this CALL COLOR(10,P2,P2)

[RXB]

Save some bytes:
40 A$=RPT$("F",16)

Or use
40 CALL CHAR(96,RPT$("F",512)) ! 96 to 128 all "F"

This would accomplish the same thing faster and smaller.

Edited by RXB, Sat Oct 8, 2011 4:39 PM.

[orion1052003]

Added DR,DC=100 and and took the row and column velocity off the CALL SPRITE. Didn't simply the call chars part yet. Now the question is, why does it work? It moves slowly but works now. Thanks.

10 DR,DC=1
20 !TEST PROGRAM-USE CALL LOCATE WITH JOYST
25 P1=15 :: P2=10
30 CALL CLEAR :: CALL SCREEN(6) :: CALL COLOR(9,2,2)
40 A$="FFFFFFFFFFFFFFFF" :: B$="FFFFFFFFFFFFFFFF"
42 C$="FFFFFFFFFFFFFFFF" :: D$="FFFFFFFFFFFFFFFF" :: E$="FFFFFFFFFFFFFFFF"
50 CALL CHAR(96,A$,104,B$,112,C$,120,D$,128,E$)
60 CALL SPRITE(#1,96,2,89,121)
65 DR=100 :: DC=100
70 CALL JOYST(1,X,Y)
75 CALL COLOR(10,P1,6,11,P1,6,12,P1,6,13,P1,6)
80 !=R-Y/4 :: C=C+X/4
90 DR=DR-Y*4 :: DC=DC+X*4
100 !R=INT(R*8-7):: DC=INT(C*8-7)
110 !ALL POSITION(#1,DR,DC)
120 CALL LOCATE(#1,DR,DC)
130 CALL KEY(1,K,S)
140 DISPLAY AT(16,1):"SAME KEY=0 NEW KEY=1 NO KEY PRESS=-1"
145 DISPLAY AT(18,5):"KEY= ";K;"STATUS= ";S
150 DISPLAY AT(20,1):"X= ";X;"Y= ";Y
160 DISPLAY AT(21,1):"R= ";R;"C= ";C
170 DISPLAY AT(22,1):"DR= ";DR;"DC= ";DC
180 CALL HCHAR(1,16,104)!UP
190 CALL HCHAR(24,16,112)!DOWN
195 CALL HCHAR(12,3,120)!LEFT
198 CALL HCHAR(12,30,128)!RIGHT
200 IF Y=4 AND X=0 THEN CALL COLOR(10,P2,6)
210 IF Y=0 AND X=4 THEN CALL COLOR(13,P2,6)
220 IF Y=-4 AND X=0 THEN CALL COLOR(11,P2,6)
230 IF Y=0 AND X=-4 THEN CALL COLOR(12,P2,6)
250 GOTO 70

[sometimes99er]

orion1052003, on Sat Oct 8, 2011 4:45 PM, said:

Now the question is, why does it work?

120 CALL LOCATE(#1,DR,DC)
The line didn't like the original initial values of DR and DC, which were both 0. Tests show that the x and y parameters of LOCATE must both be in the range of 1-256.

orion1052003, on Sat Oct 8, 2011 4:45 PM, said:

It moves slowly but works now.

You have a lot going on in the loop (lines 70-250). It takes time to do it all before again reaching JOYST and LOCATE. Lines 180-198 could be moved to the start (outside the loop). Lines 180-198 is always doing the same, and nothing here (as far as I can see) overwrites these characters put to the screen.

[orion1052003]

Changed the program a bit according to the suggestions. Seems pretty effective now. Perhaps the movement is still a bit slow. I doubt LOCATE could be as smooth as CALL MOTION.


100 !TEST PROGRAM-USE CALL LOCATE WITH JOYST
110 P1=15 :: P2=10
120 CALL CLEAR :: CALL SCREEN(6)
130 A$=RPT$("F",16) :: CALL CHAR(96,A$)
140 CALL SPRITE(#1,96,2,89,121)
150 DR=100 :: DC=100
160 CALL HCHAR(1,16,104)!UP
170 CALL HCHAR(24,16,112)!DOWN
180 CALL HCHAR(12,3,120)!LEFT
190 CALL HCHAR(12,30,128)!RIGHT
200 CALL JOYST(1,X,Y)
210 CALL COLOR(10,P1,P1,11,P1,P1,12,P1,P1,13,P1,P1)
220 R=R-Y/4 :: C=C+X/4
230 DR=DR-Y*4 :: DC=DC+X*4
260 CALL LOCATE(#1,DR,DC)
270 CALL KEY(1,K,S)
280 DISPLAY AT(16,1):"SAME KEY=0 NEW KEY=1 NO KEY PRESS=-1"
290 DISPLAY AT(18,5):"KEY= ";K;"STATUS= ";S
300 DISPLAY AT(20,1):"X= ";X;"Y= ";Y
310 DISPLAY AT(21,1):"R= ";R;"C= ";C
320 DISPLAY AT(22,1):"DR= ";DR;"DC= ";DC
330 IF Y=4 AND X=0 THEN CALL COLOR(10,P2,P2)
340 IF Y=0 AND X=4 THEN CALL COLOR(13,P2,P2)
350 IF Y=-4 AND X=0 THEN CALL COLOR(11,P2,P2)
360 IF Y=0 AND X=-4 THEN CALL COLOR(12,P2,P2)
370 GOTO 200

[sometimes99er]

Yes, CALL MOTION can appear more smooth.

Also using CALL LOCATE without screen boundary checking will have your program crash (as is), when you move off screen horizontally or move too much vertically (getting outside the value range of 1-256). This will not happen when using CALL MOTION, which simply let's the sprite reappear "on the other side".

It all depends on what you're doing (overall objective and where you're at (code as is)) and what you're trying to do (the local trade off effect). Moving a sprite around in a maze might use both CALL MOTION and CALL LOCATE. MOTION to have a constant "flow", and LOCATE to put the sprite back into the maze, even though it's only off with a few pixels.

Edited by sometimes99er, Mon Oct 10, 2011 12:24 AM.

[orion1052003]

Thanks! neat stuff. Tried it out in my own program, seems like it works, too. Now, gotta set some screen edges to wrap horizontally and stop vertically, and make the man jump. Trying to make the man jump something like Major Havoc.


200 L$="00233123213F0303033F20202020E0000080808080F888889888808080FC0404"
210 L2$="0003010B09090F010101011F10101070008080808080F8888880808080FC0404"
220 R$="000303037F43434303030202023E303000880888F880808080F8080808080E0E"
230 R2$="00030303070F172747070707FCFCC0C0008000808080FC000000E0E060607878"
280 C$="000302030F0B1B03030302020202060600808080E0A0B080808080808080C0C0"
290 C2$="000302030F0B1B03030302020202060600808080E0A0B080808080808080C0C0"
420 CALL CHAR(96,C$,100,L$,104,L2$)
440 CALL CHAR(112,C2$,116,R$,120,R2$)


635 DR=130 :: DC=1
640 CALL SPRITE(#1,96,16,DR,DC) :: CALL MAGNIFY(4)
660 ANIM=ABS(ANIM-4)::CALL JOYST(1,X,Y)::DR=DR-Y*4 :: DC=DC+X*4::CALL LOCATE(#1,DR,DC)
663 IF X<>0 THEN CALL PATTERN(#1,ANIM+X*2+108)::FACE=SGN(X+4)::GOTO 660
665 CALL PATTERN(#1,FACE*16+96)::GOTO 660

[sometimes99er]

Hehe, the guy is cute and moves fast. Like it.

[sometimes99er]

Try to change
CALL LOCATE(#1,DR,DC)
to
CALL LOCATE(#1,(DR AND 255)+1,(DC AND 255)+1)
Now run and try to move off screen.

In Basic you often do not think of AND as a bit operator, but it is. "AND 255" limits the value into the range 0-255. Beware, you can't simply change to "AND 254" and expect to limit a value into the range 0-254. You have to get into the bit manipulation of things to understand what's happening. Simple range limitations though are:
AND 1 gives 0-1
AND 3 gives 0-3
AND 7 gives 0-7
AND 15 ...
AND 31
AND 63
AND 127
AND 255
AND 511
...

[RXB]

Just wondering if this solves your problem?

100 !TEST PROGRAM-USE CALL LOCATE WITH JOYST
110 P1=15 :: P2=10
120 CALL CLEAR :: CALL SCREEN(6)
130 A$=RPT$("F",16):: CALL CHAR(96,A$)
140 CALL SPRITE(#1,96,2,89,121)
150 DR=100 :: DC=100
160 CALL HCHAR(1,16,104)!UP
170 CALL HCHAR(24,16,112)!DOWN
180 CALL HCHAR(12,3,120)!LEFT
190 CALL HCHAR(12,30,128)!RIGHT
200 CALL JOYST(1,X,Y):: CALL MOTION(#1,-Y*4,X*4)
210 CALL COLOR(10,P1,P1,11,P1,P1,12,P1,P1,13,P1,P1)
220 R=R-Y/4 :: C=C+X/4
230 ! DR=DR-Y*4 :: DC=DC+X*4
240 CALL POSITION(#1,DR,DC)
260 ! CALL LOCATE(#1,DR,DC)
270 CALL KEY(1,K,S)
280 DISPLAY AT(16,1):"SAME KEY=0 NEW KEY=1 NO KEY PRESS=-1"
290 DISPLAY AT(18,5):"KEY= ";K;"STATUS= ";S
300 DISPLAY AT(20,1):"X= ";X;"Y= ";Y
310 DISPLAY AT(21,1):"R= ";R;"C= ";C
320 DISPLAY AT(22,1):"DR= ";DR;"DC= ";DC
330 IF Y=4 AND X=0 THEN CALL COLOR(10,P2,P2)
340 IF Y=0 AND X=4 THEN CALL COLOR(13,P2,P2)
350 IF Y=-4 AND X=0 THEN CALL COLOR(11,P2,P2)
360 IF Y=0 AND X=-4 THEN CALL COLOR(12,P2,P2)
370 GOTO 200

Also if you add the following line you get a intresting response:
200 CALL MOTION(#1,0,0)

Edited by RXB, Mon Oct 10, 2011 2:54 AM.

[orion1052003]

It works great. The man wraps around on screen. Why does it work?



640 CALL SPRITE(#1,96,16,DR,DC) :: CALL MAGNIFY(4)
660 ANIM=ABS(ANIM-4) :: CALL JOYST(1,X,Y) :: DR=DR-Y*0 :: DC=DC+X*4 :: CALL LOCATE(#1,(DR AND 255)+1,(DC AND 255)+1)

What does the +1 do?

663 IF X<>0 THEN CALL PATTERN(#1,ANIM+X*2+108) :: FACE=SGN(X+4) :: GOTO 660
665 CALL PATTERN(#1,FACE*16+96) :: GOTO 660
670 IF DC<2 THEN DC=240 ELSE IF DC>240 THEN DC=2!THIS LINE DIDN'T WORK

I am somewhat familiar with AND since I read The Power of AND by Craig Miller from "Night Mission". I think whatever you AND something with, the answer can't be higher than whatever number you ANDed with. The bit "mask" in assembly. I don't fully understand it, but I ANDed some numbers at work just to get familiar with it. I think 9 is 1001. 1 is 0001. 9 AND 1 would be 0001=1 then I think. Can you actually do AND 1, AND 7, etc. or was it some number AND 1, DC, DR, or some number AND 7, etc. that you meant above?

[orion1052003]

JOYPROG

200 CALL MOTION(#1,0,0) Makes it a joystick tester without moving the dot.

200 CALL JOYST(1,X,Y):: CALL MOTION(#1,-Y*4,X*4)


240 CALL POSITION(#1,DR,DC)

These 200, 240 also work good. What does the CALL POSITION do in this case? The square is in motion in 200, Line 240 checks its position, then what does it do with that position?

[orion1052003]

Do you have any idea why my jump won't work?


730 CALL KEY(1,K,S)
740 IF K=18 THEN CALL JUMP(DR,DC)ELSE 660
743 IF COUNT=25 THEN CALL ALIEN
745 IF COUNT=100 THEN CALL BLASTOFF
750 IF K<>18 THEN 660!CALL JOYST
760 GOTO 660!CALL JOYST
770 !ENDOFMAINLOOP



810 SUB JUMP(DR,DC)
815 !ALL COINC(#1,ALL,C)
820 CALL SOUND(150,-2,4)
830 DR=DR-Y*4
840 SDR=DR :: A=1
850 CALL KEY(1,K,S) :: IF K=18 THEN DR=DR-4 :: DC=DC+(A*PI/45)*5 :: IF DC>240 THEN DC=1
860 !DISPLAY AT(23,1):A;" ";SIN(A*PI/45)
870 IF DR<8 THEN 890
880 CALL LOCATE(#1,DR,DC) :: IF S<0 THEN A=A+1 :: GOTO 850
890 IF DR<SDR THEN DR=DR+4 :: DC=DC+1 :: CALL LOCATE(#1,DR,DC) :: IF DC>240 THEN DC=1
900 IF DR<SDR THEN 890