I'm programming a little card game in Pascal. Card games in Pascal are fun programming exercises but are generally not visually interesting. I'm looking at changing up the UI to show cards being dealt, presented, flipped. I looked into turtlegraphics, but I'm thinking I'll use sprites. If for no other reason than because I have access to far more documentation on sprites than turtlegraphics.
Sprites will make it a non-portable Pascal program, but my goal in doing this wasn't to create a portable Pascal program. The current text UI version of the code is portable to any UCSD system, save for the random number generator. I found some pseudo-random-number generators that I believe could be easily implemented, so that's likely a problem easily solve-able. I'm just going for a little visual improvement.
With all of that as a preamble, here's my question.
It's been a long time since I coded sprites, so I'm creating some test cases to model out the things I'll need to do for this to work. My test moves a double-sized sprite (not magnified) from (y=95,x=128) at velocity (y=-8, x=0) for a countdown of 64, then a velocity of (y=-4,x=0) for a countdown of 64. Then it holds position. I'm just experimenting with showing a card come out fast, then slow down, then stop. (Inspired by the truly beautiful motion of the Q*Bert demo we saw at the Evanston meet-up a few weeks ago!) I'd expect the sprite to end up at 95 + ((-8/32*64) + (-4/32*64)), or y=71, x=128. It isn't. It's ending up at double the distance: y=47, x=128.
The velocity/32 every 60th of a second math comes from page 145 of the Pascal Compiler manual. This suggests a sprite travels just about 2 pixels every 60th of a second. Or, assuming it's an octal and not a decimal clock, 1 / 32 * 64 == 2.
The Editor/Assembler manual has a different description on sprite motion. Page 341 says, that a velocity of >01 causes a sprite to move one pixel every 16/60th. Assuming that the velocity is the same, it seems to me that the assembler manual says we get 4 pixel moves every (roughly) 60th of a second. Back to our octal clock, 16/64 == 4.
If I'm reading this right, the sprite speed in the assembler manual would describe the 2x difference in velocity that I'm seeing with where my sprite is ending up.
I haven't run all possible tests yet to figure out if I'm just thick-headed. I haven't coded sprites in assembly or XB routines to time comparisons, I haven't re-timed using a standard sized sprite, etc.
But anyone who is familiar with sprite motion who knows the velocity I should expect, I would appreciate it.