Brief explanation of sprite collision function, it tests for collisions between rectangular coordinates so if you have say a sprite that is:

X = 10
Y = 10
W = 8
H = 8

And you wanted to test if this 'rectangle' overlaps with an enemy sprite at:

X = 15
Y = 15
W = 8
H = 8

Like so:


Then you can use the function to check:

real(4,6,1,10,10,8,8,15,15,8,8

In which case they do collide so the result will be a list:

{1,1,0

{1 = collision found
  1 = number of collisions found
  0 = index of collision passed with real( statement

And since there was only 1 set of coordinates passed the first index that collided is 0 (the red square).

Another case:

Rectangles at:

X = 10
Y = 10
W = 8
H = 8

Tested against others where:

X = 15
Y = 15
W = 8
H = 8

X = 48
Y = 32
W = 16
H = 16

X = 8
Y = 0
W = 64
H = 16

Like so:


The call would be: real(4,6,3,10,10,8,8,15,15,8,8,48,32,16,16,8,0,64,16

And the result would be:

{1,2,0,2

{1 = collision found (would be 0 if no collisions occured)
  2 = number of collisions found (green and red)
  0 = collision with index 0 (red)
  2 = collision with index 2 (green)

Index 1 is the orange square for which there was no collision.

There is already sprite<->tilemap collisions but no facility for sprite<->sprite collisions.

Oh right I see now. Thanks for the clarification

EDIT: Does the new xLIBC allow people to use Output() when using xLIBC drawing commands? Right now, you have to use real(0,1,0,1) before using Output, else it's screwed up, but then you are stuck with the gray bar at the screen top. Hexatron is doing a Celtic remake of Illusiat 11, but would like to get rid of the gray bar:

No longer necessary (I did it in ASM), but it still would be a nice feature.

He wanted to stick to the TI-OS ASCII characters so that he doesn't have to modify the entire game with many real( commands. The goal was to keep the game as it is, but still apply some minor updates such as color additions, perhaps an HUD or a logo and get rid of the surrounding gray/white.

Well you can still draw to both sides of GRAM without setting half-res mode, you just need to do it in 2 calls.

Good news, i fixed the Output( bug! Now xLIBC commands play nicely with the TIOS .

Also i discovered that returning values into a List in Ans is SLOW. So slow that it halved the fps of the xLIBC DEMO :S. But the workaround is that I now create a user-defined list call "XL" that holds all the arguments needed. This is only for the Sprite Collision routines. But I probably should port it over to the getKey->List routine as well.

Question: Does the new xLIBC version work with very large string files? (such as 60 KB large)

Also, is there a command to store a string to Str0-Str9 without copying it to Ans first? For example, something like real(6,3,"HELLO WORLD, MY NAME IS "+Sub("JAMESDAVIDMATT JOEY ",L1(25)*5+1,5)+"!",6) that would store to Str6 and work with strings of any size (or at least up to 8 KB or so).

The current issue is that when we need to copy a map to a string for use with the DrawMap command, it takes a crapload of RAM (enough RAM for the program containing the string data, plus twice or three times the RAM required to store the string).

Yeah this is not for displaying strings anyway, more for map data storage in my case (strings up to 7 or 9 KB in size)