Funny Sprite Movement

[MisterMister]

I am having difficulty with this piece of code (See Below)

It seems that if my character continually runs left (JLEFT) and then jumps(FIRE) the sprite shown is the character jumping right. however, it is not the case when the character is running right. If the character runs right (JRIGHT) and you jump (FIRE) then the sprite shown is of the character jumping right. Its strange because I can't seem to see what is wrong here. I'm quite new to stos and this is my first venture into sprite movement/manipulation. Any help on this would be appreciated. Thanks in advance...

This is a list of the following sprite numbers

| FACING RIGHT | FACING LEFT |

STATIONARY 1 7

RUNNING 2,3,4 8,9,10

TURNING 6 12

JUMPING 5 11

this is the code I'm currently using. Once again, Thanks for taking the time!

MisterMister

=========================================================================================

5 load "character.mbk"
10 cls : key off : curs off : hide : mode 0
20 D=palt(start(1)) : wait vbl
30 rem ****************************
40 rem ***** PLAYER VARIABLES *****
50 rem ****************************
60 PX=110 : PY=168 : PS=1 PX=left/right PY=up/down PS=spriter number
70 rem ****************************
80 rem ***** SET PLAYER ON SCREEN *****
90 rem ********************************
98 wait vbl
99 sprite 1,PX,PY,PS
100 if PS>6 then PS=7
101 if PS<6 then PS=1
110 rem ***********************************
120 rem ***** TEST JOYSTICK MOVEMENT *****
130 rem **********************************
140 if jleft then gosub 300
150 if jright then gosub 400
160 if fire then gosub 500
170 wait vbl
180 goto 98
297 rem ***************************
298 rem ***** PLAYER MOVES RIGHT *****
299 rem ******************************
300 if PS=1 then PS=7
310 repeat : wait vbl : inc PS : sprite 1,PX,PY,PS : until PS=10
320 return
397 rem ***************************
398 rem ***** PLAYER MOVES LEFT *****
399 rem ******************************
400 if PS=7 then PS=1
410 repeat : wait vbl : inc PS : sprite 1,PX,PY,PS : until PS=4
420 return
497 rem ***************************
498 rem ***** PLAYER MOVES UP *****
499 rem ******************************
500 if PS=7 then 550
510 PS=5
520 repeat : wait vbl : PY=PY-4 : sprite 1,PX,PY,PS : until PY=104
530 repeat : wait vbl : PY=PY+4 : sprite 1,PX,PY,PS : until PY=168
540 return
550 PS=11
560 repeat : wait vbl : PY=PY-4 : sprite 1,PX,PY,PS : until PY=104
570 repeat : wait vbl : PY=PY+4 : sprite 1,PX,PY,PS : until PY=168
580 return

====================================================================================================

[PaulB]

It's been years since I coded in Stos but maybe line 500 should look like this:

500 if PS=7 then goto 550

Also, even though stos allows it, it's bad programming practice to jump out of a subroutine. The left and right jumping could be contained in the same subroutine using a simple if/else statement.

[leehanken]

Nothing to do with the stated problem, but...

On Line 101 I think it should say

Code: Select all

IF PS <= 6 ...

Also for the sprite to be seen turning, would need

Code: Select all

300 ...:wait vbl:sprite 1,PX,PY,6

Code: Select all

400 ...:wait vbl:sprite 1,PX,PY,12

And for there to be any movement left or right would need

Code: Select all

310 ...:PX=PX+1:...

Code: Select all

410 ...:PX=PX-1:...

[MisterMister]

I know my bad programming works. STOS allows "if bla bla then 200" it allows you to miss goto's funily enough?! Its horrendous isn't it?

I'm not a complete newbie but not done anything that would be considered as a complete program in years (VRY rusty!!).

Its just bizarre but i think it has something to do with the JRIGHT JLEFT GOTO statements and the flow of the program in the initial test of the joystick movements.

its actually part of a tiled program and the character doesnt do any PX=PX+1 moving or indeed any INC'ing . Its not included because thats a seperate .BAS file that will be merged and edited later.

[MisterMister]

thanks guys, it was something (although not sure) to do with the GOSUB routines.

I Re-Wrote it without gosubs and used simpler GOTO's and it seems to work as it should now, if you hadn't have mentioned the subroutine jumping i don't think i would have tried re-writing it !!

Thanks again guys, my own mistake but sometimes you need different people to point it out lol!

MisterMister

[Desty]

Gotos have their place, but if you have better constructs available (like higher-level loops/macros and subroutines or better yet, functions ) it usually results in clearer, less buggy code if you use them instead.

It's especially dirty to combine higher-level control constructs with goto - I'm not sure exactly how STOS does it, but the general idea with interpreters and compilers is that jumping to a subroutine creates an activation record or stack frame. In STOS's case, maybe just the return address goes onto the (or some special-purpose) stack.

e.g. in pseudo STOS-code:

Code: Select all

10 gosub outer
20 end

30 proc outer:
40  gosub inner
50 return

60 proc inner:
70  print "Hi!"
80 return

When we get to line 30, the call stack will contain (at least) the return address (or just the line number 20 for kicks).
Then we get to 40 which calls inner at 60... at this point, the call stack is (20, 50). When we get to line 80, the return pops the most recent address from the call stack and jumps to line 50, where the outer call returns to line 20 by popping that off the stack.
So it should be apparent why goto-ing out of a procedure like this can screw things up, by modifying the control flow without the new information being updated in the call stack. For example, if you jump into a subroutine and it tries to return, what happens? Well, the result is undefined and it's hard to see a 'correct' thing to do in that situation other than crash.
Some more powerful languages like Scheme and Haskell allow you to do weird things with control flow (continuations) but in a carefully designed way that isn't going to screw up the call stack.

It's good that you solved the problem, but I'd suggest you go the other way next time and try to use subroutines where possible instead of goto. For loops, sure, goto might make sense, but in general subroutines help to reduce complexity of what you're doing by wrapping up some specific task in a special-purpose box.

[STOSGargoyle]

Hi there, I found that using INC PS is very useful for animating a sprite while moving it with the joystick, but the animation is quite fast, does anyone if there is a way of reducing the animation speed?

If possible MisterMister, I would really appreciate it if you could please paste up the code you have rewritten?

[simonsunnyboy]

Independant of the language, just increment a counter first and only update the actual animation frame after x steps of the counter.

Code: Select all

INC framecounter
IF (framecounter AND 2)
  ' each 4 frames animate
  INC animation_frame
ENDIF

[MiggyMog]

but the animation is quite fast, does anyone if there is a way of reducing the animation speed?

If you are using STOS's built in routines you can use the ANIM comand to cycle through frames.


anim [sprite number],"[frame_no],[Delay_In_VBLS]"

So to slow down frame changing just change the delay to a higher number for each frame.Page 87 of the STOS manual has the details.

anim 1,"(1,200)(2,200)(3,200)L"