CALL PATTERN vs. CALL CHAR (data)

[Opry99er]

As the title of this thread suggests, I'm dealing with a character pattern issue... Here are my issues:

 

I'm needing to re-define 4 SPRITEs during gameplay each time an opposite "direction" is pressed by the user... Additionally, the patterns will also have alternate definitions to shift during a thread.

 

Essentially, this can be broken down into two different questions, each of which MAY have a different solution.

 

1) If the PC is facing left, the 4 SPRITEs will have patterns A,B,C,D---- if the PC is facing right, the SPRITEs will have patterns E,F,G,H.

 

2) During the game loop, the left-facing collection of 4 SPRITEs will change their patterns back and forth (from A to B)

During the game loop, the right facing collection of 4 SPRITEs will change their patterns back and forth (from C to D)

 

(please note that the "A,B,C,D" in the first question have no relation the the ABCD in the second question)

 

 

To clarify: This would take 16 characters... 4 characterss for left facing "A", 4 characters for left facing "B".... 4 characters for right facing "A", and 4 characters for right facing "B"

 

 

So, all that was to ask the following question:

 

 

"Would it be faster/better/more efficient to take up 2 character sets and simply use "CALL PATTERN" for each of the SPRITEs, or to actually do CALL CHAR(96,PAT2) and re-define the same 4 or 8 characters over and over? I HAVE the character set space available to do all 16 patterns and use CALL PATTERN to re-define the SPRITEs, but it would wipe out every available character I have. But if it's faster, I'd be willing to sacrifice all of it for this purpose.

 

Perhaps using CALL PATTERN for the threaded A-B shift would be best, but CALL CHAR might be best when swapping between right and left... This way, I'd only use 8 characters total and only re-define the characters when swapping from left to right or vice versa...

 

I tested this in Classic99 with a simple program, but it's not within the actual game loop in which this routine will be placed, so the speed difference isn't noticeable. Is there a theoretical reason to believe one would be preferable over another, or will it just take doing both and testing... The CALL CHAR method would take quite a bit of time to put together, whereas the CALL PATTERN would be easy to write... but that isn't really indicative as to which is "faster"... Any help you guys can offer (philosophical or otherwise) would be appreciated. =)

 

P.S. Sorry for the length of this post... I had to lay out the actual issues to make it understandable and not abstract. Thanks!

Edited March 10, 2011 by Opry99er

[rocky007]

I think it will be more fast with PATTERN. Pattern just set 1 byte / sprite, CHAR set 8 bytes.

But as you told, you have economy of character redefining the same char for the different position.

( it's what i did for my game Octopus )

[Bones-69]

Using CHAR will likely have a noticable effect on the sprite. CHAR really does seem to draw at a speed the eye can notice. For best results you probably should have a buffer set of 8 characters where you can redefine the next possible change of player direction and pre-define it before it needs to be displayed, then use PATTERN when the sprite needs to be changed. But, I do appreciate the limited characters we have at our BASIC fingertips and know that doing this often comes at a graphical disadvantage somewhere. Would have been great if TI gave us another 16 colour sets to play with!

 

In regards to using CHAR for the character change if you have no choice but to go this way, I would load each new character into a string which is 64 characters in length and then call this value from an array which is linked to the program variables. So say you have CALL KEY(0,A,B) and press the left arrow key, which would set A value at 8, perahps in this instance you could then CALL CHAR(128,A$(A)).... Or something similar that suits your circumstance.

[+OLD CS1]

What he said. Also, if you are planing to compile the final release I think the issue is moot.

 

Yes, unhelpful post, but I have often pondered the same question myself. And I have been disappointed with the speed at which CHAR literally draws character definitions. When I was learning assembly with my Mini Memory, I had quite a few routines which were written to overcome speed issues with character definitions and screen drawing, etc.

[Opry99er]

It's for Beryl Reichardt... So, no freaking chance I'm compiling this baby.

[sometimes99er]

It's for Beryl Reichardt... So, no freaking chance I'm compiling this baby.

I understand that your PC (player characters) will animate as it goes along. During gameplay you will want to use CALL PATTERN. CALL CHAR will slow it down way to much.

 

[Opry99er]

Thanks... I think I'd come to that conclusion, but its nice to have confirmation. . I saw you posted to the beryl thread--- so I'll pop over there and see what you had to say.

[Opry99er]

Tested a simple KSCAN loop using both methods. In XB, CALL CHAR does have a noticeable effect on the SPRITE... In my initial testing, I only used a single character to test... In the most recent test, I used 4 (as per my needs)--- this broke the camel's back. PATTERN it is. Thanks for your help and suggestions, guys.

[Bones-69]

One thing I have noticed is how using CHAR can be minimised depending on what characters are changed. For example;

 

AC

BD

 

Say this is a character running right. If the character is designed in a way where characters A&C don't change (maybe they are the head and shoulders), but B or D (maybe both) change to represent the legs running, then the re-draw effect using CHAR is highly reduced. If sprites can be designed so only 1 or 2 characters need to be changed for animation then you can sometimes get away with using CHAR at no great disadvantage. For complicated sprites this doesn't help much but I thought it worth the mention.

 

100 CALL CLEAR :: CALL MAGNIFY(4):: CALL SCREEN(2)
110 A$="0000003F0007073F408098988080807F0000F09090F0F0FC022121F9212101FE"
120 B$="0000003F0007073F408098988080807F0000F09090F0F0FC0211A171294101FE"
130 C$="0000003F0007073F408098988080807F0000F09090F0F0FC0211D121594101FE"
140 D$="0000003F0007073F408098988080807F0000F09090F0F0FC02895121518901FE"
150 CALL SPRITE(#1,128,14,100,100,0,-6)
160 CALL CHAR(128,A$,128,B$,128,C$,128,D$):: GOTO 160

[+OLD CS1]

One thing I have noticed is how using CHAR can be minimised depending on what characters are changed. For example;

 

AC

BD

 

Say this is a character running right. If the character is designed in a way where characters A&C don't change (maybe they are the head and shoulders), but B or D (maybe both) change to represent the legs running, then the re-draw effect using CHAR is highly reduced. If sprites can be designed so only 1 or 2 characters need to be changed for animation then you can sometimes get away with using CHAR at no great disadvantage. For complicated sprites this doesn't help much but I thought it worth the mention.

 

For that matter, you could save a lot of time by simply re-defining only the character which changes, in this case 131. Animation now happens much more quickly, maybe a little too quickly for this example. (Neat graphic, BTW.)

 

100 CALL CLEAR :: CALL MAGNIFY(4):: CALL SCREEN(2)
105 X$="0000003F0007073F408098988080807F0000F09090F0F0FC"
110 A$="022121F9212101FE"
120 B$="0211A171294101FE"
130 C$="0211D121594101FE"
140 D$="02895121518901FE"
150 CALL SPRITE(#1,128,14,100,100,0,-6)
155 CALL CHAR(128,X$&A$)
160 CALL CHAR(131,A$,131,B$,131,C$,131,D$):: GOTO 160

[unhuman]

If you're animating multiple, identical objects, char can be advantageous. I used this technique in Inaccurate Invaders to animate all the aliens (of a particular type) at the same time (they were single characters, not sprites).

 

Alternatively, in your game loop, you could must decide which one (of the 4) to animate - so they differ an animate more slowly, but this will reduce the function call overhead.

 

Also, you might be able to only alter just one or 2 of the characters in the sprite instead of the entire char. I recall at some point in my TI history I wrote a game with a guy running, and I only moved his foot, or something like that.

 

Alternatively again (but building on the call char idea) - you could just update 1/4 of the character in each loop - which would minimize the call char expense (1 char versus 4) and - perhaps - give an interesting animated effect.

Edited March 13, 2011 by unhuman

[+RXB]

You know characters in the upper range shift all the time so some tricks that were used by some programmers was to find one that changes all the time and just put it into that char spot, as the Pixels take a second to refresh the open spaces are very hard to see next to all the closed spaces so it still give the illusion of movement.

Example:

10 FOR X=0 TO 256::PRINT CHR$(X);

20 NEXT X

30 GOTO 30

 

You will notice the characters moving all the time as they are just VDP addresses being used by the GPL/OS and as such keep changing in a loop. So if you CALL POKEV(CB,8A) to change the Address VDP Table some very cool stuff can be done.

CB would be Character table addres of the character plus the Byte you want to change.

 

Or a more simple method is:

Example:

Say the character table is at >0380 and the character is at >0395 plus the 16 byte definition byte is number 8 so that would be >0395 + 8 = >039D or in Decimal 925

thus a loop would be like just this one call to get character motion CALL POKEV(925,121) at one line and later another would be CALL POKEV(925,185) in the loop, this would be the motion.

The character definition of that character is "8ABE4C879F456287" the eighth byte is a "79" and you want it to be a "B9" so you will be changing it from 7 to B thus CALL POKEV(925,121) or CALL POKE(925,185)

 

This is just an example but you can see a POKE VPD would be 10 times faster then CALL CHAR or CALL CHARPAT as only a single byte is moved into VDP vs the other way requires more processor power used to fetch more bytes and convert them each loop.

[Opry99er]

Hey RXB.... Unfortunately TI XB doesn't offer POKEV and the character sets are limited to 14. POKEV is pretty much limited to TI BASIC+Minimem and.... Your XB uses it correct?? It's a fine language.... We should just see to it that a good number of carts get built and distributed. Then more folks would develop with it--- I'm sure I would!!!

[+RXB]

Hey RXB.... Unfortunately TI XB doesn't offer POKEV and the character sets are limited to 14. POKEV is pretty much limited to TI BASIC+Minimem and.... Your XB uses it correct?? It's a fine language.... We should just see to it that a good number of carts get built and distributed. Then more folks would develop with it--- I'm sure I would!!!

 

 

Yea RXB is free not asking anything for it since 1999 made it Freeware. If I can get my PGRAMs repaired then you will see some new versions come out. RXB 2001 had some errors I corrected.

[Opry99er]

Would you post a new thread containing a download of the current version's binaries and perhaps a downloadable manual? It would be a great way to bring renewed interest in this software which is really underused in the community.... I'd love to see some more excitement generated around this XB--- perhaps we could do a community run of 20-30 carts so we could all share in the benefits.

[Bones-69]

Is getting RXB into Classic 99 an option?

 

As much as I love the old hardware, I don't have the desk real estate to ever contemplate going back to a real TI system....

[unhuman]

Yup sounds great just not sure how I can use it as well as what's going to be really sharable out of what I create

[Opry99er]

RXB is clocked faster than TIXB (from what I've heard), just not sure how much faster. Perhaps Rich can provide us with some benchmark results?

[+RXB]

RXB is clocked faster than TIXB (from what I've heard), just not sure how much faster. Perhaps Rich can provide us with some benchmark results?

 

Depends on the commands you use.

Example:

CALL COINC(#sprite,#sprite,tolerance,numericvarible) in XB requires a seperate call each time so you use :: alot that slows down the program.

RXB lets you use a comma after the numericvarible so you can avoid the :: separator command and that speeds up XB.

The commands speeded up are:

COINC

DISTANCE

GCHAR

HCHAR

VCHAR

JOYST

KEY

 

These are the guts of most programs in XB. With KEY and JOYST being used the most.

 

Size of the programs is the other XB problem bigger is slower.

780 CALL KEY(0,K,S) :: IF S=0 THEN 780 ! This is normal XB

 

780 CALL KEY("",O,K,S) ! This is RXB the IF S=0 THEN is built into RXB.

 

Or.

 

780 CALL KEY(0,K,S) :: IF K=89 THEN 2050 ELSE 780 ! This is normal XB

 

780 CALL KEY("N",0,K,S) :: GOTO 2050 ! This is RXB

 

I have thought about making a version of CALL KEYGOTO("N",0,K,S,linenumber) but missed keys could be a problem in emulators.

Edited March 14, 2011 by RXB

[Bones-69]

I have thought about making a version of CALL KEYGOTO("N",0,K,S,linenumber) but missed keys could be a problem in emulators.

That sounds very useful. I have also wanted to be able to GOTO A, or GOSUB A(n), or anything that makes a good work-around for the whole ON GOTO or ON GOSUB alternatives.