Speed of CALL MOTION?

[nanochess]

Hi.

 

What values I need for moving one pixel to right each frame? (I'm thinking in 60hz, also is it right?)

 

Thanks!

[digdugnate]

I'm a little rusty on my Extended Basic, but I'm thinking maybe the value is 1? Assuming the sprite is #1....

 

call motion(#1, 0, 1) - it's row-velocity and column-velocity for the respective values, so I think that 0 would cause it to *not* move vertically but 1 would be like 1 to the right. the ranges are -127 to 127.

 

Hope this helps (and I'm remembering right!)

[mizapf]

Yes. You can easily prove it - start the sprite with a motion of one (column), take the time until the sprite is back at the initial position. For NTSC consoles you should get 4.267 secs, for PAL consoles it takes 5.12 secs.

 

This is also the reason why you cannot assume that an automoving sprite will reach some given location on the screen when it runs faster than speed 1.

Edited March 28, 2017 by mizapf

[sometimes99er]

This one moves the sprite to the right one pixel every frame. You can try other values and examine VDP @>0780-83 to get proof.

 

100 call sprite(#1,35,2,99,99,0,16)
110 goto 110
run
 

Edited March 29, 2017 by sometimes99er

[nanochess]

This one moves the sprite to the right one pixel every frame. You can try other values and examine VDP @>0780-83 to get proof.

 

100 call sprite(#1,35,2,99,99,0,16)
110 goto 110
run
 

 

Thanks!

 

Just I was testing CALL MOTION with js99'er and I got an estimated of 8 pixel fraction at 30 hz but checked with frame by frame and it's 60 hz, and 16 is right for 1 pixel per frame.

[+RXB]

Try RXB 2015 E as it has a updated version of CALL MOTION that can do multiple sprite per line unlike all other XB's.

 

Also the option of CALL MOTION(ALL, row-velocity,col-velocity,.....)

 

Also the CALL DISTANCE is upgraded in RXB to be much more precise, plus you get CALL RMOTION(#sprite,....) that will reverse the motion of that sprite.

 

You can do things in RXB not available in other XB products.

[mizapf]

Ah yes, you're right, of course ... value 16 is for 1 position per frame, and lower values are fractions of that speed. Seems as if I did not have enough sprites in the last years...

[Asmusr]

I guess you can consider the velocities in the sprite motion table as signed 3.4 fixed point values?

[Opry99er]

Don't forget to use the correct SPRITE magnification..

 

[Retrospect]

I've been meaning to ask people on here regarding sprite automotion vs doing it manually -

 

Are there any drawbacks to having a few sprites in automotion at once? .... for example, does it become diuretic and cause a garbage collection or anything? Been noticing lately automotion sprites and the TI locking for a split second then continuing.

[+RXB]

I've been meaning to ask people on here regarding sprite automotion vs doing it manually -

 

Are there any drawbacks to having a few sprites in automotion at once? .... for example, does it become diuretic and cause a garbage collection or anything? Been noticing lately automotion sprites and the TI locking for a split second then continuing.

Garbage collection is only done in VDP memory and Sprite motion does not use Strings so it does not trigger a Garbage collection.

 

Reasons:

1. CALL MOTION uses Numeric Variables and these reside in upper 24K RAM, unless just a console then everything is in VDP.

2. CALL MOTION does not use stack so no Garbage Collection will be triggered on VDP Stack.

 

If a Garbage collection is triggered it was done by XB normally just using temporary buffers processing program lines from Crunch Buffer.

 

Thus Sprites had nothing to do with it, just normal XB processing triggered it.

Edited April 29, 2017 by RXB

[Retrospect]

Thanks rich.

[+Lee Stewart]

I've been meaning to ask people on here regarding sprite automotion vs doing it manually -

 

Are there any drawbacks to having a few sprites in automotion at once? .... for example, does it become diuretic and cause a garbage collection or anything? Been noticing lately automotion sprites and the TI locking for a split second then continuing.

 

Here is the automotion part of the console ISR:

 

 

 

.

.

.

* ------- AUTO SPRITE MOTION ------- (INT. ROUTINE)

MOVB @MOTION,R12

JEQ TSTSND

SRL R12,8

LI R2,>8800 =VDPRD+VDPWA

LI R3,>8C00 =VDPWD+VDPWA

LI R8,>0780 =RSMOT

MLOOP MOVB @R8LSB,*R15 LOAD ADR. TO READ SML

MOVB R8,*R15

CLR R4

MOVB *R2,R4 READ DELTA Y

CLR R6

MOVB *R2,R6 READ DELTA X

SRA R4,4 MOVE RIGHT ONE DIGIT

MOVB *R2,R5 READ TEMP Y

SRA R5,4 MOVE RIGHT ONE DIGIT

A R4,R5

MOVB *R2,R7

SRA R6,4 MOVE RIGHT ONE DIGIT

SRA R7,4 MOVE RIGHT ONE DIGIT

A R6,R7

AI R8,-QSAML CHANGE ADR. TO SAL

MOVB @R8LSB,*R15 LOAD ADR. TO READ SAL

MOVB R8,*R15

CLR R4

MOVB *R2,R4 READ Y POSITION

A R5,R4 ADD Y MOVEMENT TO POSITION

CI R4,6*VDELTA+255

JLE ONSCRN

CI R4,7*VDELTA

JH ONSCRN

MOV R5,R5

JGT C9B2 JMP IS $+6

AI R4,6*VDELTA

C9B2 AI R4,VDELTA

ONSCRN CLR R6

MOVB *R2,R6

A R7,R6

ORI R8,>4000 =WRVDP

MOVB @R8LSB,*R15 LOAD ADR. TO WRITE SAL

MOVB R8,*R15

MOVB R4,*R3

AI R8,QSAML+2

MOVB R6,*R3

SWPB R5

MOVB @R8LSB,*R15 LOAD ADR TO WRITE SML

MOVB R8,*R15

SRL R5,4

MOVB R5,*R3

SWPB R7

SRL R7,4

MOVB R7,*R3

AI R8,2-WRVDP

DEC R12

JGT MLOOP

TSTSND SLA R1,1 THESE 2 INSTN'S NOT ON /4

.

.

.

 

It runs in 16-bit RAM, so is likely faster than anything you can write—even in ALC in 8-bit RAM. Of course, that code loops for every sprite up to the highest sprite # set for automotion, even if one of those sprites is not moving; so it adds to the time spent in the ISR and may be the reason for the occasional missed interrupt (hiccup).

 

...lee

[Retrospect]

Cheers Lee. Hey there was also a bug in version 100 of XB for the Ti99/4 that did something similar to what you mention but up to sprite num 28 even if no sprites were present (am i right? sure i read that somewhere!)

[+Lee Stewart]

Cheers Lee. Hey there was also a bug in version 100 of XB for the Ti99/4 that did something similar to what you mention but up to sprite num 28 even if no sprites were present (am i right? sure i read that somewhere!)

 

I do not know. Someone will be by ere long to answer that one, I am sure.

 

...lee

[+Airshack]

Cheers Lee. Hey there was also a bug in version 100 of XB for the Ti99/4 that did something similar to what you mention but up to sprite num 28 even if no sprites were present (am i right? sure i read that somewhere!)

 

I believe this to be correct.

 

 

Sent from my iPhone using Tapatalk

[Casey]

I tried to find it last night and couldn't, but if you had the 32K RAM, you can issue a CALL LOAD that would set the highest sprite number that could be controlled by automotion. I feel like I saw it in a document on whtech about how to speed up BASIC, but I sure couldn't find it.

[+RXB]

I tried to find it last night and couldn't, but if you had the 32K RAM, you can issue a CALL LOAD that would set the highest sprite number that could be controlled by automotion. I feel like I saw it in a document on whtech about how to speed up BASIC, but I sure couldn't find it.

>837A = -31878 is highest sprite byte in XB.