Subject: SPRITE question

From: Owen Brand <[email-masked]>
Date: Tue, 25 May 2010 09:35:16 -0400

When determining the location of a double sized SPRITE, am I correct  
in assuming that the actual location is returned as the top left pixel  
of the top left tile making up the 2x2 SPRITE?  I'm re-formatting my  
maps for my RPG to be able to handle double sized SPRITEs, and I want  
to make sure I am going "far enough".  Thanks

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: "kabldb" <[email-masked]>
Date: Tue, 25 May 2010 17:57:38 -0000

Yes, as far as XB is concerned. If you're using Assembler, then the top line is actually 255 (>FF), next line is 0 (>00), next is 1 (>01) etc. Horizontal positions are the same unless you're using early clock.

:-)

---

From: Owen Brand <[email-masked]>
Date: Tue, 25 May 2010 17:55:40 -0400

This is for an assembly project--- guess I should have specified.   
Take a look at my Beryl thread on Atariage--- I need to keep ol' Beryl  
on the path.  :). Ideas, sometimes?

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 25, 2010, at 1:57 PM, "kabldb" <[email-masked]> wrote:

> Yes, as far as XB is concerned. If you're using Assembler, then the  
> top line is actually 255 (>FF), next line is 0 (>00), next is 1  
> (>01) etc. Horizontal positions are the same unless you're using  
> early clock.
>
> :-)
>

---

From: "kabldb" <[email-masked]>
Date: Wed, 26 May 2010 07:54:54 -0000

So I guess your main character (Beryl) is a 16x16 pixel sprite. And I guess you would like to prevent Beryl from leaving your prearranged tracks. And I assume you're not moving him 8 pixels at a time horizontally and/or vertically.

Beryl will then sometimes cover 4 characters, sometimes he'll cover 6 characters, but most of the time (light statistics) he'll actually be hovering 9 characters.

By using the x and y position of the Beryl sprite, you can calculate the upper left screen location. I've done this before and you can effectively use the 9900 shift instructions. That's all about shifting bits left and right, adjusting and adding them together to get to the screen location holding the character. See EA manual page 194.

The x (horizontal) position of Beryl is something between 0 and 255. The top screen locations horizontally are between 0 and 31. So basically to get from one system to the other, we have to divide by 8 (256/32). That makes perfect sense since a character is 8 pixels wide.

Use the SRL (Shift Right Logical) to divide by 8. Remainer is lost.

SRL R1,>1 ;divides by 2,
SRL R1,>2 ;divides by 4,
SRL R1,>3 ;divides by 8,
SRL R1,>4 ;divides by 16 etc.

Try to get a sprite up on the screen. Try to move it left and right. Take the x position and calculate a horizontal screen location as explained above. Put something in that screen location. Now, when you move the sprite left and right, you'll see characters being filled according to the sprites x position. 

You'll notice that it works to pixel perfection when you move left. Everytime the sprite touches a new screen location (with whatever vertical position) the screen location will be filled.

Move right and you see that screen locations only fill when the x position of the sprite, and that's the pixel in the upper left corner of the sprite, is moving into a screen location.

The y (vertical) position of Beryl is much the same, though the first upper sprite position is not 0 but 255. Correct this by adding 1.

The Beryl y position is now something between 0 and 191. Screen location characters are 8 pixels both horizontally and vertically, so we have to divide by 8 again. Do the shift.

Now screen locations vertically are however 0, 32, 64, 96 etc. for the first column. We have to multiply by 32 to go to the correct line in the screen locations (knowing they are arranged as one long string of 768 characters). Use SLA (Shift Left Arithmetic) to multiply.

SLA R1,>1 ;multiply by 2,
SLA R1,>2 ;multiply by 4,
SLA R1,>3 ;multiply by 8,
SLA R1,>4 ;multiply by 16,
SLA R1,>5 ;multiply by 32 etc.

Next job is simply adding the previous calculated screen column with this new calculated screen row (line). You now know which screen location your Beryl is covering as far as the x and y position is concerned.

Since Beryl can cover 4, 6 or 9 characters, you have to make more checks. Either reuse the code already written, or use the screen location calculated.

The screen locations to check are just right and below this one calculated. To be pixel perfect you have to decide if it's 4, 6 (two versions - tall or wide) and 9 characters. A bit tricky. You have to check if the divisions by 8 were without remainers. No remainer means aligned with screen location positions. I think reusing the pixel check code is easier.

If the sprite were 8x8, you only had to check the corners. If you sprite is 16x16, you'll need to check the corners and 4 more points along each side of the sprite. Otherwise your Beryl sprite could have a one character bush or tree stump slide into his private parts.

Hope some of it makes sense.

:-)

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On May 25, 2010, at 1:57 PM, "kabldb" <kabldb@...> wrote:
> 
> > --- In [email-masked], Owen Brand <owenbrand@> wrote:
> > >

---

From: "kabldb" <[email-masked]>
Date: Wed, 26 May 2010 09:01:15 -0000

/quote

Oops. Having the value in the most significant byte of a register (after reading it from VDP maybe). Thus a value of 255 would become 0.

:-)  

--- In [email-masked], "kabldb" <kabldb@...> wrote:
> > On May 25, 2010, at 1:57 PM, "kabldb" <kabldb@> wrote:
> >

---

From: Owen Brand <[email-masked]>
Date: Wed, 26 May 2010 08:57:44 -0400

Thanks Karsten--- more than likely, I will have a scroller inside a  
15x15 window, so Beryl's actual screen position won't change--- the  
map will appear to change around him.  As you pointed out, it will be  
an 8 pixel at a time scroll, so technically pretty simple to  
accomplish.  Still a difficult one for ME, as I'm new to the  
language.  :) your explanation is very clear, thank you.  I imagine  
the same advice applies (with some conventional differences) to this  
particular set of circumstances, yes?

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 26, 2010, at 5:01 AM, "kabldb" <[email-masked]> wrote:

> /quote
> The y (vertical) position of Beryl is much the same, though the  
> first upper sprite position is not 0 but 255. Correct this by adding  
> 1.
>
> Oops. Having the value in the most significant byte of a register  
> (after reading it from VDP maybe). Thus a value of 255 would become 0.
>
> :-)
>
> > So I guess your main character (Beryl) is a 16x16 pixel sprite.  
> And I guess you would like to prevent Beryl from leaving your  
> prearranged tracks. And I assume you're not moving him 8 pixels at a  
> time horizontally and/or vertically.
> >
> > Beryl will then sometimes cover 4 characters, sometimes he'll  
> cover 6 characters, but most of the time (light statistics) he'll  
> actually be hovering 9 characters.
> >
> > By using the x and y position of the Beryl sprite, you can  
> calculate the upper left screen location. I've done this before and  
> you can effectively use the 9900 shift instructions. That's all  
> about shifting bits left and right, adjusting and adding them  
> together to get to the screen location holding the character. See EA  
> manual page 194.
> >
> > The x (horizontal) position of Beryl is something between 0 and  
> 255. The top screen locations horizontally are between 0 and 31. So  
> basically to get from one system to the other, we have to divide by  
> 8 (256/32). That makes perfect sense since a character is 8 pixels  
> wide.
> >
> > Try to get a sprite up on the screen. Try to move it left and  
> right. Take the x position and calculate a horizontal screen  
> location as explained above. Put something in that screen location.  
> Now, when you move the sprite left and right, you'll see characters  
> being filled according to the sprites x position.
> >
> > You'll notice that it works to pixel perfection when you move  
> left. Everytime the sprite touches a new screen location (with  
> whatever vertical position) the screen location will be filled.
> >
> > Move right and you see that screen locations only fill when the x  
> position of the sprite, and that's the pixel in the upper left  
> corner of the sprite, is moving into a screen location.
> >
> > The y (vertical) position of Beryl is much the same, though the  
> first upper sprite position is not 0 but 255. Correct this by adding  
> 1.
> >
> > The Beryl y position is now something between 0 and 191. Screen  
> location characters are 8 pixels both horizontally and vertically,  
> so we have to divide by 8 again. Do the shift.
> >
> > Now screen locations vertically are however 0, 32, 64, 96 etc. for  
> the first column. We have to multiply by 32 to go to the correct  
> line in the screen locations (knowing they are arranged as one long  
> string of 768 characters). Use SLA (Shift Left Arithmetic) to  
> multiply.
> >
> > Next job is simply adding the previous calculated screen column  
> with this new calculated screen row (line). You now know which  
> screen location your Beryl is covering as far as the x and y  
> position is concerned.
> >
> > Since Beryl can cover 4, 6 or 9 characters, you have to make more  
> checks. Either reuse the code already written, or use the screen  
> location calculated.
> >
> > The screen locations to check are just right and below this one  
> calculated. To be pixel perfect you have to decide if it's 4, 6 (two  
> versions - tall or wide) and 9 characters. A bit tricky. You have to  
> check if the divisions by 8 were without remainers. No remainer  
> means aligned with screen location positions. I think reusing the  
> pixel check code is easier.
> >
> > If the sprite were 8x8, you only had to check the corners. If you  
> sprite is 16x16, you'll need to check the corners and 4 more points  
> along each side of the sprite. Otherwise your Beryl sprite could  
> have a one character bush or tree stump slide into his private parts.
> >
> > > > > in assuming that the actual location is returned as the top  
> left
> > > > pixel
> > > > > maps for my RPG to be able to handle double sized SPRITEs,  
> and I
> > > > want

---

From: "kabldb" <[email-masked]>
Date: Wed, 26 May 2010 13:55:06 -0000

Oh ... - You could make Beryl 2x2 characters instead of a sprite (I know the background won't be underneath him). That would make collision detection much easier (that's character to character, not sprite to character).

:-)

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On May 26, 2010, at 5:01 AM, "kabldb" <kabldb@...> wrote:
> 
> > /quote
> > --- In [email-masked], "kabldb" <kabldb@> wrote:
> > >

---

From: Owen Brand <[email-masked]>
Date: Wed, 26 May 2010 10:37:16 -0400

Well--- that's true.  But since Beryl will be travelling over multiple  
terrains, I'll need to maintain the illusion of "moving over"  
backgrounds.  Plus, he will be a layered SPRITE, 2 colors.  Hmmmm....

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 26, 2010, at 9:55 AM, "kabldb" <[email-masked]> wrote:

> Oh ... - You could make Beryl 2x2 characters instead of a sprite (I  
> know the background won't be underneath him). That would make  
> collision detection much easier (that's character to character, not  
> sprite to character).
>
> :-)
>
> > > > > Take a look at my Beryl thread on Atariage--- I need to keep  
> ol'
> > > Beryl
> > > > > > > When determining the location of a double sized SPRITE,  
> am I
> > > correct

---

From: "Tursi" <[email-masked]>
Date: Wed, 26 May 2010 09:48:06 -0700

If Beryl never moves on the screen (ie: the map is always the part that 
moves), you could position his sprites at a known location corresponding to 
a character cell. Then you always know where to check for collisions, since 
it's always the same place. Unless I missed something?

--------------------------------------------------
From: "Owen Brand" <[email-masked]>
Sent: Wednesday, May 26, 2010 7:37 AM
To: <[email-masked]>
Subject: Re: [TI994A] Re: SPRITE question

---

From: "kabldb" <[email-masked]>
Date: Wed, 26 May 2010 17:02:33 -0000

So if Beryl's sprites are in a fixed position, then you always know which 4 screen locations he is at. If he tries to move up, then you have to check 2 screen locations above the 4, if he tries to move right, then it's the 2 screen locations to the right of the 4 etc. Assuming the world moves 8 pixels around him. That's probably about the easiest collision detection there is.

If Beryl's sprites occupied say line 7 and 8 and column 7 and 8, that's starting at screen location 6*32+6 = 198 or >C6. He also occupies location >C7, >E6 and >E7. It's relatively easy going one line down in hex. Add >20. >C6 becomes >E6.

If Beryl is trying to move up, you have to check location >A6 and >A7. If he tries an move right, you have to check location >C8 and >E8.

:-)

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On May 26, 2010, at 9:55 AM, "kabldb" <kabldb@...> wrote:
> 
> > > On May 26, 2010, at 5:01 AM, "kabldb" <kabldb@> wrote:
> > >
> > > > /quote

---

From: Owen Brand <[email-masked]>
Date: Wed, 26 May 2010 13:28:36 -0400

Tursi--- no you're not missing anything.... I'm the one missing a few  
marbles.  :)

Sometimes, this is how I thought about this as well--- but as far as I  
knew, SPRITE collision detection was dependant on a top left pixel  
basis... It did not strike me, however, that Beryl is completely  
stationary.  He is the only thing on the map that does not move!!  It  
is backwards from what I'm used to, so forgive my ignorance.  :)  
please take a look at the Beryl thread at Atariage to see the maps and  
such.. it'll give you an idea what my requirements are.  Thanks guys!

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 26, 2010, at 1:02 PM, "kabldb" <[email-masked]> wrote:

> So if Beryl's sprites are in a fixed position, then you always know  
> which 4 screen locations he is at. If he tries to move up, then you  
> have to check 2 screen locations above the 4, if he tries to move  
> right, then it's the 2 screen locations to the right of the 4 etc.  
> Assuming the world moves 8 pixels around him. That's probably about  
> the easiest collision detection there is.
>
> If Beryl's sprites occupied say line 7 and 8 and column 7 and 8,  
> that's starting at screen location 6*32+6 = 198 or >C6. He also  
> occupies location >C7, >E6 and >E7. It's relatively easy going one  
> line down in hex. Add >20. >C6 becomes >E6.
>
> If Beryl is trying to move up, you have to check location >A6 and  
> >A7. If he tries an move right, you have to check location >C8 and  
> >E8.
>
> :-)
>
> > > > > prearranged tracks. And I assume you're not moving him 8  
> pixels
> > > at a
> > > > > calculate the upper left screen location. I've done this  
> before
> > > and
> > > > > 255. The top screen locations horizontally are between 0 and  
> 31.
> > > So
> > > > > basically to get from one system to the other, we have to  
> divide
> > > by
> > > > > > Use the SRL (Shift Right Logical) to divide by 8. Remainer  
> is
> > > lost.
> > > > > >
> > > > > > SRL R1,>1 ;divides by 2,
> > > > > > SRL R1,>2 ;divides by 4,
> > > > > > SRL R1,>3 ;divides by 8,
> > > > > > Now screen locations vertically are however 0, 32, 64, 96  
> etc.
> > > for
> > > > > calculated. To be pixel perfect you have to decide if it's  
> 4, 6
> > > (two
> > > > > > If the sprite were 8x8, you only had to check the corners.  
> If
> > > you
> > > > > > > > Yes, as far as XB is concerned. If you're using  
> Assembler,
> > > > > then the
> > > > > > > > top line is actually 255 (>FF), next line is 0 (>00),  
> next
> > > is 1
> > > > > > > > (>01) etc. Horizontal positions are the same unless  
> you're
> > > using
> > > > > > > > early clock.
> > > > > > > >
> > > > > > > > :-)
> > > > > > > >
> > > > > > > > > in assuming that the actual location is returned as  
> the
> > > top
> > > > > left
> > > > > > > > pixel

---

From: tursi <[email-masked]>
Date: Wed, 26 May 2010 10:45:57 -0700 (PDT)

> stationary.  He is the only thing on the map that does not move!!  It is 
> backwards from what I'm used to, so forgive my ignorance.  :) please 
> take a look at the Beryl thread at Atariage to see the maps and such.. 
> it'll give you an idea what my requirements are.  Thanks guys! 

I've seen the maps, nice work! I saved off a copy of the lava world the 
other day (I like multi-screen video game maps. ;) Good page for them at 
http://www.vgmaps.com/ ;) )

---

From: Owen Brand <[email-masked]>
Date: Wed, 26 May 2010 16:06:22 -0400

Thanks... :) I have since created a modified world map which will  
facilitate my double sized (2x2) SPRITEs.  Before, I was using  
single   tiles for my paths, which could only handle a character of a  
single tile width.  1x1,1x2, etc.  Thanks for looking... And if you're  
interested, I posted the .mag Magellan file to the thread.  Map #7 is  
the new improved updated map.  :) you can open it in the new release  
of Magellan and take a look or make modifications or whatever.  :)  
it's fun to play with, anyway.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com