turning off sprite pixels

[+atari2600land]

Suppose you're using player0 and NUSIZ0=$07. Is there a way to turn off 4 pixels at a time when, say, one of the four pixels in a certain range of player0 gets hit by a missile or something?

[+Gemintronic]

This is not a definitive answer but..

 

No. You get hardware collision which is the whole sprite. On a more powerful system you could use this to trigger a software based per-pixel collision routine and then delete the pixels needed.

 

You can fiddle with the sprite pixels at runtime but this requires you to move the sprite data into RAM. Very expensive.

Edited April 9, 2012 by theloon

[SeaGtGruff]

Suppose you're using player0 and NUSIZ0=$07. Is there a way to turn off 4 pixels at a time when, say, one of the four pixels in a certain range of player0 gets hit by a missile or something?

The short answer is "Yes, there is a way to do that." But that doesn't mean it will be easy.

 

This question involves two issues-- (1) how to selectively turn the pixels of a player on or off; and (2) how to do fancy collision detection. I'm going to ignore the second issue for the time being.

 

There are only two ways to selectively turn the pixels of a player on or off-- (1) by putting the sprite data in RAM so the data can be changed dynamically; or (2) by putting the sprite data in ROM and defining as many different versions of the player as needed, then pointing to whichever version is appropriate.

 

Method 2 is the one normally used to animate a sprite, and is best suited to situations where the total number of variations in the sprite's appearance is fairly small. If you want to selectively turn the sprite's pixels on or off, you probably are *not* talking about simple animation, so method 2 wouldn't be feasible.

 

Method 1 is probably what you'd want to use-- move the sprite's data into RAM, then you can selectively turn any of its pixels on or off.

 

For example, 2600 "Space Invaders" uses method 1 for the three shields-- each shield's initial data is copied into RAM, then the pixels (bits) are selectively turned off as the invaders' missiles hit the shields, slowly eating away at the shields. It looks to me like the programmer(s) could have used the RAM more efficiently by using the ZP,X mode to read the shields' data from RAM, instead of using the (ZP),Y mode-- but I assume the (ZP),Y mode was chosen for a good reason.

 

It's true that moving sprite data to RAM is expensive, since RAM is such a precious commodity on the 2600-- but it might be worth the expense, depending on how much RAM you need for the other parts of your program and whether or not you're using a cartridge type that adds extra RAM.