some fade in from left to right & wip

[+hloberg]

1st off i'm sure you can guess what game this is working toward. I'm building it with @senior_falcon XB256

my question is there a way to smoothly have to sprites slide in from the left and smoothly slide off from the right. as of now the sprites pop into existence on the left then slide off on the right. using EARLY CLOCK just swaps how right and left work. 

my guess is not, but i thought i would ask. 

PS 1 idea I thought of was use XB256 characters scrolling but due to several issues I not ready to go there yet.

M10-X M10

[Asmusr]

5 hours ago, hloberg said:

my question is there a way to smoothly have to sprites slide in from the left and smoothly slide off from the right. as of now the sprites pop into existence on the left then slide off on the right. using EARLY CLOCK just swaps how right and left work. 

Sure, but you need a check: if the x coordinate is negative, set the early clock bit and add 32 to the x coordinate. I don't think this would work with auto-motion.

[Retrospect]

5 hours ago, hloberg said:

is there a way to smoothly have to sprites slide in from the left and smoothly slide off from the right.

I think I was once told that , if for example you want the sprite to appear at the left, but smoothly, you could set the sprite's coordinate like this : x = -16 . So it's 16 pixels out of screen. It was mentioned this wouldn't work in testing in XB but would be okay with the compiler.  I never checked it.  So for the building of the game just set it to 1 as normal, but for the final compile, (if it works) set it to -16   

[Reciprocating Bill]

I wonder - since the early clock is set individually for each sprite, you could have a sprite with the appropriate early clock slide in from left, then, once it is fully visible, substitute an identical sprite at adjusted coordinates with it's early clock set for a smooth exit on the right and have it continue the journey.  

[+OLD CS1]

4 hours ago, Reciprocating Bill said:

I wonder - since the early clock is set individually for each sprite, you could have a sprite with the appropriate early clock slide in from left, then, once it is fully visible, substitute an identical sprite at adjusted coordinates with it's early clock set for a smooth exit on the right and have it continue the journey.  

I can see this working.  Is there any reason not to just update the existing sprite's early clock and x-position at the same time?

[senior_falcon]

I will have a short demo program for you soon, but in testing it, I found that CALL LINK("EARLYC",X) does not work properly in the compiler. I don't see how the code I wrote makes any sense.

So I will study that until I have an answer, and then will post it.

There is another way to do it that works fine compiled, but I want both ways to work.

[senior_falcon]

Here is a short program that shows what you want to do. The video shows it first running in XB and you will see a slight flicker when the sprite wraps around. The compiled version does not do this.

A revised version of RUNTIME4 is below the program. This has the proper code for EARLYC.

The previous version had an older version of EARLYC that combined the sprite number and the sprite color. That is not done in XB256 and now the compiled version matches that behavior.

 

5 CALL MAGNIFY(4)
6 ECO=0
10 CALL SPRITE(#1,65,16,100,100,0,5)
20 CALL POSITION(#1,X,Y)
40 IF Y<2 AND ECO=0 THEN CALL LINK("EARLYC",1):: ECO=1 :: GOTO 20
50 IF Y>33 AND ECO=1 THEN CALL LOCATE(#1,X,Y-32):: ECO=0 :: CALL COLOR(#1,16):: GOTO 20
60 GOTO 20

 

(Edit) In line 50, the CALL COLOR(#1,16)  is there to turn off the sprite early clock.

 

In code that will be compiled, there is another way to turn the early clock on/off.

There is no limit check on CALL COLOR, so if you add 144 to the color it will turn the early clock on. According to the E/A manual it only needs to be 128, but my notes say it must be 144 to work in Win99/4a, and that change seems to cause no problems on other simulators.

CALL COLOR(#1,160) !early clock on

CALL COLOR(#1,16) !early clock off

 

RUNTIME4.TXT

 

 

 

 

Edited September 5, 2023 by senior_falcon

[+hloberg]

thanks @senior_falcon looks like what I exactly need! I'll play with it this weekend.

[Asmusr]

17 hours ago, senior_falcon said:

There is no limit check on CALL COLOR, so if you add 144 to the color it will turn the early clock on. According to the E/A manual it only needs to be 128, but my notes say it must be 144 to work in Win99/4a, and that change seems to cause no problems on other simulators.

Just for the record, on real hardware and emulators, setting bit 3 (bit value 16) has no effect. 🙂

 

Edited September 5, 2023 by Asmusr

[+FarmerPotato]

On 9/4/2023 at 5:19 PM, senior_falcon said:

 

In code that will be compiled, there is another way to turn the early clock on/off.

There is no limit check on CALL COLOR, so if you add 144 to the color it will turn the early clock on. According to the E/A manual it only needs to be 128, but my notes say it must be 144 to work in Win99/4a, and that change seems to cause no problems on other simulators.

CALL COLOR(#1,160) !early clock on

CALL COLOR(#1,16)

!early clock off

144 makes sense if you consider that XB color codes start at 1 whereas the actual color codes go 0-15.
 

So subtracting 1 will transform:

 

144 or >90 into >8F. 

128 or >80 into >7F. No early clock.

In each case you get color white?

 

Maybe you want 128 plus 1 to 16. 

 

Aside: in assembly language, I've used 16 bit "world" sprite coordinates.  Test for visibility by comparing to  screen origin X-16, then X+256.  (Can be optimized.) Re-implementing auto-motion for all "sprites". 

 

[Asmusr]

7 minutes ago, FarmerPotato said:

144 makes sense if you consider that XB color codes start at 1 whereas the actual color codes go 0-15.

Ahh, yes that makes sense. 

[senior_falcon]

"The four most-significant bits in the fourth byte control the early clock of the sprite. If the last of these four bits is 0, the early clock is off. Then the sprite's location is its upper left^iand comer, and it fades in and out on the right edge of the screen. If the last of these four bits is 1, the early clock is on. Then the sprite's location is shifted 32 pixels to the lefti allowing it to fade in and out on the left edge of the screen"

 

Above is what the E/A manual says. In my code I read the color byte, then ORI R1,>9000 and then write it back to the VDP. This does not accord with the E/A manual. My notes say this is necessary for compatibility with Win994a. It does set the last of the four most significant bits, as the E/A manual says,  but it also sets the first. It doesn't seem to cause any problems.

[+FarmerPotato]

@Asmusr @senior_falcon
 

I consulted the TMS9918 programming manual just now--it's definitely the >80 bit with the other three unused. 
 

https://map.grauw.nl/resources/video/ti-vdp-programmers-guide.pdf

 

I never saw this book until recently. Has the "undocumented" modes not in the 9918/28/29 Data Book. 
 

V9938 didn't use the other bits either. 

[senior_falcon]

6 hours ago, senior_falcon said:

"The four most-significant bits in the fourth byte control the early clock of the sprite. If the last of these four bits is 0, the early clock is off. Then the sprite's location is its upper left hand corner, and it fades in and out on the right edge of the screen. If the last of these four bits is 1, the early clock is on. Then the sprite's location is shifted 32 pixels to the left allowing it to fade in and out on the left edge of the screen"

10 hours ago, Asmusr said:

Just for the record, on real hardware and emulators, setting bit 3 (bit value 16) has no effect. 🙂

I would understand that bit 0 is the first of the four most significant bits, and bit 3 is the last. Is that correct, or am I thinking in reverse?

 

(Edit) Below is from the 9918 VDP guide. Unlike the description in the E/A manual, here there is no ambiguity as to which bit should be set.

 

"The fourth byte in the Sprite Attribute Table entry performs two functions. The lower four bits(nibble) define the sprite color, which can be any of the 16 available VDP colors. The MSB is the Early Clock bit, which shifts the horizontal position of the sprite to the left 32 pixels (whenset high). The remaining three bits are unused and should be set to 0."

Edited September 6, 2023 by senior_falcon

[Asmusr]

17 hours ago, senior_falcon said:

I would understand that bit 0 is the first of the four most significant bits, and bit 3 is the last. Is that correct, or am I thinking in reverse?

 

(Edit) Below is from the 9918 VDP guide. Unlike the description in the E/A manual, here there is no ambiguity as to which bit should be set.

 

"The fourth byte in the Sprite Attribute Table entry performs two functions. The lower four bits(nibble) define the sprite color, which can be any of the 16 available VDP colors. The MSB is the Early Clock bit, which shifts the horizontal position of the sprite to the left 32 pixels (whenset high). The remaining three bits are unused and should be set to 0."

Yes that's correct, bit 0 (value 128) is the early clock bit. But when you set the byte you also need to set the color of the sprite, or it would become invisible (color 0). And, as FarmerPotato explained, in XB colors have base 1, so 128 + 15 (white) + 1 (XB base) = 144, which is why this value must be used to set the early clock for a white sprite using CALL COLOR. I don't think that's particular to Win99/4a, which is what confused me.

[senior_falcon]

With a tiny change to the code, I can make the early clock toggle between off and on.

CALL LINK("EARLYC",1) would turn on the early clock for sprite #1

CALL LINK("EARLYC",1) a second time would turn it off.

Of course, then you must keep track of the early clock's status to be sure it does what you want.

Would this be a useful addition? Or is it confusing?

 

[+hloberg]

On 9/10/2023 at 4:36 PM, senior_falcon said:

With a tiny change to the code, I can make the early clock toggle between off and on.

CALL LINK("EARLYC",1) would turn on the early clock for sprite #1

CALL LINK("EARLYC",1) a second time would turn it off.

Of course, then you must keep track of the early clock's status to be sure it does what you want.

Would this be a useful addition? Or is it confusing?

 

thanks for looking into this, might help, but, I have moved on to using character graphics for the bad guy ships instead of sprites for a couple reasons:1. Megamania had 5 characters in line not 4, the TI99 max. 2. i have 12 sprites that need to be taken care of with turning the EARLYC on and off in rapid order. even with tight code & compiled some were skipping.

so i found just creating a window & using character scroll looks really good. haven't yet tested shot detection but I think I can just use GCHAR with the shot to detect the character bad guy ship. should work.

only problem I have is one of the screens the ships go in different directions, thus:

> > > > > >

< < < < < <

> > > > > >

it doesn't look like your scrolling can do that. if it can't I plan to just ignore that screen & make some form of substitute.