Velocity to Animated Sprites?

[Sinphaltimus]

Is there a way to create an animated sprite and then put it in to motion with the call sprite command?
So that it moves (column and/or row velocity) and still be animated?

The only way I could think of doing this is shown below and I have to use a stationary sprite to accomplish this illusion by changing its column position instead of using the column velocity.

100 CALL CLEAR
200 DATA 1818101010101018,1818183C1C142630,181A3C5E1A334060,18197E981C724100,18197E9818147243,1818385E581C2436
300 R=12 :: C=1
400 CHR=39
500 FOR DIST=1 TO 200 :: CHR=CHR+1
600 IF CHR<=44 THEN 800 ELSE 700
700 CHR=40 :: RESTORE 200
800 C=C+1 :: IF C>=250 THEN 300
900 READ PAT$
1000 CALL CHAR(CHR,PAT$)
1100 CALL SPRITE(#1,CHR,2,R,C)
1200 NEXT DIST
1300 RESTORE 200
1400 GOTO 300

[+arcadeshopper]

you are looking for call motion

 

great reference here: http://mainbyte.com/ti99/basic/basic2.asp

[+mizapf]

You can add the velocities as two more arguments to the SPRITE subprogram.

 

Why are you recreating the sprite? There are specific subprograms like PATTERN, MOTION, or LOCATE.

[Airshack]

Look specifically at lines 230 and beyond:

 

 

Name:

PATTERN subprogram

Format:

CALL PATTERN(#sprite-number, character-value [,...] )

Description:

The PATTERN subprogram allows you to change the character pattern of sprite without affecting any other characteristics of the sprite.

 

Sprite-number specifies the sprite you are using. Character-value may be any integer from 32 to 143. See the CHAR subprogram for information on defining the pattern for characters. See the MAGNIFY subprogram for more information.

Options:

 

Examples:

The program below illustrates the use of the PATTERN subprogram.

 

>100 CALL CLEAR

 

Lines 110 through 140 build a floor.

 

>110 CALL COLOR(12,16,16)

>120 FOR A=19 TO 24

>130 CALL HCHAR(A,1,120,32)

>140 NEXT A

 

Lines 150 though 200 define characters 96 through 107.

 

>150 A$="01071821214141FFFF4141212119070080E0988484 8282FFFF8282848498E000"

>160 B$="01061820305C4681814246242C1807008060183424 62428181623A0C0418E000"

>170 C$="0106182C2446428181465C3020180700806018040C 3A6281814262243418E000"

>180 CALL CHAR(96,A$)

>190 CALL CHAR(100,B$)

>200 CALL CHAR(104,C$)

 

Line 210 creates a sprite in the shape of a wheel and starts it moving to the right.

 

>210 CALL SPRITE(#1,96,5,130,1,0,

 

Line 220 makes the sprite double size. >220 CALL MAGNIFY(3)

 

Lines 230 through 270 make the spokes of the wheel appear to move as the character displayed is changed.

 

>230 FOR A=96 TO 104 STEP 4

>240 CALL PATTERN(#1,A)

>250 FOR DELAY=1 TO 5:: NEXT DELAY

>260 NEXT A

>270 GOTO 230

 

(Press SHIFT C to stop the program.)

Edited August 2, 2016 by Airshack

[Airshack]

For a multi-colored animation:

 

A. Hide another Sprite (of another color and/or pattern, using CALL LOCATE) off the bottom of the screen by positioning it on to the last row of pixels.

 

B. Use CALL POSITION to find where your Sprite needing animation is located.

 

C. Momentarily reposition the hidden Sprite to that location using CALL LOCATE.

 

D. Move that Sprite back to the hidden row using CALL LOCATE.

 

This technique is found in the Miller's Graphics book, SMART PROGRAMMING GUIDE FOR SPRITES.

[Opry99er]

Oh, so much fun about to have you are....

 

Learn the ways of the Jedi....

[Sinphaltimus]

Ok. I'm going to play with this a lot. The issue I have with the additional velocity setting is being able to cycle through patterns without having to call the sprite again. Like having the call sprite outside of the for next loop. But then it wouldnt animate. When I used the additional arguments to set the sprite in motion within the for next, I would be resetting the start position. So the only easy I could think to do it was the way I've shown.

 

This is strictly for me to contribute to the ti graphics thread. Looking for the most efficient method without trying to reinvent the wheel.

 

Call motion. I barely recall that. I should probably read the extended basic manual cover to cover.

 

Thanks for the advice. I'll be sure to follow up later with more animation shenanigans.

Edited August 3, 2016 by Sinphaltimus

[Sinphaltimus]

You can add the velocities as two more arguments to the SPRITE subprogram.

 

Why are you recreating the sprite? There are specific subprograms like PATTERN, MOTION, or LOCATE.

I guess I don't understand the other subprograms and what they do. I can add the velocity arguments but how do I cycle through the patterns at the same time?

[Sinphaltimus]

Look specifically at lines 230 and beyond:

 

 

Name:

PATTERN subprogram

Format:

CALL PATTERN(#sprite-number, character-value [,...] )

Description:

The PATTERN subprogram allows you to change the character pattern of sprite without affecting any other characteristics of the sprite.

 

Sprite-number specifies the sprite you are using. Character-value may be any integer from 32 to 143. See the CHAR subprogram for information on defining the pattern for characters. See the MAGNIFY subprogram for more information.

Options:

 

Examples:

The program below illustrates the use of the PATTERN subprogram.

 

>100 CALL CLEAR

 

Lines 110 through 140 build a floor.

 

>110 CALL COLOR(12,16,16)

>120 FOR A=19 TO 24

>130 CALL HCHAR(A,1,120,32)

>140 NEXT A

 

Lines 150 though 200 define characters 96 through 107.

 

>150 A$="01071821214141FFFF4141212119070080E0988484 8282FFFF8282848498E000"

>160 B$="01061820305C4681814246242C1807008060183424 62428181623A0C0418E000"

>170 C$="0106182C2446428181465C3020180700806018040C 3A6281814262243418E000"

>180 CALL CHAR(96,A$)

>190 CALL CHAR(100,B$)

>200 CALL CHAR(104,C$)

 

Line 210 creates a sprite in the shape of a wheel and starts it moving to the right.

 

>210 CALL SPRITE(#1,96,5,130,1,0,

 

Line 220 makes the sprite double size. >220 CALL MAGNIFY(3)

 

Lines 230 through 270 make the spokes of the wheel appear to move as the character displayed is changed.

 

>230 FOR A=96 TO 104 STEP 4

>240 CALL PATTERN(#1,A)

>250 FOR DELAY=1 TO 5:: NEXT DELAY

>260 NEXT A

>270 GOTO 230

 

(Press SHIFT C to stop the program.)

 

OK, this looks exactly like what I'm looking for. Yeah. I think I may just rtfm on XB from cover to cover so I at least get the different commands in to my brain for later recall. Thanks, I'm going to try this right now!

[Sinphaltimus]

For a multi-colored animation:

 

A. Hide another Sprite (of another color and/or pattern, using CALL LOCATE) off the bottom of the screen by positioning it on to the last row of pixels.

 

B. Use CALL POSITION to find where your Sprite needing animation is located.

 

C. Momentarily reposition the hidden Sprite to that location using CALL LOCATE.

 

D. Move that Sprite back to the hidden row using CALL LOCATE.

 

This technique is found in the Miller's Graphics book, SMART PROGRAMMING GUIDE FOR SPRITES.

 

I'm not even close to multi-color yet. I'm just trying to get a grip on 8x8 animating stick figures for the moment. But there's color in my future for sure.

[Sinphaltimus]

 

 
 
100 CALL CLEAR
200 DATA 1818101010101018,1818183C1C142630,181A3C5E1A334060,18197E981C724100,18197E9818147243,1818385E581C2436
300 for chr=40 to 45
425 READ PAT$
450 CALL CHAR(CHR,PAT$)
475 next chr
500 CALL SPRITE(#1,CHR,2,12,15,0,6)
600 for pt=40 to 45
700 call pattern(#1,pt)
750 for delay=1 to 10
760 next delay
800 Next pt
900 goto 600
 

[+mizapf]

One caveat for sprite automotion (which basically everyone sooner or later had to learn): If you put a sprite in motion, you have no guarantees that it reaches a certain position on the screen.

 

A bit less abstract: Suppose you animate a laser shot going from left to right that is supposed to vanish when hitting a 4 pixel wide wall. Sprites are moved at every video interrupt, which means you have 60 relocations of the sprite per second (NTSC) or 50 (PAL). Since the screen is 256 columns wide, the fastest shot that is moved column by column needs 4.267 seconds. If the sprite is faster (e.g. 0.53 seconds for the whole width), it leaps forward 8 columns (!) on each video interrupt.

 

Also, if you compose an object of multiple sprites, you must make sure that position updates to all composing sprites happen with the same video interrupt.

[Airshack]

I believe this page in the XB manual is where you need to concentrate. This leads to the calls: PATTERN, DISTANCE, POSITION, and LOCATE.

Edited August 3, 2016 by Airshack

[Omega-TI]

I believe this page in the XB manual is where you need to concentrate. This leads to the calls: PATTERN, DISTANCE, POSITION, and LOCATE.

 

If any other returning TI'ers or newbie lurkers are following along, you might want to download the REFERENCE CARD and the linked PDF version of the TI Extended BASIC manual attached to this post.

TI Extended Basic - Linked.pdf

TI-Extended BASIC Reference Card.pdf

[Sinphaltimus]

One caveat for sprite automotion (which basically everyone sooner or later had to learn): If you put a sprite

<<Snip>>

 

Also, if you compose an object of multiple sprites, you must make sure that position updates to all composing sprites happen with the same video interrupt.

 

I've run in to that issue with various 2d game engines where the collision detection gets missed on fast moving objects. I've also ran in to that here in this very program where I was waiting for the column position to equal 100 then initiate the jump. It would miss every so often so I put in a small range.

 

About the video timing... Do I have any control over that in xb? That sounds more like an al process.

Edited August 3, 2016 by Sinphaltimus

[Opry99er]

One nice thing is if you are moving the SPRITE left to right and you want to modify it upon hitting pixel column 100, you can always check for >100 (instead of =100). That way, even if it misses the check for 100, it likely won't go far past that.

[Sinphaltimus]

One nice thing is if you are moving the SPRITE left to right and you want to modify it upon hitting pixel column 100, you can always check for >100 (instead of =100). That way, even if it misses the check for 100, it likely won't go far past that.

That's pretty much what I did. Been updating the code here:

 

http://atariage.com/forums/topic/254360-graphics-on-your-ti-are-you-interested/

[+adamantyr]

 

I've run in to that issue with various 2d game engines where the collision detection gets missed on fast moving objects. I've also ran in to that here in this very program where I was waiting for the column position to equal 100 then initiate the jump. It would miss every so often so I put in a small range.

 

About the video timing... Do I have any control over that in xb? That sounds more like an al process.

 

In Extended BASIC you don't have any control of the video interrupt. My experience with automated motion is that it's best use is when you just want to get something moving and then forget about it. It lends itself very well to Frogger style games where you just want a lot of moving objects.

 

I tested out using MOTION with my photon torpedoes in Space Trek, but Extended BASIC simply wasn't fast enough to be able to GCHAR position reliably while the sprite was moving, unless it was moving extremely slow.

 

One technique I didn't try but may have worked better would be:

 

1) Using GCHAR, plot the end-point of the torpedo silently prior to launch

2) Place an invisible sprite at the end-point

3) Create the torpedo and set it in motion towards the end-point

4) Do a CALL CONIC(ALL,N):: IF N THEN jump ELSE loop, so that when the photon torpedo sprite meets the other sprite it stops

 

I didn't try this though because the pre-plotting would still take a second or two of time to do, more if it has to go the whole length of the screen, and that would detract from gameplay. ("I just fired a torpedo, why is it just sitting there?!")

Edited August 3, 2016 by adamantyr

[RXB]

 

In Extended BASIC you don't have any control of the video interrupt. My experience with automated motion is that it's best use is when you just want to get something moving and then forget about it. It lends itself very well to Frogger style games where you just want a lot of moving objects.

 

I tested out using MOTION with my photon torpedoes in Space Trek, but Extended BASIC simply wasn't fast enough to be able to GCHAR position reliably while the sprite was moving, unless it was moving extremely slow.

 

One technique I didn't try but may have worked better would be:

 

1) Using GCHAR, plot the end-point of the torpedo silently prior to launch

2) Place an invisible sprite at the end-point

3) Create the torpedo and set it in motion towards the end-point

4) Do a CALL CONIC(ALL,N):: IF N THEN jump ELSE loop, so that when the photon torpedo sprite meets the other sprite it stops

 

I didn't try this though because the pre-plotting would still take a second or two of time to do, more if it has to go the whole length of the screen, and that would detract from gameplay. ("I just fired a torpedo, why is it just sitting there?!")

Why not use CALL DISTANCE?

 

1 CALL DISTANCE(#sprite,dot-row,dot-col,variable)

2 IF variable<6 THEN ??? ELSE ???

 

I was curious as to why you guys did not even think of this routine?

Edited August 4, 2016 by RXB

[+Lee Stewart]

Why not use CALL DISTANCE?

 

1 CALL DISTANCE(#sprite,dot-row,dot-col,variable)

2 IF variable<6 THEN ??? ELSE ???

 

I was curious as to why you guys did not even think of this routine?

 

Just remember that variable in the argument/parameter list returns the square of the distance, not the actual distance. This also means that the value can never be negative, so you cannot tell from this function if the sprite has passed the spot, only how close it is.

 

Obviously, execution times should be compared to see which functions are fastest.

 

...lee

[Sinphaltimus]

I imagine doing the pre-calculation method at the moent of fireing and then use a glowing red tip on the photon torpedo tube as if it's warming up while the precalcs take place. A way to "hide" the thinking process.

[+adamantyr]

I actually just implemented it and it looks pretty good! I may update the game to have this now... I still need to do a little testing.