Pretty self-explanatory

Ok, so I made this program that's supposed to move a spaceship sideways. However, it acts really weird when I compile it and run it.

Code:


The solution will probably be so obvious, but I can't see anything wrong...

Your code is probably doing something weird.

Which is to say: that's not helpful for anybody else to try to debug it. Elaborate.

Oof. Ok.

I can successfully compile the code and send it to my calc. The sprite shows up correctly, but it flickers (which sprites from another tutorial didn't do when I tested their code). I ignored that and tried to press the left and right keys, but then the screen glitched out, and shaded the bottom 2/3's of the screen with pixels.

That's more helpful.

Looks like you're continuously scanning the keyboard and XORing the sprite to the screen, which would cause visible flicker- every iteration of the loop you're either drawing or erasing the sprite, and they alternate.

I suspect filling the screen is because your loop is much faster than you can press and release a key, so when you press right (for example) you end up incrementing the position by a large number. When the position exceeds the x-resolution of the screen, it will move down one row (since the display memory has row-major ordering) and continue from the left edge. Plus you don't erase the previous sprite when you move, so it will tend to leave junk onscreen.

Why is the screen never cleared between iterations of the loop? You should double buffer.

If you're just waiting for a key, it might be easier to use ngetchx(), which will wait automatically until a key is pressed (kbhit() is like TI-BASIC getKey in that it doesn't block waiting for a key). Also, from the code, it looks like the second Sprite8() call intended to erase the sprite before redrawing it is outside the while loop, so that instead of happening after the keypress tests, it would only happen once, just before the program exits. As a result, the code is alternately drawing and erasing the sprite every key test (which will leave odd junk on the screen as soon as a key is pressed and it ends up trying to erase the sprite at different coordinates than it drew it).

Using ngetchx() fixed it, so now the sprite moves as intended! I also moved the Sprite8() call inside the while loop (I seriously thought it was inside the loop already). Thanks for the help on that guys!

Another question: I run the program and it takes a while for repeated keypresses (pressing and holding the left arrow key, for example) to register. Therefore, there's some noticeable delay when moving back and forth. I researched how to fix this in the documentation, and I found out that I could call OSFastArrows using the following syntax:


Code:


But there's supposed to be an additional argument (a number) that determines the speed of the arrows. How would I add that argument? I've tried the following:

Code:


Code:

And both of them don't work. I'd appreciate some help please

That's not a function call, that's a variable declaration that happens to be named OSFastArrows. Documentation for others' benefit.

Those docs are not great in describing how to actually use it; since it's a global and used by the libraries you probably need to link it as an external symbol, presumably already coming from that header.

Code:

OSFastArrows is seldom used by TI-68k programmers, because it's a direct portability issue for little practical benefit: it only works on AMS 2.xx and 3.xx, and it doesn't work on PedroM.

If you don't want to use low-level keyboard reading (_rowread, _keytest), the usual way to get keypresses much more efficiently than with ngetchx(), kbhit() or GKeyIn() is using OSdequeue() + kbd_queue(). Most TICT programs do that, you can borrow their GetKeyInput() or similarly named routine at will.