Best Way(s) to Move a Game Character in TI BASIC (not Extended BASIC) without CALL CLEAR

[zacharyfruhling]

What are the best way(s) to move a game character on the screen in TI BASIC without clearing the entire screen with CALL CLEAR every time a character is repositioned?

[GDMike]

Hchar, clear old character then place the new character.

Or use sprites

Edited December 28, 2022 by GDMike

[zacharyfruhling]

11 minutes ago, GDMike said:

Hchar, clear old character then place the new character.

Or use sprites

It's a long story, but I'm trying to recreate an old game program my dad wrote for me when I was a little kid in regular TI BASIC. Using sprites in Extended BASIC would certainly simplify things, but I'm hoping to create as faithful a rendition of this old game as possible using only regular TI BASIC. (More details are forthcoming as I get further along in recreating the program!)

 

Ah, yes, it sounds obvious now that you've said it, but one could just clear the old character using HCHAR or VCHAR and then use another HCHAR or VCHAR command to place the new character in an adjacent screen position. Thanks!

Edited December 28, 2022 by zacharyfruhling

[+TheBF]

1 minute ago, zacharyfruhling said:

It's a long story, but I'm trying to recreate an old game program my dad wrote for me when I was a little kid in regular TI BASIC. Using sprites in Extended BASIC would certainly simplify things, but I'm hoping to create as faithful a rendition of this old game as possible using only regular TI BASIC. (More details are forthcoming as I get further along in recreating the program!)

 

Ah, yes, it sounds obvious now that you've said it, but one could just clear the old character using HCHAR or VCHAR and then use another HCHAR or VCHAR command to place the new character in an adjacent screen position. Thanks!

(HCHAR() is the faster one) 

[zacharyfruhling]

5 minutes ago, TheBF said:

(HCHAR() is the faster one) 

Oh, I didn't realize that HCHAR was faster for placing single characters than VCHAR. I'll take every speed-boost tip I can get for this program!

[SteveB]

I usually keep the old coordinates in a separate set of variables, so I can do

 

CALL HCHAR(YOLD,XOLD,32,1)

CALL HCHAR(Y,X,88,1)

 

directly following each other to avoid the blinking. If you just update if you really moved I would even exchange the two ... first draw the new one, than remove the old one ...

 

[zacharyfruhling]

16 minutes ago, SteveB said:

I usually keep the old coordinates in a separate set of variables, so I can do

 

CALL HCHAR(YOLD,XOLD,32,1)

CALL HCHAR(Y,X,88,1)

 

directly following each other to avoid the blinking. If you just update if you really moved I would even exchange the two ... first draw the new one, than remove the old one ...

 

I was thinking that I would need variables to store the previous X,Y coordinates as well. Yes, I'm trying to avoid as much blinking as possible.

 

One more question: Short of using sprites in Extended BASIC, is there a way to detect key press / key hold (say, to adjust a firing angle from a spaceship.) without massively slowing down the velocity of other items on the screen (e.g., a moving target character). I am able to create a Call Key loop to detect a key press/hold to rotate a firing angle (after some trial and error), but then the action on the screen just grinds to a halt while doing so. Any guidance on key hold detection without getting stuck in a loop that freezes up the game action would be very, very helpful!

[1980gamer]

sample...

 

 

10 CALL CLEAR
20 CALL CHAR(64,"0F0F0F0F0F0F0F0F")
30 CALL CHAR(65,"FFFFFFFFFFFFFFFF")
40 CALL CHAR(66,"F0F0F0F0F0F0F0F")
50 FOR M=3 TO 31
60 CALL HCHAR(5,M,65)
70 CALL HCHAR(5,M+1,66)
75 CALL HCHAR(8,M,65)
80 CALL HCHAR(5,M-1,64)
90 CALL HCHAR(5,M-1,32)
95 CALL HCHAR(8,M-1,32)
100 NEXT M

 

row 5 is HALF char move and row 8 is FULL char move.   You could add 1/4 or 1/8 but you would slow movement down.

 

I also cheated doing the half...  But I want them to scroll/move in one loop.

 

Go even faster...  How about a race!

 

10 CALL CLEAR
20 CALL CHAR(65,"E0E7427F7F42E7E0")
30 FOR M=4 TO 32 STEP 4
40 CALL HCHAR(8,M/4,65)
50 CALL HCHAR(10,M/2,65)
60 CALL HCHAR(12,M,65)
70 CALL HCHAR(8,M/4,32)
80 CALL HCHAR(10,M/2,32)
90 CALL HCHAR(12,M,32)
100 NEXT M
110 GOTO 30

 

 

[RXB]

31 minutes ago, 1980gamer said:

sample...

 

 

10 CALL CLEAR
20 CALL CHAR(64,"0F0F0F0F0F0F0F0F")
30 CALL CHAR(65,"FFFFFFFFFFFFFFFF")
40 CALL CHAR(66,"F0F0F0F0F0F0F0F")
50 FOR M=3 TO 31
60 CALL HCHAR(5,M,65)
70 CALL HCHAR(5,M+1,66)
75 CALL HCHAR(8,M,65)
80 CALL HCHAR(5,M-1,64)
90 CALL HCHAR(5,M-1,32)
95 CALL HCHAR(8,M-1,32)
100 NEXT M

 

row 5 is HALF char move and row 8 is FULL char move.   You could add 1/4 or 1/8 but you would slow movement down.

 

I also cheated doing the half...  But I want them to scroll/move in one loop.

 

Go even faster...  How about a race!

 

10 CALL CLEAR
20 CALL CHAR(65,"E0E7427F7F42E7E0")
30 FOR M=4 TO 32 STEP 4
40 CALL HCHAR(8,M/4,65)
50 CALL HCHAR(10,M/2,65)
60 CALL HCHAR(12,M,65)
70 CALL HCHAR(8,M/4,32)
80 CALL HCHAR(10,M/2,32)
90 CALL HCHAR(12,M,32)
100 NEXT M
110 GOTO 30

 

 

RXB runs almost all TI Basic programs as long as you do not use strange quirks of only TI Basic like odd logic commands where XB has NOT, OR, NOR and AND.

 

10 CALL CLEAR
20 CALL CHAR(64,"0F0F0F0F0F0F0F0F",65,"FFFFFFFFFFFFFFFF",66,"F0F0F0F0F0F0F0F")
50 FOR M=3 TO 31
60 CALL HCHAR(5,M,65,1,5,M+1,66,1,8,M,65,1,5,M-1,64,1,5,M-1,32,1,8,M-1,32)
100 NEXT M



10 CALL CLEAR
20 CALL CHAR(65,"E0E7427F7F42E7E0")
30 FOR M=4 TO 32 STEP 4
40 CALL HCHAR(8,M/4,65,1,10,M/2,65,1,12,M,65,1,8,M/4,32,1,10,M/2,32,1,12,M,32)
100 NEXT M
110 GOTO 30

As you can see extremely efficient and more compact.

Also line 20 above could be rewritten as:

20 CALL CHAR(64,"0F0F0F0F0F0F0F0FFFFFFFFFFFFFFFFFF0F0F0F0F0F0F0F")

You can load up to 15 character definition in a single command unlike XB only allows 4 and TI Basic only 1.

[1980gamer]

3 minutes ago, RXB said:

RXB runs almost all TI Basic programs as long as you do not use strange quirks of only TI Basic like odd logic commands where XB has NOT, OR, NOR and AND.

 

10 CALL CLEAR
20 CALL CHAR(64,"0F0F0F0F0F0F0F0F",65,"FFFFFFFFFFFFFFFF",66,"F0F0F0F0F0F0F0F")
50 FOR M=3 TO 31
60 CALL HCHAR(5,M,65,1,5,M+1,66,1,8,M,65,1,5,M-1,64,1,5,M-1,32,1,8,M-1,32)
100 NEXT M



10 CALL CLEAR
20 CALL CHAR(65,"E0E7427F7F42E7E0")
30 FOR M=4 TO 32 STEP 4
40 CALL HCHAR(8,M/4,65,1,10,M/2,65,1,12,M,65,1,8,M/4,32,1,10,M/2,32,1,12,M,32)
100 NEXT M
110 GOTO 30

As you can see extremely efficient and more compact.

Also line 20 above could be rewritten as:

20 CALL CHAR(64,"0F0F0F0F0F0F0F0FFFFFFFFFFFFFFFFFF0F0F0F0F0F0F0F")

You can load up to 15 character definition in a single command unlike XB only allows 4 and TI Basic only 1.

Trying to be BASIC and not define multiple chars in 1 command.

Also, they do not want to use XB or RXB.  Just BASIC.

 

Otherwise I would have given sprite examples.

 

[pixelpedant]

If you want to get really fancy, here is a TI BASIC ESDX movement input routine (i.e., for moving a single-tile character based on input from the ESDX keyboard keys) based on the method I use in Hell's Halls (which I've attempted to disentangle from all the surrounding program logic, since in practice, that program is handling a lot more than motion):

 

100 CALL KEY(1,K,Z)
110 IF (K>5)+(K=4)+(ABS(K)=1) THEN 100
120 YM=(K=5)-(K<1)
130 XM=(K=2)-(K=3)
140 CALL GCHAR(PY+YM,PX+XM,GC)
150 CALL HCHAR(PY,PX,CT)
160 PY=PY+YM
170 PX=PX+XM
180 CT=GC
190 CALL HCHAR(PY,PX,40+K)

 

So, to summarise, 0,2,3 and 5 (the ESDX direction keys, via CALL KEY Key Unit 1) are valid inputs, as assigned to K, and these values are tested for (or rather, the absence of these values is tested for by exclusion), by the relevant conditional (Line 110), which, in the manner of so many TI BASIC conditionals, uses arithmetic operators as de facto logical operators. 

 

If valid input is given, positive or negative adjustments to the X and Y coordinates of the player (PX,PY) are then tested for (Lines 120,130), and assigned to YM and XM (one of which will now equal +1 or -1).  Note that we cannot test for K=0, as the 0 returned by CALL KEY is aberrant, and non-equivalent to the constant 0 on the 99/4A (though notably, this bug is absent on the 99/4).  Anyway, hence, (K<1).

 

Now we need to know what tile exists in the square the player is trying to move into (a floor tile? a wall tile? An enemy?), and that will be acquired via CALL GCHAR (Line 140).  That puts this character into the variable GC for further tests (in practice, a pair of ON GOSUBs which handle 20 or so possible tile values, not shown here). 

 

Now that we know what tile we're trying to walk towards let's assume that action is possible or whatever outcome can be handled.  So we start by replacing the current player tile (stored in PY and PX) with the character which existed there before the player moved into it (Line 150).  This 'current tile' is held in the variable CT at all times. 

 

The player coordinates can now be updated with the Y and X modifications implied by the input provided (Lines 160,170).  As well, with the player coordinates changed, we can update the current tile value to the new one furnished by CALL GCHAR (Line 180), before overwriting it with the player.

 

Finally, the player character itself can be drawn to the new tile at the new PY/PX coordinates (Line 190).  One of the four "directional" representations of the player is selected from the pattern table automatically, as these are located at 40,42,43, and 45.  And with the CALL HCHAR command drawing character 40+K, where K is the CALL KEY return value for Key Unit 1, this will equal either 0,2,3 or 5 and hence in sum 40,42,43 or 45. 

[RXB]

1 hour ago, 1980gamer said:

Trying to be BASIC and not define multiple chars in 1 command.

Also, they do not want to use XB or RXB.  Just BASIC.

 

Otherwise I would have given sprite examples.

 

I guess the idea is to make it as inefficient and slow as possible.

Sort of like running up hill dragging as many rocks as you can in your backpack.

Reasons?

[zacharyfruhling]

1 hour ago, RXB said:

I guess the idea is to make it as inefficient and slow as possible.

Sort of like running up hill dragging as many rocks as you can in your backpack.

Reasons?

Nostalgia is the only reason. My dad was able to make a working version of the program in regular TI BASIC that I'm attempting to recreate, and I thought I'd give myself the same constraints, just for proverbial kicks.

[GDMike]

11 hours ago, 1980gamer said:

Trying to be BASIC and not define multiple chars in 1 command.

Also, they do not want to use XB or RXB.  Just BASIC.

 

Otherwise I would have given sprite examples.

 

 

If  fast, then  choose assembly,  forth or C - not a flavor of Basic.

 

Or  run in turbo on classic99.  

 

But this is about a basic program that runs off tape with no memory expansion if I got this right.  

 😆😂😆😆😂 

Edited December 29, 2022 by GDMike

[+Ksarul]

18 hours ago, zacharyfruhling said:

One more question: Short of using sprites in Extended BASIC, is there a way to detect key press / key hold (say, to adjust a firing angle from a spaceship.) without massively slowing down the velocity of other items on the screen (e.g., a moving target character). I am able to create a Call Key loop to detect a key press/hold to rotate a firing angle (after some trial and error), but then the action on the screen just grinds to a halt while doing so. Any guidance on key hold detection without getting stuck in a loop that freezes up the game action would be very, very helpful!

I don't think anyone has tried to answer this part of your question yet, but you are going to run into some of the interesting constraints of TI BASIC with this one. As you have already seen what the standard CALL KEY loop does to screen motion, not pretty since the loop doesn't allow anything else to happen until you exit the loop, you could potentially make a motion subroutine and have the program jump to it from the loop, move the items that need to keep moving, and return to the loop to continue loop execution. It will still be slow, but that should keep things from getting glacial. It has been a long time since I programmed in console BASIC, so that might (or might not) work as described. I suspect you would need to account for several global variables as well, since the subroutine would need to know which character was moving, its pattern, and both direction and speed of motion.

[+OLD CS1]

Start with what is available.  For instance, go to @Vorticon's TI Game Shelf, check out the TI BASIC programs there.  I also posted a blog entry about a fairly quick input routine in both BASIC and Extended BASIC.

 

There is literally (as the kids would say) no reason to CALL CLEAR to move a single character on the screen.  In its most simple form, you will have two variables maintaining the character's row and column position.  Say, R and C.  Then, when you run the routine to move, you just HCHAR a space (ASCII 32, or whatever you decide to use as a background character,) onto the current R,C coordinates, perform the R,C update including bounds and collision checking, then plot the character in its new R,C position.

 

I like to do the bounds checking before the update so the character does not flash, unless the flashing would serve a purpose -- for instance, in Tiles, the selection arrow is my "character" and it flashes to indicate a bad choice or selection.

 

Bounds checking can be literal or variable based, such as hard-coding the bounds of 2,20,2,18 or an array holding a grid like G(20,18) which contains values for bounds and enemies, bonuses, obstacles, &c.  A combination of both could be used, as well: use literal bounding values to prevent over-runing the array, then checking the value in the array for whatever goodie (or badie) is in store for your character.

 

Or you can trust the screen and use GCHAR to look for boundary characters, enemies, bonuses, &c. in the proposed direction of movement.  If enemies or bonuses are to be mobile, you would need to keep track of them, as well.  Recognize that GCHAR usually has a larger penalty than using variables.

[RXB]

11 hours ago, GDMike said:

 

If  fast, then  choose assembly,  forth or C - not a flavor of Basic.

 

Or  run in turbo on classic99.  

 

But this is about a basic program that runs off tape with no memory expansion if I got this right.  

 😆😂😆😆😂 

RXB 2022 CALL CLEAR, CALL HCHAR, CALL VCHAR are all written in Assembly and backwards compatible with Basic.

And with a FinalGROM will run from CONSOLE ONLY! 

No memory expansion needed but you can use it or SAMS also not required to work.

[1980gamer]

28 minutes ago, RXB said:

RXB 2022 CALL CLEAR, CALL HCHAR, CALL VCHAR are all written in Assembly and backwards compatible with Basic.

And with a FinalGROM will run from CONSOLE ONLY! 

No memory expansion needed but you can use it or SAMS also not required to work.

1st. RXB is a nice product.

2nd. It is clearly a passion project for you.

3rd. You never seem to read the questions asked?  You just cannot wait to tell everyone RXB is how it should be done.  Forgetting the very fact that it was to recreate something from years before RXB or FinalGROM.

 

If someone wanted to create something to be as fast as possible...  It would not be in BASIC, XB, RXB, TI forth or TI assembly.  It would be on a system with a processor from this century, no matter what language it is!

[1980gamer]

3 hours ago, Ksarul said:

I don't think anyone has tried to answer this part of your question yet, but you are going to run into some of the interesting constraints of TI BASIC with this one. As you have already seen what the standard CALL KEY loop does to screen motion, not pretty since the loop doesn't allow anything else to happen until you exit the loop, you could potentially make a motion subroutine and have the program jump to it from the loop, move the items that need to keep moving, and return to the loop to continue loop execution. It will still be slow, but that should keep things from getting glacial. It has been a long time since I programmed in console BASIC, so that might (or might not) work as described. I suspect you would need to account for several global variables as well, since the subroutine would need to know which character was moving, its pattern, and both direction and speed of motion.

OMG, I just always press 2 for XB when I start my TI.

I didn't remember if BASIC handled Subs.

@zacharyfruhling Basic does handle subroutines as @Ksarul was talking about.

 

In your game loop you can CALL different routines based on game actions or user input.

 

Kind of a time slicing thing.  I created a simple gosub and return as a test. 

These SUBS could be check for Keyboard press or Fire Missile or END GAME screen with Music etc.  Hint.  KEY value 18 is Q and is also the joystick fire button.

 

The TI99/4A was my first computer and I wanted to make games!  I will say that life changed the first time I set a sprite in motion!

Then it changed again, when I tried to detect 2 sprites colliding.    LOL.

 

Never the less, 1981/82 was a magical time for an 11 year old learning BASIC on my own.  Not even a cassette to save to for several months. 

I did not know how to type...  But learned PRINT, GOTO, IF THEN etc. quickly.  Picked up bad habits... But eventually learned the home row and how to type.

Though I still find myself typing PRINT etc. the wrong way.  LOL

 

Sample:

10 CALL CLEAR
20 GOSUB 1000
30 GOSUB 2000
40 GOSUB 3000
50 END
1000 PRINT 1
1010 RETURN
2000 PRINT 2
2010 RETURN
3000 PRINT 3
3010 RETURN

 

[retrodroid]

6 minutes ago, 1980gamer said:

OMG, I just always press 2 for XB when I start my TI.

I didn't remember if BASIC handled Subs.

@zacharyfruhling Basic does handle subroutines as @Ksarul was talking about.

 

In your game loop you can CALL different routines based on game actions or user input.

 

Kind of a time slicing thing.  I created a simple gosub and return as a test. 

These SUBS could be check for Keyboard press or Fire Missile or END GAME screen with Music etc.  Hint.  KEY value 18 is Q and is also the joystick fire button.

 

The TI99/4A was my first computer and I wanted to make games!  I will say that life changed the first time I set a sprite in motion!

Then it changed again, when I tried to detect 2 sprites colliding.    LOL.

 

Never the less, 1981/82 was a magical time for an 11 year old learning BASIC on my own.  Not even a cassette to save to for several months. 

I did not know how to type...  But learned PRINT, GOTO, IF THEN etc. quickly.  Picked up bad habits... But eventually learned the home row and how to type.

Though I still find myself typing PRINT etc. the wrong way.  LOL

 

Sample:

10 CALL CLEAR
20 GOSUB 1000
30 GOSUB 2000
40 GOSUB 3000
50 END
1000 PRINT 1
1010 RETURN
2000 PRINT 2
2010 RETURN
3000 PRINT 3
3010 RETURN

 

I was right there with you, brother!  No cassette cables because they were back-ordered, and then when they finally came they were defective. I think I went 6 months or more without any way to save my programs. So many 99er magazine games typed in, multiple times.  My friends and I had a system where one would read the magazine code out loud and the other would enter it. We'd take turns typing. Then we'd play the game for as long as we wanted or usually until my TI would get "zapped" by a static electricity charge and lock up.  😐

 

Like going to war, adversity like that bonds people for life.  lol.

 

 

 

Edited December 29, 2022 by retrodroid

[1980gamer]

@retrodroid

My friend David and I would do the same thing from Compute! magazine.  LOL

 

We started earlier with the character definition program in the book.  Type that in several times before being able to save it to tape.

 

I later expanded it to 16x16 for sprites.  I was so used to David reading while I typed, I had the Speech Synth say the hexadecimal code to me so I could write it down in a notebook.

 

[GDMike]

2 hours ago, 1980gamer said:

1st. RXB is a nice product.

2nd. It is clearly a passion project for you.

3rd. You never seem to read the questions asked?  You just cannot wait to tell everyone RXB is how it should be done.  Forgetting the very fact that it was to recreate something from years before RXB or FinalGROM.

 

If someone wanted to create something to be as fast as possible...  It would not be in BASIC, XB, RXB, TI forth or TI assembly.  It would be on a system with a processor from this century, no matter what language it is!

 I think it's impossible to put this basic program on FG. 

Mini-memory, yes. Cassette, yes. I think that's all you can do with an unexpanded system.

Which is just fine. Wait..hold the cell phone. 

It's exactly what I did in 1985 and thousands of other people did to.

Edited December 29, 2022 by GDMike

[1980gamer]

5 hours ago, GDMike said:

 I think it's impossible to put this basic program on FG. 

Mini-memory, yes. Cassette, yes. I think that's all you can do with an unexpanded system.

Which is just fine. Wait..hold the cell phone. 

It's exactly what I did in 1985 and thousands of other people did to.

Rich was talking about putting RXB on the FinalGrom.

Thus making it an expanded console, like XB would have done as well.

 

I remember having just basic and having plenty to do and learn.

I am kind of glad it took me a while to get XB.  Then I was only learning the additional commands.

I didn't spend a lot of time in the XB book.  I pretty much just left the Reference card ( folded thing ) tucked under the XB cart for quick reference. Hmm, Hence the name! 

 

[RXB]

22 hours ago, 1980gamer said:

1st. RXB is a nice product.

2nd. It is clearly a passion project for you.

3rd. You never seem to read the questions asked?  You just cannot wait to tell everyone RXB is how it should be done.  Forgetting the very fact that it was to recreate something from years before RXB or FinalGROM.

 

If someone wanted to create something to be as fast as possible...  It would not be in BASIC, XB, RXB, TI forth or TI assembly.  It would be on a system with a processor from this century, no matter what language it is!

Who ever said fast as possible? Did anyone suggest a Super Computer worth millions of dollars?

Console only Basic is super slow and inefficient and everyone know this even you. 

Any upgrade to it would be an improvement, even XB cart is faster overall, and RXB has faster assembly routines that are backwards compatible.

So now even a cartridge in the cart slot is just a step to far for you?

And you cannot run any other language on the TI without a 32K so that sure is not console alone.

Well LOGO maybe...

Is the Cassette a step to far too?

Or does each program have to be typed in by hand?

[RXB]

14 hours ago, 1980gamer said:

Rich was talking about putting RXB on the FinalGrom.

Thus making it an expanded console, like XB would have done as well.

 

I remember having just basic and having plenty to do and learn.

I am kind of glad it took me a while to get XB.  Then I was only learning the additional commands.

I didn't spend a lot of time in the XB book.  I pretty much just left the Reference card ( folded thing ) tucked under the XB cart for quick reference. Hmm, Hence the name! 

 

My first TI came with Minimemory and XB.

Took just a few seconds to see TI Basic sucked compared to XB and Mini Memory had 4K of RAM added to Console that was 3 times faster than VDP.

So good ol Basic took a back seat pretty fast.