Kernel Segmentation

[johnnystarr]

This might be dumb, but I have started to realize what I have been doing wrong. I have been viewing my kernel as one big glob instead of small sections. When working with the NES frame buffer and DMA, you don't exactly have to view any section of the screen as "special" - at least not in common situations.

 

This is the downside of writing demos at first. You seem to think of the screen as free real estate for your sprites to go wherever they please. But, in some of the best games, I've noticed that the sprites only "live" on certain lines.

 

After studying "Dragonfire" a bit, I came to a few assertions. They are notated in the diagram image I uploaded. Granted, I am inferring quite a bit with the number of scanlines per segment. It isn't meant to be exact. The point is, I'm guessing here and the purpose for this post is to see if I am anywhere near the mark.

 

If my understanding is accurate, I'm still having trouble understanding how exactly one might have so many sprites on the screen. I've read that this isn't too difficult on a vertical scale because the TIA latches the values until changed. But, what I haven't figured out is collision detection and what to do when those collisions are made. Or, if you even would use collision detection at all for this. (specifically, when the character grabs all the goodies)

 

 

My goal is to continue to write small demos before I dive deep into a big project. I want to learn all of these techniques so that if one of my games calls for multiple sprites, I will already know how that is done.

 

[+SpiceWare]

There's a few ways to deal with collision detection.

1. if collision was detected, use the X and Y values of the player's position to determine which copy was hit (CPU expensive)
2. save collision registers for each section (RAM expensive, but fast)
3. use software collision detection (CPU and ROM expensive)

 

For Medieval Mayhem I used the first option, the X and Y values of the fireballs determined what was hit.

 

For Stay Frosty and Stay Frosty 2 I saved the collision registers for each zone.

 

For Space Rocks I used the ARM chip's extra horsepower to do software collision detection. Atari's Asteroids also used software collision detection - since everything flickered, some of the collisions could not be detected by the hardware.

[johnnystarr]

@SpiceWare

 

I appreciate all the help. On your slide presentation, I noticed how you were able to show how SP0 and SP1 could be used along with the ball and missiles to facilitate multiple sprites.

 

So am I getting things right with the segmentation? As in, if the top of the screen isn't going to have movement, I can make it more detailed graphically. But, the sections that have a lot more drawn during the HBLANK period, to keep it more simple (IE no playfield on that line, etc.)

[+SpiceWare]

Yep, that's how it's done. If you know an object is always going to be on the left, or always on the right, then you can do mid-screen updates of those objects.

 

After you get more comfortable with TIA, take the time to understand Vertical Delay. It'll give you a little more freedom for 1 or 2 of the updates.