Using Ball/Missile Sprites for added color?

[LatchKeyKid]

I asked this a while ago on a different platform and didn't get an answer but I was curious as to why more games (whether official back in the day or homebrew now) don't use the missile/ball sprites for added color.  At the time, it was a theoretical question for me as I wasn't aware of a game that did but I recently found one that does, Snoopy and the Red Baron).

 

Is there a hidden complication that prevents the use like the tracking of the added sprite (ball in this case) taking up too many CPU cycles?  I now know that various kernels disable aspects of programming in order to make multicolor player sprites like the one below and also that the ball and missile colors are intrinsically tied to the playfield and respective players.  Assuming that you're not disabling them in the kernel or using them for something else, is it just not worth the effort for a splash of color like Snoopy's nose and spots for most programmers?  I personally think it adds alot but as an admitted programming n00b I fully admit that I'm potentially unaware of the cost of tracking the second sprite alongside the player.

[+splendidnut]

33 minutes ago, LatchKeyKid said:

Is there a hidden complication that prevents the use like the tracking of the added sprite (ball in this case) taking up too many CPU cycles?

Yup.  As seen in the image you attached, that ball is resized, repositioning, and enabled/disabled... That's potentially 4 TIA registers that have to be hit or changed within a scanline with the repositioning needing 2 registers manipulated (min of 1/max of 3 registers depending on the situation).  The TIA registers also need to be hit or changed at appropriate times within that line as to minimize display glitches.

 

39 minutes ago, LatchKeyKid said:

Assuming that you're not disabling them in the kernel or using them for something else, is it just not worth the effort for a splash of color like Snoopy's nose and spots for most programmers?

All depends on the situation.

[+littaum]

In addition to CPU cycles, the ball also takes the color of whatever the playfield color is (there's some trickery that can be done when playfield is in score mode, but it's not very clean).  

 

Halo 2600 uses the ball for the Master Chief face mask, at the cost of having the boundaries be the same color - see below:

 

 

[LatchKeyKid]

2 hours ago, splendidnut said:

Yup.  As seen in the image you attached, that ball is resized, repositioning, and enabled/disabled... That's potentially 4 TIA registers that have to be hit or changed within a scanline with the repositioning needing 2 registers manipulated (min of 1/max of 3 registers depending on the situation).  The TIA registers also need to be hit or changed at appropriate times within that line as to minimize display glitches.

 

All depends on the situation.

Can some of those be done ahead of time when time allows (specifically setting the size for example)?  I don't know if that single change helps for example if you're only planning on keeping it a certain size and then moving it hidden under the prioritized player sprite visible under gaps.  I'll have to rewatch the video on drawing sprites and the CPU cycles to see if you can overlap them as I'm hoping.  Basically, I'd want to make something like my profile pic here with a mono-color player sprite and another color ball sprite moving along with it at all times.

[LatchKeyKid]

3 hours ago, littaum said:

In addition to CPU cycles, the ball also takes the color of whatever the playfield color is (there's some trickery that can be done when playfield is in score mode, but it's not very clean).  

 

Halo 2600 uses the ball for the Master Chief face mask, at the cost of having the boundaries be the same color - see below:

 

 

 

Thanks!  I was aware of the color matching and mentioned it above but I definitely didn't know the unofficial Halo port used the technique.  It's always good to have another example to refer to other than just Snoopy.

[+splendidnut]

7 hours ago, LatchKeyKid said:

Can some of those be done ahead of time when time allows (specifically setting the size for example)?  I don't know if that single change helps for example if you're only planning on keeping it a certain size and then moving it hidden under the prioritized player sprite visible under gaps.

Sure, I was basing my answer off the snoopy image you provided.  If you only need the ball to be a single size, you can set that ahead of time.

 

For your profile image, if you plan on using the ball, you would still need to enable/disable (ENABL), and resposition (HMBL + HMOVE).  You could "hide" the ball underneath the player sprite head, in which you'd only have to enable it at the top of your sprite and disable it at the bottom.  The easiest way to handle that would be to have 3 separate kernels (above player, draw player, below player)... which would let you reuse that sprite for other things.

[LatchKeyKid]

1 hour ago, splendidnut said:

Sure, I was basing my answer off the snoopy image you provided.  If you only need the ball to be a single size, you can set that ahead of time.

 

For your profile image, if you plan on using the ball, you would still need to enable/disable (ENABL), and resposition (HMBL + HMOVE).  You could "hide" the ball underneath the player sprite head, in which you'd only have to enable it at the top of your sprite and disable it at the bottom.  The easiest way to handle that would be to have 3 separate kernels (above player, draw player, below player)... which would let you reuse that sprite for other things.

No worries.  I didn't mention my profile pic initially as it's currently a pipe dream at the moment and not actually programmed (just drawn in a sprite maker with the 2600 in mind).  I've got two game ideas in mind and both of the main characters use this technique of shifting a constant size partially hidden ball for a bit more color without hopefully losing access to the missile sprite for the player as a bB tradeoff.  I don't know yet (and may never know) if it's a feasible/realistic option but that's the idea for now.  Thank you regardless for the info!

 

Regarding the separate kernels, I saw that Pitfall (my only practical experience with 2600 was my recent hack of it) uses that technique.  When you're making trade offs like at the link below for added color, those are done individually for each zone kernel, correct?

 

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

 

As in, above the player you can have single color sprites but all the missiles enabled for added color (like stars in the night sky for example) but then change it to missiles disabled for the zone where the player sprite is for added color?  And then maybe some other variation below?  You'd obviously have to code in those changes and hopefully they'd fit within the CPU cycle limit but I'm hoping that the two line kernel might have the room for that on the one line but admittedly I have no real knowledge of how many free cycles there are in each line of the two line bB code (and that clearly also depends on the enemy sprite and other code).

[+splendidnut]

Yes, Pitfall is a good example of using multiple kernels to do different things for each zone.  Sega's CongoBongo is also another example: the rock staircase/waterfall screen makes extensive use of that technique.

 

If you're specifically looking at doing things in bBasic, I believe your options are going to be limited since the prepackaged kernels are designed to accomplish general use-cases in a somewhat flexible way and to be easy to use.  I believe you can only one use kernel (or set of kernel options) per screen.  Anything beyond that is probably going to need customization of the kernel ASM code to accomplish.

 

My general suggestion is to get your game working first within the "standard" constraints of one of those kernels... then work on improving it with things like "shifting ball" detail later on, since that will require customization of the kernel ASM code to accomplish.

[+Gemintronic]

Speaking of batariBASIC it is possible to combine resources for more colorful sprites.  In this case the playfield is the flesh color in the chef sprite.  Trouble is: you really need to design your game around complicated tricks like this.  On the 2600 there's always a tradeoff.

 

[LatchKeyKid]

On 6/23/2022 at 12:00 PM, splendidnut said:

If you're specifically looking at doing things in bBasic, I believe your options are going to be limited since the prepackaged kernels are designed to accomplish general use-cases in a somewhat flexible way and to be easy to use.  I believe you can only one use kernel (or set of kernel options) per screen.  Anything beyond that is probably going to need customization of the kernel ASM code to accomplish.

 

My general suggestion is to get your game working first within the "standard" constraints of one of those kernels... then work on improving it with things like "shifting ball" detail later on, since that will require customization of the kernel ASM code to accomplish.

Thanks again.  I agree (especially given my lack of knowledge/experience) that would be a better starting point for sure.  Are you familiar with DPC+ as well?   Is that also subject to the same limitations (i.e. you lose the missile sprites to get multicolor player sprites)?

 

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

 

It seems like further down you specify color line by line and it still references missiles.

[Sohl]

@LatchKeyKid, @splendidnut, great discussion!  In my Immunity game I'm working on, in some cases I just use two player graphics on top of each other to render a virus sprite, but in other cases I use flicker or changing color per line for one sprite. I even used the playfield bitmap and color to fill in part of my viruses in a non-play portion of one screen to save a player graphic, probably similar to what @Gemintronic mentioned.  In this crop, the white virus bodies are playfield and square, but the overlaid spike proteins sort of hide that and make them seem more rounded, but I can more easily do this here because in this screen, the upper three viruses don't move:
 

 

In general, using the ball is the most flexible, but you either need to design your playfield and sprites to work together properly, or need to actively control the playfield color in tight timing constraints.  Using missiles for extra color is not very flexible, but if your sprites have inverted colors relative each other, it could work.  (e.g. Spy-versus-Spy games based on the Mad Magazine cartoon).  You'd use Missile 1 with Player 0, and Missile 0 with Player 1.   

 

One of my future game ideas will probably use layered player graphic spites with a solid-color silhouette and a color-per-line upper layer, but I will flicker the upper layer between a player and an enemy or other special object as needed.  I'm using asm, not bB, so I can try to be more optimized for my particular approach.  I do want to set up my data better for efficient use in future drawing kernels so the kernels can be more streamlined and efficient.  The kernels in Immunity have been a bit maddening at times to get working correctly and I had to do a lot of rework to make the RAM use somewhat more efficient.

 

 

[LatchKeyKid]

1 hour ago, Sohl said:

@LatchKeyKid, @splendidnut, great discussion!  In my Immunity game I'm working on, in some cases I just use two player graphics on top of each other to render a virus sprite, but in other cases I use flicker or changing color per line for one sprite. I even used the playfield bitmap and color to fill in part of my viruses in a non-play portion of one screen to save a player graphic, probably similar to what @Gemintronic mentioned.  In this crop, the white virus bodies are playfield and square, but the overlaid spike proteins sort of hide that and make them seem more rounded, but I can more easily do this here because in this screen, the upper three viruses don't move:
 

 

In general, using the ball is the most flexible, but you either need to design your playfield and sprites to work together properly, or need to actively control the playfield color in tight timing constraints.  Using missiles for extra color is not very flexible, but if your sprites have inverted colors relative each other, it could work.  (e.g. Spy-versus-Spy games based on the Mad Magazine cartoon).  You'd use Missile 1 with Player 0, and Missile 0 with Player 1.   

 

 

Thanks for the info.  When you're using both player sprites for the player, does that mean that none of the enemy/NPC sprites will ever appear on the same scanline with the player then without using flicker like the various multisprite and DPC+ demos?  I'm completely new to all this so I'm starting from scratch and it seems from the 8blit youtube channel videos that you barely have enough CPU cycles to control the two player sprites in the same line hence the frequent doubling up.  As someone without the personal experience, I keep wondering if I'll have enough cycles to control/modify everything needed.  I figure in a two line kernel that the actual player sprites will be on one line and the other will be maybe the ball, a single missile, and the playfield when necessary.  I actually prefer the square doubled pixels so visually that's perfectly fine with me.

[Sohl]

2 hours ago, LatchKeyKid said:

 

Thanks for the info.  When you're using both player sprites for the player, does that mean that none of the enemy/NPC sprites will ever appear on the same scanline with the player then without using flicker like the various multisprite and DPC+ demos?  I'm completely new to all this so I'm starting from scratch and it seems from the 8blit youtube channel videos that you barely have enough CPU cycles to control the two player sprites in the same line hence the frequent doubling up.  As someone without the personal experience, I keep wondering if I'll have enough cycles to control/modify everything needed.  I figure in a two line kernel that the actual player sprites will be on one line and the other will be maybe the ball, a single missile, and the playfield when necessary.  I actually prefer the square doubled pixels so visually that's perfectly fine with me.

Yes, on the same scanline, the TIA will show the two "player" sprites, ball, two missiles, and playfield, according to what is enabled (for ball & missiles) or has '1' bits set (for player graphics AKA "sprites" and playfield).  You can use these however you want, but if both "player" graphics (GRP0 and GRP1) are used to draw the human player's sprite, there is not much left to draw any enemies, a second human player's sprite, etc., so some games use flicker to draw different objects on alternating video frames (mild flicker) or even once per three or four video frames (which leads to very noticeable flicker).

 

Positioning the movable objects is made difficult by the requirement to "strobe" (write anything to) the  "reset position" registers at the right time and then use fine-tuning "movement" registers rather than just putting the intended overall horizontal position as a number into a register.  If you don't have to reuse any of the movable TIA objects as multiple game entities, you can do all of the positioning when the CRT beam is above (VBlank period) or below (Overscan period) the visible portion, so during the visible part you only worry about setting the correct bits on or off (enable flag for ball & missiles, or bitmap for the player graphics and playfield) and correct colors at the right time. If you do want to re-use a TIA object as a different game entity with a different horizontal position, you need to do the repositioning stuff during the visible portion and that can be difficult, especially if the objects are not spaced out enough to get the changes done before the next entity is visible.  

[MCP90]

I did it too on my "as a joke" game BTT , i flicker the ball between the two players which not only represents the helmet/eyes it also gives it a fancy "electronic helmet" look to them, sadly screenshots doesn't do justice to this, it really shines on a crt or running on an emulator with retro filters (stella has you covered with this

[doctorclu]

Currently hex hacking games into an emulator that recognizes 6507 functions, but not the player missile hit detection or graphics.  It is a alpha/demo 2600 emulator for the Jaguar that I've found some games that work and play.

 

One game (Space Chase) works about perfectly as a few other games do, minus the fact that the ball effect doesn't work, so shots and all are invisible.

SpaceChase.zip

 

Question's that come to mind:

Can another color be put in place of the ball color?

 

And what would be great is if anyone knows what those would be in hex, and possible hex replacements for other colors?

[LatchKeyKid]

I'm not a programmer myself but the ball color is typically linked to the playfield color so you can change it on the scan lines that the ball is on but you'd have to either erase playfield elements on those lines as it travels or be ok with them also changing color for those lines.  From what I've read, there is also a score mode where each half the screen of playfield turns to corresponding sprite colors but you still have the option of the original color you set for the playfield for the actual ball.  Again, I haven't programmed anything other than a hack so add much salt to the above as I don't know how practical any of it is.  My guess is that you'd have to program the kernel from scratch to take advantage of the graphic mechanic instead of just incorporating it into an existing game.

[Ecernosoft]

On 6/22/2022 at 6:27 PM, LatchKeyKid said:

I asked this a while ago on a different platform and didn't get an answer but I was curious as to why more games (whether official back in the day or homebrew now) don't use the missile/ball sprites for added color.  At the time, it was a theoretical question for me as I wasn't aware of a game that did but I recently found one that does, Snoopy and the Red Baron).

 

Is there a hidden complication that prevents the use like the tracking of the added sprite (ball in this case) taking up too many CPU cycles?  I now know that various kernels disable aspects of programming in order to make multicolor player sprites like the one below and also that the ball and missile colors are intrinsically tied to the playfield and respective players.  Assuming that you're not disabling them in the kernel or using them for something else, is it just not worth the effort for a splash of color like Snoopy's nose and spots for most programmers?  I personally think it adds alot but as an admitted programming n00b I fully admit that I'm potentially unaware of the cost of tracking the second sprite alongside the player.

It could work but under limited circumstances.

The ball sprite is most useful when no background or a background of a single color is present for added color.

[LatchKeyKid]

Another more recent example from the Homebrew Circus game release wherethe giraffe was created with a player and ball sprite for added color.  Thanks to lucienEN for the example posted in another thread.

 

3 hours ago, lucienEn said:

I took some screenshots from debug colors. The giraffe I think is clear now since it's indeed ball color with just 1 sprite (no small feat still).

The chameleon is still not very clear to me since it only shows 2 sprites and they don't look replicated:

 

 

[Ecernosoft]

On 6/22/2022 at 8:02 PM, LatchKeyKid said:

Can some of those be done ahead of time when time allows (specifically setting the size for example)?  I don't know if that single change helps for example if you're only planning on keeping it a certain size and then moving it hidden under the prioritized player sprite visible under gaps.  I'll have to rewatch the video on drawing sprites and the CPU cycles to see if you can overlap them as I'm hoping.  Basically, I'd want to make something like my profile pic here with a mono-color player sprite and another color ball sprite moving along with it at all times.

If you keep things simple (Ex. Like the Halo example where the Ball doesn't move) and don't mind the color limitation, it can be done. Reminder that you do need to RENDER the ball as well if you want to do this which takes more CPU cycles.