Which is faster?

[Retrospect]

I've got a few enemies for Anubis in mind. I want them animated, 'cos that looks damn good to be honest. 

 

So what's the faster method in terms of execution / not getting the game bloated .... 

 

1 ... changing the patterns by re-defining a character code, ie;

       P=P+1 :: IF P>4 THEN P=1
       ON P GOTO xxxx,xxxx,xxx,xxxx
      CALL CHAR(60,"blahblahblah") :: GOTO xxxx
       CALL CHAR(60,"blahdeblahdeblah"):: GOTO xxxx

2 ... having the patterns stored in the characters, ie;
       CALL CHAR(64,"blahblah")
       CALL CHAR(68,"blahdeblah")
       CALL CHAR(72,"blahdebloodyblah")
     and then cycling through the patterns with CALL PATTERN(#3,PAT)       .... (PAT storing the relevant number)

Edited November 2, 2022 by Retrospect

[+OLD CS1]

Changing the sprite pattern is faster.

[Retrospect]

8 minutes ago, OLD CS1 said:

Changing the sprite pattern is faster.

As in , PAT=PAT+4 :: IF PAT>88 THEN PAT=64
          CALL PATTERN(#3,PAT)   ?   

[pixelpedant]

Yes, CALL PATTERN is dramatically faster.  CALL CHAR is XB's slowest graphical command by a fairly large margin.  Where CALL PATTERN is one of its fastest. 

[Retrospect]

Great, good stuff .... Yeah , Anubis was suffering from a bit of a slow-down as I was using CALL CHAR for various enemies.  Whilst it saves on character patterns the trade-off was becoming obvious so I needed to know for sure

 

I'm sure I'll still have enough patterns for a few different animated enemies on screen.  Thanks guys

[+TheBF]

2 hours ago, pixelpedant said:

Yes, CALL PATTERN is dramatically faster.  CALL CHAR is XB's slowest graphical command by a fairly large margin.  Where CALL PATTERN is one of its fastest. 

Does anyone know why?

I guess that CALL CHAR is converting the text string to integers at run-time each time it is called which is a lot of overhead.

Does CALL PATTERN pre-compute the string to integers and keep them stored as binary data?

[pixelpedant]

In Extended BASIC, there is no independent sprite pattern table.  There is a character pattern table which is also the sprite pattern table.  Thus, CALL PATTERN doesn't need to copy data from the character pattern table to set a sprite pattern.  It just needs to set the relevant character value in the sprite attribute table. 

 

Or such is my understanding. 

[SteveB]

2 hours ago, pixelpedant said:

Yes, CALL PATTERN is dramatically faster.  CALL CHAR is XB's slowest graphical command by a fairly large margin.  Where CALL PATTERN is one of its fastest. 

If you are running out of usable characters or want to animate characters instead of sprites, you might want to use XB256 VREAD and VWRITE routines and store the binary patterns in strings. This really speed up the movement in Scuttlebutt, where the player is 42 characters big ... 

[fabrice montupet]

41 minutes ago, SteveB said:

you might want to use XB256 VREAD and VWRITE routines and store the binary patterns in strings. This really speed up the movement in Scuttlebutt, where the player is 42 characters big ... 

It is the solution that I use and that's very quick. Add to that the ability to compile the program, XB256 has the top place for all TI Extended Basic programmers.

[+Lee Stewart]

1 hour ago, TheBF said:

Does anyone know why?

I guess that CALL CHAR is converting the text string to integers at run-time each time it is called which is a lot of overhead.

Does CALL PATTERN pre-compute the string to integers and keep them stored as binary data?

 

1 hour ago, pixelpedant said:

In Extended BASIC, there is no independent sprite pattern table.  There is a character pattern table which is also the sprite pattern table.  Thus, CALL PATTERN doesn't need to copy data from the character pattern table to set a sprite pattern.  It just needs to set the relevant character value in the sprite attribute table.  Or such is my understanding. 

 

TIB and XB, pretty much, set the VRAM address for each and every byte transferred to/from VRAM (v-e-e-e-r-r-y slow!). They do not take advantage of the VDP’s autoincrement feature for a block of reads/writes. As pointed out, changing the sprite character pattern # is much faster than redefining the pattern because only 1 byte needs to be transferred, whereas a new pattern needs 8 – 32 bytes (plus text-to-hex conversion), depending on magnification. Though the patterns obviously need to be loaded, they are presumably loaded ahead of time. Also, whether the character pattern and sprite pattern tables overlap or are coincident does not matter for the speed of changing the character #. If they are different tables, they need separate patterns, but that is something usually managed at the beginning of a program.

[RXB]

If you need the GPL Source Code from XB I can show it.

Mostly the slowdown is CALL CHAR(65,"FED12449563AB9463450AFDEC254656") every character in that string has to be checked for 0 to 9 and A to F

and if it finds a invalid character in string like say J or Y it errors out and reports it in XB.

After that check the string can be installed into VDP but remember that string just checked was also in VDP too thus double slows down the process.

So, to speed it up XB only checks a single chunk of 16 characters each time and has to re-assembly the string from Characters like 65 (an A) to a byte value A

Thus "AF" in the string has to converted to a single byte value >AF that goes into the VDP definition of that character and this all takes time.

Also when doing this it pads string that are less then 16 characters too with zeros.

I wrote an assembly version of it for RXB but for 4 character definition it did not result in much of a speed increase.

[Retrospect]

27 minutes ago, RXB said:

Mostly the slowdown is CALL CHAR(65,"FED12449563AB9463450AFDEC254656") every character in that string has to be checked for 0 to 9 and A to F

Thanks for the info, Rich.  I must say when I changed my code to use CALL PATTERN instead of constantly re-defining the CALL CHAR's , it was very quick compared.  
It seems insane to want to keep redefining using CALL CHAR, but at the time I was thinking, I can get more enemies on screen doing this, say for example , char 60 is the flying saucer and has seven different patterns constantly being defined to it, char 64 was a kind of tie-fighter with 4 patterns being defined to it .. and so on.  Of course, having the ability to have lots of enemies, all being redefined constantly, meant the TI had only one thing to do - slow down.  And it did. 

[+TheBF]

26 minutes ago, Retrospect said:

It seems insane to want to keep redefining using CALL CHAR, but at the time I was thinking, I can get more enemies on screen doing this, say for example , char 60 is the flying saucer and has seven different patterns constantly being defined to it, char 64 was a kind of tie-fighter with 4 patterns being defined to it .. and so on.  Of course, having the ability to have lots of enemies, all being redefined constantly, meant the TI had only one thing to do - slow down.  And it did. 

If you had access to VMBW, an assembly language routine, you could change patterns much quicker.

You could change the entire character set in tens of milli-seconds from what I measure.

I wonder if someone has a version you could link into your programs or if that is possible?

 

 

 

[Retrospect]

4 hours ago, TheBF said:

If you had access to VMBW, an assembly language routine, you could change patterns much quicker.

You could change the entire character set in tens of milli-seconds from what I measure.

I wonder if someone has a version you could link into your programs or if that is possible?

 

 

 

Thanks, but that won't be necessary now, I'm doing another re-write using call pattern.  It wasn't a wise move to think I could have like 8 animated sprites and all the missiles and the player ship too .... it was overkill!  So I wouldn't need to use call char anyhow.  

[Retrospect]

It's coming along nicely using CALL PATTERN ... I've done my re-write, I've got the player ship moving around on joystick, tilting up and down, firing, and I've managed to get a little enemy walking around and blasting at the player.  I'm pleased with the player and enemy explosions.  

 

I only really want a couple of enemies that fire on the screen at once anyhow, due to having to catch player and enemy missiles before they wrap round the screen.