XB tips

[Bones-69]

I thought this might be a good place for tips on XB programming....

 

I have one!

 

We probably all know that the use of sprites can slow XB down. I did some testing with the following programs;

 

Example 1

100 CALL CLEAR:: CALL INIT :: ! FOR A=1 TO 28 :: CALL SPRITE(#A,65,2,100,100+A) :: NEXT A

110 INPUT A$:: FOR I=1 TO 100 :: PRINT I :: NEXT I :: INPUT A$

The execution time for this was around 9 seconds. I used this program as a method of "calibration"

 

Example 2

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28 :: CALL SPRITE(#A,65,2,100,100+A) :: NEXT A

110 INPUT A$ :: FOR I=1 TO 100 :: PRINT I :: NEXT I :: INPUT A$

The execution time for this was around 9 seconds. Putting 28 sprites on the screen but not specifying a velocity seems to come at zero cost.

 

Example 3

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: NEXT A

110 INPUT A$:: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$

The execution time for this was around 13 seconds. Putting 28 sprites on the screen but specifying a velocity comes at the cost of speed and I got the same results when specifying a zero sprite velocity by replacing the sprite command with CALL SPRITE(#A,65,2,100,100,0,0)

 

Example 4

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: CALL MOTION(#A,0,0) :: NEXT A

110 INPUT A$ :: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$

The execution time for this was also 13 seconds. It appears that once you put a sprite in motion and stop it, there is still a cost in execution time as the sprite checking continues even on those sprites that are now stationary - but originally had a velocity specified when they were created.

 

Example 5

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: NEXT A :: CALL LOAD(-31878,0)

110 INPUT A$ :: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$

The execution speed for this was back down to 9 seconds. COOL!

 

In example 5 the CALL LOAD command seems to not only stop sprite motion, but it reverts back to the same result as my example 2 where velocity was never specified. CALL MOTION (#?,0,0) does not do this and you still pay the price of execution speed even after stopping sprite movement.

 

Fiddling with the program, I used CALL PEEK(-31878,B) to discover that the value of B is not the highest sprite displayed on the screen, but the highest sprite that has had a velocity originally specified regardless of if it was still in motion.

 

Using CALL LOAD(-31878,20) for example stopped sprites 20-28 from moving and gave an improvement over execution speeds where sprite checking for those 8 sprites was turned off. CALL LOAD(-31878,10) stopped 18 sprites and resulted in again better execution time.

 

I think using CALL LOAD(-31878,#) is a pretty cool way to stop and start several sprites at the same time, but also found it interesting that you can milk a little more speed from XB using this method to switch off sprite checking for the sprites you no longer wish to be in motion (but still want displayed on the screen). While it is not as flexible as the CALL MOTION command where you can stop an individual sprite (say #20 & #22- but still have #21 in motion), I can see uses for this tip in certain applications. In the instance of the 28 sprites that are completely reset using the CALL LOAD command, there seems to be an improvement of almost 50% in execution time which I though impressive.

 

The above was tested using WIN99/4a and the RXB cartridge. I assume the results are the same for standard XB in original hardware with 32K memory but haven't and can't check....

[Opry99er]

Wow--- great work! This is some great info. Marc Hull has also done some very good stuff with disabling all unneeded "features" to achieve some added efficiency. I'd love for him to post some things here. He has helped me out quite a bit in my XB learning process. Ill post a few tips here myself I'm sure.

[Opry99er]

Okay--- I know there's a way to disble prescan in XB.... Honeycomb and Lemonade Stand both take a bunch of time to kick off because of the 8-10 seconds of pre-scan.... How do I disable it, and how will that affect my program execution (if at all). Thanks in advance!

[+retroclouds]

Check the ninerpedia wiki here.

Look for sections 3.5-3.9

 

I'll update the development resources thread shortly, making reference to the wiki and TI-FAQ.

[Opry99er]

Interesting read!! It's a bit vague on a couple points, but I kind of get the idea here.... The "dead code" section is a bit confusing, but very important I am guessing. I am not sure how to go back and modify my code now--- after the fact, but I'll give er a shot and see if I can re-order some stuff... Thanks for the link, buddy.

[sometimes99er]

Okay--- I know there's a way to disble prescan in XB.... Honeycomb and Lemonade Stand both take a bunch of time to kick off because of the 8-10 seconds of pre-scan.... How do I disable it, and how will that affect my program execution (if at all). Thanks in advance!

Print from manual at mainbyte.com

[Opry99er]

Thanks guys!!

[Opry99er]

I thought I might post this for new XB programmers... It's something that came naturally while I was coding this morning, but I realized that it only comes naturally because I've had to deal with the DISPLAY AT offset as it relates to the CALL HCHAR routine. When doing CALL HCHAR(1,1,42), it starts at the very top left of the screen. When doing "DISPLAY AT(1,1):CHR$(42), it ACTUALLY starts at row 3, column 3. I explain below how this works in application.

 

 

***edit***---

it's actually row 1 column 3... Thanks for pointing that out, sometimes99er.

 

 

I was working on my menu routines in my current game project and had to solve a bit of a problem... I am creating and wiping text within a "box" onscreen, but didn't want to have to re-draw the box over and over, and didn't want to spend a bunch of unnecessary "time" erasing stuff... Since the box is static, here's what I did.

 

Using HCHAR and VCHAR I drew the box edges in columns 1 and 32 repectively. Then I used DISPLAY AT to do all my writing... This means that no matter what I do, I can't affect the sides of the boxes. Since DISPLAY AT only deals with columns 3 through 30, I could safely use DISPLAY AT no matter what I wanted to accomplish.

 

Here's where a bit of syntax knowledge comes in handy. Inside the box, there can be multiple pieces of information, varying in length and content... I had considered using a long string of spaces to wipe the box of information, but tried something else that worked nicely.

 

5000 DISPLAY AT(8,1):" ":" ":" ":" ":" "

 

This wipes all the rows from 8-12 clean. It's compact and simple... This works because DISPLAY AT wipes the line beyond the quoted text. If I wanted to leave everything in place AFTER a quote, a semicolon would be required. For instance, if we do the following:

 

500 DISPLAY AT(8,1):" ";:" ";:" ";:" ";:" ";

 

it only wipes the first character in the lines and leaves the rest in place. In this way, you can manipulate a variety of on-screen information such as a timer... If a timer counts down and you're using the trailing semicolon, you can have problems... For instance...

 

REM "TIMER" is the variable containing our current "count"--- we are counting "down"
DISPLAY AT(25,1):TIMER;
.
.
103
102
101
100
990
980
970
.
.

 

The zero after each count from 99 on down is a "relic" of your three digit timer... So, in this case, using a trailing semicolon screws you up.

 

 

Just something I came across today and thought "someone will find this useful someday." =)

Edited March 6, 2011 by Opry99er

[sometimes99er]

When doing CALL HCHAR(1,1,42), it starts at the very top left of the screen. When doing "DISPLAY AT(1,1):CHR$(42), it ACTUALLY starts at row 3, column 3.

Ain't that row 1, column 3 ?

[Opry99er]

Ha! Yep. It is. I wrote improperly.

[unhuman]

Okay--- I know there's a way to disble prescan in XB.... Honeycomb and Lemonade Stand both take a bunch of time to kick off because of the 8-10 seconds of pre-scan.... How do I disable it, and how will that affect my program execution (if at all). Thanks in advance!

 

There was a program I had as a kid called Prescan It! that did this automagically.

[+RXB]

I thought this might be a good place for tips on XB programming....

 

I have one!

 

We probably all know that the use of sprites can slow XB down. I did some testing with the following programs;

 

Example 1

100 CALL CLEAR:: CALL INIT :: ! FOR A=1 TO 28 :: CALL SPRITE(#A,65,2,100,100+A) :: NEXT A

110 INPUT A$:: FOR I=1 TO 100 :: PRINT I :: NEXT I :: INPUT A$

The execution time for this was around 9 seconds. I used this program as a method of "calibration"

 

Example 2

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28 :: CALL SPRITE(#A,65,2,100,100+A) :: NEXT A

110 INPUT A$ :: FOR I=1 TO 100 :: PRINT I :: NEXT I :: INPUT A$

The execution time for this was around 9 seconds. Putting 28 sprites on the screen but not specifying a velocity seems to come at zero cost.

 

Example 3

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: NEXT A

110 INPUT A$:: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$

The execution time for this was around 13 seconds. Putting 28 sprites on the screen but specifying a velocity comes at the cost of speed and I got the same results when specifying a zero sprite velocity by replacing the sprite command with CALL SPRITE(#A,65,2,100,100,0,0)

 

Example 4

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: CALL MOTION(#A,0,0) :: NEXT A

110 INPUT A$ :: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$

The execution time for this was also 13 seconds. It appears that once you put a sprite in motion and stop it, there is still a cost in execution time as the sprite checking continues even on those sprites that are now stationary - but originally had a velocity specified when they were created.

 

Example 5

100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: NEXT A :: CALL LOAD(-31878,0)

110 INPUT A$ :: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$

The execution speed for this was back down to 9 seconds. COOL!

 

In example 5 the CALL LOAD command seems to not only stop sprite motion, but it reverts back to the same result as my example 2 where velocity was never specified. CALL MOTION (#?,0,0) does not do this and you still pay the price of execution speed even after stopping sprite movement.

 

Fiddling with the program, I used CALL PEEK(-31878,B) to discover that the value of B is not the highest sprite displayed on the screen, but the highest sprite that has had a velocity originally specified regardless of if it was still in motion.

 

Using CALL LOAD(-31878,20) for example stopped sprites 20-28 from moving and gave an improvement over execution speeds where sprite checking for those 8 sprites was turned off. CALL LOAD(-31878,10) stopped 18 sprites and resulted in again better execution time.

 

I think using CALL LOAD(-31878,#) is a pretty cool way to stop and start several sprites at the same time, but also found it interesting that you can milk a little more speed from XB using this method to switch off sprite checking for the sprites you no longer wish to be in motion (but still want displayed on the screen). While it is not as flexible as the CALL MOTION command where you can stop an individual sprite (say #20 & #22- but still have #21 in motion), I can see uses for this tip in certain applications. In the instance of the 28 sprites that are completely reset using the CALL LOAD command, there seems to be an improvement of almost 50% in execution time which I though impressive.

 

The above was tested using WIN99/4a and the RXB cartridge. I assume the results are the same for standard XB in original hardware with 32K memory but haven't and can't check....

 

This is why I put a CALL MOTION(GO) and the CALL MOTION(STOP) in RXB. You can also mix and match like CALL MOTION(STOP, ALL, 10,10, GO) this would stop all the Sprites and put all of them the same motion and then they all start moving again in the same exact direction. The ALL command affects all the sprites and GO and STOP does the same. I added the CALL RMOTION(sprite number) to reverse the direction with out having to recall a variable use as that slows programs and CALL GMOTION(sprite number,X,Y) if you wanted to fetch it. The CALL GMOTION was

originally for Chris of Asgard fame as he wanted a Asgard XB mouse command. I thought of this while we were talking about the problem of using a mouse on the TI99/4A.

[sometimes99er]

This is why I put a CALL MOTION(GO) and the CALL MOTION(STOP) in RXB. You can also mix and match like CALL MOTION(STOP, ALL, 10,10, GO) this would stop all the Sprites and put all of them the same motion and then they all start moving again in the same exact direction. The ALL command affects all the sprites and GO and STOP does the same. I added the CALL RMOTION(sprite number) to reverse the direction with out having to recall a variable use as that slows programs and CALL GMOTION(sprite number,X,Y) if you wanted to fetch it. The CALL GMOTION was

originally for Chris of Asgard fame as he wanted a Asgard XB mouse command. I thought of this while we were talking about the problem of using a mouse on the TI99/4A.

Ahh, very nice insight. Thanks.