Kernel loop from Complex scene 1

[Danny85]

Hi,

 

I'm currently working my way through the book "Making Games for the Atari 2600" by Steven Hugg. I'm really enjoying it but have come across one thing (of many) that I'm really confused by.

 

In the "Complex scene 1" chapter the following code is used to decided when to render sprite 0:

 

KernelLoop
; Does this scanline intersect our sprite?
        lda #SpriteHeight	; height in 2xlines
        isb YP0			; INC yp0, then SBC yp0
        bcs .DoDraw		; inside bounds?
        lda #0			; no, load the padding offset (0)
.DoDraw

From what I understand, YP0 is being set to the current Y position of sprite 0 at the beginning of each frame which makes sense and the .DoDraw label is only branched to if #SpriteHeight >= YP0+1. This second point is the bit I don't understand. As #SpriteHeight is a constant I'm not sure how this can work for any value of Y?

 

If anybody could offer a description of what exactly is happening here it would be very much appreciated.

 

Thanks,

 

Danny

[+Andrew Davie]

On 9/20/2019 at 8:41 AM, Danny85 said:

Hi,

 

I'm currently working my way through the book "Making Games for the Atari 2600" by Steven Hugg. I'm really enjoying it but have come across one thing (of many) that I'm really confused by.

 

In the "Complex scene 1" chapter the following code is used to decided when to render sprite 0:

 

KernelLoop
; Does this scanline intersect our sprite?
        lda #SpriteHeight	; height in 2xlines
        isb YP0			; INC yp0, then SBC yp0
        bcs .DoDraw		; inside bounds?
        lda #0			; no, load the padding offset (0)
.DoDraw

From what I understand, YP0 is being set to the current Y position of sprite 0 at the beginning of each frame which makes sense and the .DoDraw label is only branched to if #SpriteHeight >= YP0+1. This second point is the bit I don't understand. As #SpriteHeight is a constant I'm not sure how this can work for any value of Y?

 

If anybody could offer a description of what exactly is happening here it would be very much appreciated.

 

Thanks,

 

Danny

 

Well, I've never actually used this, but just thought I'd point out a small bit of a misunderstanding in your pseudo-code there. It's more like...  FIRST, increment YP0. THEN, after it's incremented, do the branch if #SpriteHeight >= YP0.  Thus, YP0 is incremented every scanline.  I would assume from the comment that sprite definitions start with 0 and at .DoDraw the value in the accumulator is used as an index into the sprite shape data.

I can't see how this would work with your assumption that current Y position is in YP0.

However if the negative of current Y position is in YP0...

 

say, YP = -5 (i.e., line 5)

SpriteHeight = 2

 

LINE .  YP0 .  CARRY .  .DoDraw

0       -4    (2--4) C   0
1       -3    (2--3) C   0
2       -2    (2--2) C   0
3       -1    (2--1) C   0
4        0     (2-0) S   0
5        1     (2-1) S   1  STUFF DRAWN
6        2     (2-2) S   2  STUFF DRAWN
7        3     (3-3) S   3  STUFF DRAWN
8        4     (3-4) C   0   

... and for the rest of the screen will be similar to the last line (that is, YP0 big, so carry clear on subtraction, so 0 is the result at .doDraw

 

It seems to me that .DoDraw will receive a non-zero index only when scanline >= -YP0, and it will be valid for SpriteHeight+1 lines.

I might be out a line or two but maybe that's how it works... haven't studied it before.  It's very clever code.

 

 

 

[+SpiceWare]

Interesting - I've always seen DCP used for DoDraw, not ISB. In a number of the comments below this blog entry for my Collect tutorial I broke down how DoDraw works for @Exuro89 and @BNE Jeff.  I even did the same line-by-line breakdown Andrew does in one of the comments, but the value is decreased rather than increased.

 

Do note the blog entry itself is a bit messed up due to the recent forum upgrade - namely all the code boxes ended up with code on a single line of text. Code in all the comments is OK.  Random Terrain did an offsite conversion of the tutorial if you need to see the blog entry's code snippets as they should be.

[Danny85]

Thank you both - I've been looking through what you suggested and I feel as though my understanding has improved.

 

I'm going to continue researching.

 

Thanks again :-).