Using a ball for added sprite detail

[LatchKeyKid]

I was playing around again with sprites for a game idea I've had for a while and was curious as to what the best way to use a ball along with a sprite for added detail would be in bB.   Basically, I have a warrior sprite and the ball would be the sword so that it could extend out beyond the traditional sprite size limitations during animations.   Each individual sprite animation would have at least one (sometimes more) ball configurations to go along with it to position the sword.   The best example I've seen of character animation (admittedly using ASM) was an incrediblely detailed Prince of Persia sprite animation posted decades ago on this forum which used a large table for the position of the sword.  In my case, my animation would be much more limited (a half dozen player sprite animations with another half dozen ball animations that when combined would be about a dozen individual poses).   Is a table (array? not sure on the terminology) the better way of arranging them for proper display or would individually in bB or instead custom positioning the ball with each variation depending on the exact player sprite animation being used?

[+splendidnut]

Unless you want the ball to appear straight vertically, you're going to need a table to do specify the position (HMOVE value) for each line at the very least.  As an example, your current avatar would need a table.

[LatchKeyKid]

Thanks for the reply and info (as well as pointing out that my avatar is indeed a description of what I'm referring to as I had forgotten about that!).    How would the addition of changing widths of the ball affect the situation?  That was another detail that I didn't think to include as in some cases the ball would be 1,2, or 4 pixels wide depending on the exact pose.   I have only one sprite planned where it would change within the same animation from scanline to scanline though that can be modified out if necessary though not preferable.

[+splendidnut]

If possible, I would avoid changing the ball width for every scanline, since that would require another TIA register update (CTRLPF) during the kernel.  That register also functions as playfield control, so that would also have to be taken into account.   It's probably better if the ball width is limited to being changed once per animation frame.  Unwanted ball pixels could potentially be masked with sprite pixels as long as you keep the playfield priority set as background (so that the ball is drawn behind the player).

[LatchKeyKid]

Thanks again.  Yeah, I've only got one single animation frame with a single change in width during it and, while preferable, it's not essential.   The rest of the changes would be between frames/poses.    In that type of table, would it be possible to have all the hmoves that correspond to each player sprite animation be on the same table in bB or would they have to be an individual table for each?

[+splendidnut]

A custom/customized kernel would be required to support what I've talked about here.  To the best of my knowledge, any of the built-in bB kernels only support the ball as a block shaped object that's one or two scanlines tall.

 

So, ultimately, the table structure would be dependent on the implementation of the kernel customizations.

[+Karl G]

Assuming that you are talking about bB without a custom kernel, you might not need to vary the width of the ball at all. If the ball object is drawn under the sprite, then the varying lengths could be handled by positioning alone, having some of it obscured under the player sprite to have different lengths extending from your player sprite (which also gives finer-grained control of the length).

 

If you do it this way, you could have two data tables, e.g. ball_offset_x and ball_offset_y, containing values that are added to e.g. the player0x and player0y coordinates to get the values that should go into ballx and bally for each pose. e.g.

 

 ballx = player0x + ball_offset_x[PoseNumber]

 

 

[LatchKeyKid]

4 hours ago, splendidnut said:

A custom/customized kernel would be required to support what I've talked about here.  To the best of my knowledge, any of the built-in bB kernels only support the ball as a block shaped object that's one or two scanlines tall.

 

So, ultimately, the table structure would be dependent on the implementation of the kernel customizations.

 

I hadn't considered bB not covering that situation in one of the kernels but thank you for bringing that up.   I was hoping to use the basic kernel and it looks like you can set a height according to this and it refers to the command as part of the general display loop so I assume you can change it each frame manually as opposed to things that are set in the kernel options.

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ball

[+splendidnut]

I just looked at the Standard Kernel and it looks like ballheight is a variable, so yes, you can change it on a frame by frame basis.

[LatchKeyKid]

4 hours ago, Karl G said:

Assuming that you are talking about bB without a custom kernel, you might not need to vary the width of the ball at all. If the ball object is drawn under the sprite, then the varying lengths could be handled by positioning alone, having some of it obscured under the player sprite to have different lengths extending from your player sprite (which also gives finer-grained control of the length).

 

If you do it this way, you could have two data tables, e.g. ball_offset_x and ball_offset_y, containing values that are added to e.g. the player0x and player0y coordinates to get the values that should go into ballx and bally for each pose. e.g.

 

 ballx = player0x + ball_offset_x[PoseNumber]

 

 

 

Thanks for the code!   In my case almost all of the pixels of the ball would NOT overlap the player sprite but rather be attached to the end of it and extend outward as I hope to use it as a weapon though that is the case in a few where it is broken up by the player sprite "hand" holding the ball "sword".

[+Karl G]

3 hours ago, LatchKeyKid said:

 

Thanks for the code!   In my case almost all of the pixels of the ball would NOT overlap the player sprite but rather be attached to the end of it and extend outward as I hope to use it as a weapon though that is the case in a few where it is broken up by the player sprite "hand" holding the ball "sword".

In that case, you may need another data table to store CTRLPF and/or ballheight values for each pose as well. A little more complicated, but still quite doable.