Sprite Positioning Problem

[cd-w]

I am currently trying to get my head around sprite handling on the 2600. I think I have the main concepts down now, but I am having some difficulty putting it into practice. I am trying to draw a swinging rope ladder using the ball sprite (see attached file). The code mostly works, but for some reason the sprite position is incorrect every few scanlines. It looks like the sprite position is being updated too soon (before the HMOVE), but as I understand it, the RESBL and HMBL shouldn't take effect until after the HMOVE? Perhaps this isn't actually the problem at all. The code seems to work better under Stella than Z26, but clearly this isn't much use! Anyway, I will be very grateful if someone can spot the problem!

 

Chris

rope.zip

[vdub_bobby]

I think it is because you are calling hitting RESPBL on the same scanlines as you are displaying the ball.

 

I can't quite wrap my head around why this will mess things up right now, but I am pretty sure it will

 

For what you are doing, you should just be adjusting HMBL and calling HMOVE every scanline; you don't need to call the entire repositioning subroutine every time just to move the ball left/right one or two pixels.

 

Also: your repositioning subroutine isn't really well suited for use inside a kernel, because it will take an extra scanline if you position the object near the right edge of the screen.

[vdub_bobby]

It looks like the sprite position is being updated too soon (before the HMOVE), but as I understand it, the RESBL and HMBL shouldn't take effect until after the HMOVE?

Oh, and: RESBL will take effect immediately.

 

For a highly, highly technical discussion of this, you can check this out:

http://www.whimsey.com/atari_docs/TIA_HW_Notes.txt

 

But basically, because RESxx affects things immediately, you should probably not try to draw an object on the same scanline as when you try to reposition it.

[cd-w]

I think it is because you are calling hitting RESPBL on the same scanlines as you are displaying the ball.

 

I can't quite wrap my head around why this will mess things up right now, but I am pretty sure it will

 

For what you are doing, you should just be adjusting HMBL and calling HMOVE every scanline; you don't need to call the entire repositioning subroutine every time just to move the ball left/right one or two pixels.

 

Also: your repositioning subroutine isn't really well suited for use inside a kernel, because it will take an extra scanline if you position the object near the right edge of the screen.

 

Many thanks - for some reason I thought you had to completely

reposition everything from scratch each time. I've now got it

working properly by tweaking HMBL on every scanline.

 

Chris

[vdub_bobby]

Cool!

[cd-w]

Apologies for raising this thread, but I have another related sprite positioning problem. For some reason, the following kernel code fragment fails to work as expected. The missile sprite is incorrectly positioned, and for certain values the TIA seems to enter an infinite loop (I have verified that this also happens on real hardware with my Supercharger):

 

   ; Load Missile Data
    lda (BPTR),Y         ; [67] + 5
    sta HMM0             ; [72] + 3

   ; Commit Movements
    sta HMOVE            ; [75] + 3

   ; Draw Missile (M0)
    sta ENAM0            ; [2] + 3
    asl                  ; [5] + 2
    asl                  ; [7] + 2
    sta NUSIZ0           ; [9] + 3

 

I understand that the HMxx registers should not be modified for a certain number of cycles after the HMOVE. However, is there any restriction in altering them before the HMOVE, and should the ENAxx and NUSIZx registers not be touched after an HMOVE? Ensuring that the HMOVE happens on exactly cycle 76 does not seem fix the problem. Any advice would be appreciated as this is causing me some real head scratching.

 

Chris

[+batari]

Apologies for raising this thread, but I have another related sprite positioning problem.  For some reason, the following kernel code fragment fails to work as expected.  The missile sprite is incorrectly positioned, and for certain values the TIA seems to enter an infinite loop (I have verified that this also happens on real hardware with my Supercharger):

 

  ; Load Missile Data
    lda (BPTR),Y        ; [67] + 5
    sta HMM0            ; [72] + 3

  ; Commit Movements
    sta HMOVE           ; [75] + 3

  ; Draw Missile (M0)
    sta ENAM0           ; [2] + 3
    asl                 ; [5] + 2
    asl                 ; [7] + 2
    sta NUSIZ0          ; [9] + 3

 

I understand that the HMxx registers should not be modified for a certain number of cycles after the HMOVE.  However, is there any restriction in altering them before the HMOVE, and should the ENAxx and NUSIZx registers not be touched after an HMOVE?    Ensuring that the HMOVE happens on exactly cycle 76 does not seem fix the problem.  Any advice would be appreciated as this is causing me some real head scratching. 

 

Chris

883128[/snapback]

I haven't any idea.

 

But have you tried running in z26 with tracing on or with the new debugger in the alpha version of Stella 2.0 (on the Stella list)? I'd be curious what Stella says, or what the z26 trace file spits out.

[cd-w]

But have you tried running in z26 with tracing on or with the new debugger in the alpha version of Stella 2.0 (on the Stella list)?  I'd be curious what Stella says, or what the z26 trace file spits out.

883135[/snapback]

 

Thanks for the suggestion. It seems that this code is OK after all - the timings were just getting screwed due to a carry flag not being properly set elsewhere in the code. This was causing HMOVE to be called at the wrong time ... Argh, I think I should call it a night.

 

Chris

[+stephena]

But have you tried running in z26 with tracing on or with the new debugger in the alpha version of Stella 2.0 (on the Stella list)?  I'd be curious what Stella says, or what the z26 trace file spits out.

883135[/snapback]

We've been found out Yes, we have a (very) alpha release of Stella 2.0 released on the Stella list. It's not ready for consumption yet, but things are progressing very quickly.

 

Steve