RXB - Rich Extended Basic

[Tursi]

Having an assembly search is useful, but don't get rid of the hardware check - you want the COINC(ALL) functionality sometimes.

Normally in a game, the programmer is less often asking the system "which two sprites collided?" and more often asking did sprite A (the player) hit any of a range of other sprites (enemies). The former could include things the software doesn't care about, like overlapping enemies.

 

So maybe something like COINC(player_sprite, first_enemy_sprite, last_enemy_sprite) - check by coordinates whether player collided with any of the enemies (in sequence), and return the first hit. That might be more useful?

 

[senior_falcon]

As Lee pointed out, CALL COINC(ALL) detects when pixels on any pair of sprites overlap. Without using ALL you would have to use the sprite row and column to determine whether sprites are touching.  But you also must know something about the shape of the sprites. If you have two sprites are a single pixel then they only have to miss by one pixel. If they are 8 pixel squares then they have to miss by 8 pixels at least. If the sprites were 8 pixel diagonal lines and moving at 45 degrees, in one direction a 1 pixel offset would cause them to miss, but moving the other way they would have to miss by 8 pixels.

Not only that, but if all 28 sprites are touching, CALL COINC(ALL) will return -1 the same as if only 2 were touching.

So this is not a trivial task.

[RXB]

3 hours ago, Lee Stewart said:

 

Well—The thing about CALL COINC(ALL,numeric-variable) is that it relies on the VDP handling whether any two sprites have collided and only needs to read the VDP status register to find out. Any other hits involve reading the Sprite Attribute Table in VRAM for each sprite of interest and, then, making calculations, all of which take a lot more time. One use of checking the coincidence flag is to avoid checking for which sprites collided when the coincidence flag says none did. Of course, one problem with this is that a TRUE coincidence flag means two or more sprites overlap, but you do not know by how much until you check and, if your tolerance is large enough that a hit can happen without actual overlap, the hit could be missed. I suppose a programmer would be unlikely to compose such a scenario, so checking the flag first can still be the best procedure.

 

I am thinking, too, that a programmer is not interested so much in how many sprites have collided, but, rather, whether a particular pair have collided or a particular sprite has collided with a spot (wall?) on the screen.

 

Regarding CALL COLLIDE(ALL,numeric-variable,numeric-variable), it would probably be useful to read the entire Sprite Attribute Table (128 bytes) and deal with the sprite positions from that RAM table. I would think it best to check for the number of active sprites by looking for the lowest numbered sprite with y = >D0. This way, you would not be checking 28 sprites for coincidence when only 5 are in play.

 

I’ll stop rambling for now.

 

...lee

Yea thought of that as you check and look for the >D0 and stop there, as for checking the tolerance and collisions in Assembly it keeps them in RAM from VDP

so only has to read them once never ever has to write to VDP as the checking is in scratch pad. The 28 sprites row and columns are read into FAC and ARG and compared in assembly using 8 registers. 28 words at most need to be compared for overlap of tolerance. That should be pretty quick.

[RXB]

2 hours ago, Tursi said:

Having an assembly search is useful, but don't get rid of the hardware check - you want the COINC(ALL) functionality sometimes.

Normally in a game, the programmer is less often asking the system "which two sprites collided?" and more often asking did sprite A (the player) hit any of a range of other sprites (enemies). The former could include things the software doesn't care about, like overlapping enemies.

 

So maybe something like COINC(player_sprite, first_enemy_sprite, last_enemy_sprite) - check by coordinates whether player collided with any of the enemies (in sequence), and return the first hit. That might be more useful?

 

CALL COINC is still there I just add an assembly version to speed it up, as currently it is written in GPL only.

[RXB]

2 hours ago, senior_falcon said:

As Lee pointed out, CALL COINC(ALL) detects when pixels on any pair of sprites overlap. Without using ALL you would have to use the sprite row and column to determine whether sprites are touching.  But you also must know something about the shape of the sprites. If you have two sprites are a single pixel then they only have to miss by one pixel. If they are 8 pixel squares then they have to miss by 8 pixels at least. If the sprites were 8 pixel diagonal lines and moving at 45 degrees, in one direction a 1 pixel offset would cause them to miss, but moving the other way they would have to miss by 8 pixels.

Not only that, but if all 28 sprites are touching, CALL COINC(ALL) will return -1 the same as if only 2 were touching.

So this is not a trivial task.

Thanks I was thinking of CALL COLLIDE(ALL,tolerance,numeric-variable,numberic-variable) only returns the first collision of sprites and which ones.

Another way is

CALL COLLIDE(#1,#5,tolerance,numeric-variable,numberic-variable,#4,#8,tolerance,numeric-variable,numberic-variable,#2,#6,tolerance,numeric-variable,numberic-variable,#3,#7,tolerance,numeric-variable,numberic-variable) ! this would be for 4 sprites used checking all 4 corners.

I would set the above tolerance to 6 to be safe.

These will be in Assembly as currently CALL COINC and other sprite commands are all in GPL currently.

[RXB]

Just ran a test you can do yourself for RXB 2021 vs Extended Basic 110 vs XB 3:

XB             14 Minutes 14 Seconds

XB 3          12 Minutes   6 Seconds

RXB 2021    7 Minutes   0 Seconds

 

XB and XB 3 Program:

10 MNUM=99

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 DISPLAY AT(23,14)SIZE(2):USING "##":MNUM
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

 

RXB 2021 changed line 140 to CALL HPUT(23,16,"  ",23,16,MNUM)

Thus even using two RXB 2021 HPUT in one single command is faster than USING image and DISPLAY AT(row,col)

[+dhe]

I looked at the docs for hput, and I think this should be correct?

 

Per:

[SteveB]

Hi,

 

for the use of TiCodEd with RXB 2021 store the attached package file in the LIB directory of TiCodEd. It declares all additional subroutines as "internal", as otherwise an "Subroutine not found" Error would occur.

 

Just select this package in the Project-Tab when using RXB 2021.

 

Steve

 

RXB 2021.xbpkg

[senior_falcon]

21 hours ago, dhe said:

I looked at the docs for hput, and I think this should be correct?

 

Per:

I bet CALL HPUT will work better for you.

[+dhe]

 

Thanks Senior_Falcon, that did the trick.

 

FWIW - Windows 10, has a nice stop watch function built in.

 

 

a dumb loop of:

 

29.9 Sec with 'CALL HPUT'

 

vs print I

1:38.78

 

vs display at(10,10):I

59.35

 

Nice!

 

 

[RXB]

Just install a new Character set in RXB 2022 that replaces the one used since 2015.

Notices the need for change as in some game there was no pixel between outside of one and the next if using a full block.

[RXB]

On 12/29/2021 at 3:01 PM, dhe said:

I looked at the docs for hput, and I think this should be correct?

 

Per:

Are you missing ROM 3 from the RXBC.bin?

[RXB]

On 12/30/2021 at 1:41 PM, dhe said:

 

Thanks Senior_Falcon, that did the trick.

 

FWIW - Windows 10, has a nice stop watch function built in.

 

 

a dumb loop of:

 

29.9 Sec with 'CALL HPUT'

 

vs print I

1:38.78

 

vs display at(10,10):I

59.35

 

Nice!

 

 

 

On 12/30/2021 at 1:41 PM, dhe said:

 

Thanks Senior_Falcon, that did the trick.

 

FWIW - Windows 10, has a nice stop watch function built in.

 

 

a dumb loop of:

 

29.9 Sec with 'CALL HPUT'

 

vs print I

1:38.78

 

vs display at(10,10):I

59.35

 

Nice!

 

 

Just ran it again in Classic99 have no clue how yours could be so slow as RXB CALL HPUT is ASSEMBLY whereas DISPLAY AT(row,col) is GPL.

 

I use the clock built into Classic99 to time my loops:

• River Patroller
• 
• 4,764 posts
• Location:Vancouver, Washington, USA

• Report post
•  
•  
•  
• #1356

Posted Wednesday at 02:09 PM

Just ran a test you can do yourself for RXB 2021 vs Extended Basic 110 vs XB 3:

XB             14 Minutes 14 Seconds

XB 3          12 Minutes   6 Seconds

RXB 2021    7 Minutes   0 Seconds

 

XB and XB 3 Program:

10 MNUM=99

100 CALL CLEAR
110 OPEN #1:"CLOCK"
120 INPUT #1:A$,B$,C$
130 FOR C=1 TO 10000
140 DISPLAY AT(23,14)SIZE(2):USING "##":MNUM
150 NEXT C
160 INPUT #1:D$,E$,F$
170 PRINT A$,D$:B$,E$,C$,F$
180 END

 

RXB 2021 changed line 140 to CALL HPUT(23,16,"  ",23,16,MNUM)

Thus even using two RXB 2021 HPUT in one single command is faster than USING image and DISPLAY AT(row,col)

 

 

[RXB]

 

[RXB]

RXB 2022 DEMO 9

Example: PRINT VAL(">2000) would print 8192

               CALL PEEK(VAL(">2000"),A,B) would peek at 8192 in RAM lower 8K

 

RXB 2022 DEMO 9 - YouTube

[RXB]

RXB 2022 DEMO A

EXAMPLE: CALL ALPHALOCK(X) :: PRINT X

If X is zero ALPHALOCK is off, if X is non zero it is on.

 

RXB DEMO A - YouTube

 

[electricfling]

On 1/19/2022 at 1:22 AM, RXB said:

Hi Rich,
with the current RXB version I have the problem that the CALL DIR(1) command in XB mode works fine on my NANOPEB. If I execute the DIRECTORY function in the Editor Assembler, the EA hangs and the TI has to be restarted. The RXB2021 is started by a FINALGROM99. Is it possible that a change is necessary for the FINALGROM and NANOPEB?
Best regards
Gernot

 

 

[RXB]

57 minutes ago, electricfling said:

 

So in REA do you hit 1 and it works or do you type in DSK1?

I have the CorComp and TIPI on my computer and both work fine?

Also has been tested on Myarc, RAMDISKS and SCSI too.

 

It has been reported when you do CALL EA and do a DSR access this can cause

problems and this has been addressed in RXB 2022 when I release it.

 

Does this happen when you select Rich Editor Assembly from main Title screen?

 

This problem was told to me by Arcadeshopper so I fixed this by clearing pointers in RXB 2022.

[electricfling]

22 hours ago, RXB said:

So in REA do you hit 1 and it works or do you type in DSK1?

I have the CorComp and TIPI on my computer and both work fine?

Also has been tested on Myarc, RAMDISKS and SCSI too.

 

It has been reported when you do CALL EA and do a DSR access this can cause

problems and this has been addressed in RXB 2022 when I release it.

 

Does this happen when you select Rich Editor Assembly from main Title screen?

 

This problem was told to me by Arcadeshopper so I fixed this by clearing pointers in RXB 2022.

Thank for the fast answer.
 

There are different combinations.
WITH "2" the directory can be queried in XB mode with CALL DIR(2). With a further call Dir("DSK1."), the TI crashes. With a further attempt it works and the files are indicated. With "3" entry into the REA. "D" and "1" the files are displayed. From "DSK1." works. At a further attempt the TI crashes again. Only after I have switched off the TI completely, it works again.
And now the worse news, in the RXB 2015 I can not so understand. The change from XB to EA with Call EA runs faster in RXB 2015.
Greetings
Gernot

Translated with www.DeepL.com/Translator (free version)

On 1/19/2022 at 1:22 AM, RXB said:

RXB 2022 DEMO A

EXAMPLE: CALL ALPHALOCK(X) :: PRINT X

If X is zero ALPHALOCK is off, if X is non zero it is on.

 

RXB DEMO A - YouTube

 

 

[RXB]

29 minutes ago, electricfling said:

Thank for the fast answer.
 

There are different combinations.
WITH "2" the directory can be queried in XB mode with CALL DIR(2). With a further call Dir("DSK1."), the TI crashes. With a further attempt it works and the files are indicated. With "3" entry into the REA. "D" and "1" the files are displayed. From "DSK1." works. At a further attempt the TI crashes again. Only after I have switched off the TI completely, it works again.
And now the worse news, in the RXB 2015 I can not so understand. The change from XB to EA with Call EA runs faster in RXB 2015.
Greetings
Gernot

Translated with www.DeepL.com/Translator (free version)

 

Yea this is fixed with RXB 2022 as the CALL EA, CALL BASIC routines left a address pointer in DSR space stack.

The fix was to reset stack and delete the DSR PABs in RXB and REA carts.

[+InsaneMultitasker]

Hi Rich,  I have a question about RXB and how you implement random number generation. 

 

Recently, I have been making some minor corrections to the Geneve Advanced BASIC and something I noticed is that the RND random number sequence is always the same.  Also, if you call "RANDOMIZE" without a seed, the same seed is used every single time.  So everything is quite predictable.

 

Are you using a fixed seed or is the seed randomized somehow when RXB initializes its environment?  I don't know the best way to approach this.  I appreciate any insight you might be able to share.

 

[+dhe]

@InsaneMultitasker

 

Bruce wrote an entertaining article on Randomization for Micropendium.

 

1.13.
The Art of Assembly — Part 13. Randomly speaking
by Bruce Harrison
Copyright 1991, Harrison Software
There's nothing so rare as a good sequence of Random Numbers. Today we'll explore random number sequences on the computer and discuss some of the pitfalls waiting for you when you do random number sequences on your friendly little TI.

 

 

[Willsy]

13 hours ago, InsaneMultitasker said:

Hi Rich,  I have a question about RXB and how you implement random number generation. 

 

Recently, I have been making some minor corrections to the Geneve Advanced BASIC and something I noticed is that the RND random number sequence is always the same.  Also, if you call "RANDOMIZE" without a seed, the same seed is used every single time.  So everything is quite predictable.

 

Are you using a fixed seed or is the seed randomized somehow when RXB initializes its environment?  I don't know the best way to approach this.  I appreciate any insight you might be able to share.

 

Can't speak for RXB, but TurboForth uses the value at >83c0 as the seed. I can't remember the function of this word, but IIRC it is incremented (on the 4A) with every VDP interrupt - at least while on the TI title screen. When the user presses a key after booting the machine, the value in >83c0 freezes, and boom - there's your seed.

[+Lee Stewart]

On 1/27/2022 at 4:37 AM, Willsy said:

Can't speak for RXB, but TurboForth uses the value at >83c0 as the seed. I can't remember the function of this word, but IIRC it is incremented (on the 4A) with every VDP interrupt - at least while on the TI title screen. When the user presses a key after booting the machine, the value in >83c0 freezes, and boom - there's your seed.

 

This is true for all cartridges/programs that do not explicitly change >83C0 at startup, like TurboForth, TI Forth, fbForth, CAMEL99 Forth, etc.

 

It is, however, not true for TI Basic (TIB). TIB resets >83C0 to >3567 every time it runs a program, so that the Pseudo Random Number (PRN) sequence always starts with the same seed unless the program uses RANDOMIZE to change it.

 

RXB uses TIB’s RND, but I don’t remember whether it always starts with the same seed.

 

XB, on the other hand, does not use >83C0 for its seed, so its value is irrelevant.* Its seed is actually two** floating point numbers with the first five bytes of each stored at VRAM >03A0 and >03A5. Just as TIB, XB always starts its programs with the same seed:

VRAM @03A0:  >4203 >2315 >00   (decimal   33521)
VRAM @03A5:  >4302 >3E2A >17   (decimal 2624223)

XB has a much more complex PRN generating equation than TIB, which is why RND takes so much longer in XB than it does in TIB.

—————

*  Actually, the XB RANDOMIZE function (without user-supplied seed) does, in fact, use and update the 16-bit value at >83C0 to seed its calculation of the new XB RND seed at VRAM >03A0 and >03A5.

** The XB seed is actually a single number stored and used as two halves to reduce loss of precision: 335212624223.

 

...lee

Edited January 30, 2022 by Lee Stewart
FURTHER CLARIFICATION

[+InsaneMultitasker]

21 minutes ago, Lee Stewart said:

XB, on the other hand, does not use >83C0 for its seed, so its value is irrelevant. Its seed is actually two floating point numbers with the first five bytes of each stored at VRAM >03A0 and >03A5. Just as TIB, XB always starts its programs with the same seed:

VRAM @03A0:  >4203 >2315 >00   (decimal   33521)
VRAM @03A5:  >4302 >3E2A >17   (decimal 2624223)

XB has a much more complex PRN generating equation than TIB, which is why RND takes so much longer in XB than it does in TIB.

 

Ah hah!  The geneve abasic also uses the same seed values and I can attest to its algorithm being fairly complex, so that may also be the same.  Here is how the seed is represented in abasic.  Neat stuff, Lee!

 

X2SEED BYTE SIDVS,SIDRAD,>00,>00
       BYTE >42,>03,>23,>15
X1SEED BYTE SIDVS,SIDRAD,>00,>00
       BYTE >43,>02,>3E,>2A
       BYTE >17