Demo - 3 sprites without flicker

[ZackAttack]

I had an idea to simulate more than 2 sprites by duplicating P1 and updating GRP1 and COLUP1 twice per scanline so each copy of P1 can be a different sprite. By padding the graphic data with zeros the vertical positions of each copy can be changed independent of the other. By moving them in a circle and placing them out of phase with each other, it allows one object to rotate clockwise and the other to rotate counterclockwise. Sorry the source is so messy.

 

 

Latest Build:

 

bees0.2.bin

 

bees0.2.asm

 

Use up and down to modify the paths of the bees

Edited April 24, 2015 by ZackAttack

[Thomas Jentzsch]

That sure looks cool!

[+SpiceWare]

Slick!

[ZackAttack]

Thanks. I uploaded a new version that lets you modify the bees paths by pressing up or down.

[+Stephen]

That's really cool!

[Zarek]

Awesome work! Thanks for the source!

[ZackAttack]

With a little more effort I think it would be possible to have the P1 sprites (bees) travel across the screen in a sine wave pattern. The challenge there would be keeping the updates for the second copy in between the two copies. It would probably require a few different kernels to be switched as the sprites traveled across the screen.

[Omegamatrix]

With a little more effort I think it would be possible to have the P1 sprites (bees) travel across the screen in a sine wave pattern. The challenge there would be keeping the updates for the second copy in between the two copies. It would probably require a few different kernels to be switched as the sprites traveled across the screen.

It's not to bad if you have a loop in your kernel that is exactly 76 cycles without a WSYNC. That way you can enter the loop at a certain cycle and have the update happen in-between the sprites. If you follow the link to Circus Atariage in my signature you can see an example of this on the playing screen. The middle of the see-saw and the "catcher" are both drawn with P0, and it is set at two copies close. This can all be done with 1 kernel, but I am using three in CAA for other reasons that I don't remember right now.

[ZackAttack]

That's a neat idea. I think you'd still need multiple kernels in order to handle moving P0 independent of P1. Maybe that's why CAA has 3.

[Omegamatrix]

That's a neat idea. I think you'd still need multiple kernels in order to handle moving P0 independent of P1. Maybe that's why CAA has 3.

I looked back at the kernels. My memory was wrong about having no WSYNC in the loop. The positioning of P0 and P1 is done outside of the loops so that doesn't matter inside of them. I rediscovered that I'm HMOV'ing on every line of these kernels to draw the see-saw.

 

One of the kernels uses HMOVE at cycle74 for a specific situation where the "Catcher" is in a area where the HMOVE comb lines would normally cover him up. Other than that, two kernels are used in CAA to split the screen roughly in half. That way you can update P0 either quite early or quite late. This worked good enough in my case because I don't go completely to the right or left edge of the screens.

 

This is what the the two kernels look like. In the loop I do an indirect jump into the illegal NOP table to get the exact cycle delay before updating P0.

;---------------------------------------------------------
;  LEFT
;---------------------------------------------------------

    .byte $80,$80,$80,$80,$80,$80,$80,$80   ; Illegal NOP delay table
    .byte $80,$80,$80,$80,$80,$80,$80,$80
    .byte $80,$80,$80,$80,$80,$80
    .byte $04
    nop

UpdateCartCatcherLeft:
    sta    GRP0                  ;3  @
    dey                          ;2  @34
    bmi   .exitSeeSawLeft        ;2³ @

StartSeeSawLeft:
    lax    (tS_ColJumper),Y      ;5  @24
    txs
    lax    (tS_CatcherCartA),Y   ;5  @8
    lda    (tS_Jumper),Y         ;5  @16
    sta    WSYNC
;---------------------------------------
    sta    HMOVE                 ;3  @3
    stx    GRP0                  ;3  @6
    sta    GRP1                  ;3  @9
    tsx                          ;2  @11
    stx    COLUP1                ;3  @14
    lda    (tS_CatcherCartB),Y   ;5  @19
    jmp.ind (updateCartCatcher)  ;5  @24

;-------------------------------------------------------
; Right
;-------------------------------------------------------

    .byte $80,$80,$80,$80,$80,$80,$80,$80   ; Illegal NOP delay table
    .byte $80,$80,$80,$80,$80,$80,$80,$80
    .byte $80,$80,$80,$80,$80,$80,$80,$80
    .byte $80
    .byte $04
    nop

UpdateCartCatcherRight:
    sta    GRP0                  ;2  @
    bmi   .exitSeeSawRight       ;2³ @
StartSeeSawRight:
    sta    WSYNC
;---------------------------------------
    sta    HMOVE                 ;3  @3
    lda    (tS_Jumper),Y         ;5  @8
    sta    GRP1                  ;3  @11
    lda    (tS_ColJumper),Y      ;5  @16
    sta    COLUP1                ;3  @19
    lda    (tS_CatcherCartA),Y   ;5  @24
    sta    GRP0                  ;3  @27
    lda    (tS_CatcherCartB),Y   ;5  @32
    dey                          ;2  @34
    jmp.ind (updateCartCatcher)  ;5  @41

The illegal NOP delays do not change any of the status flags, which is nice. Opcode $80 is NOP #Immediate while opcode $04 is NOP zeropage. I normally use them with JSR, so the delay table would look like this (where you can keep adding bytes of $80 opcodes to get more and more cycle delays).

WasteTime21
    .byte $80
WasteTime20
    .byte $80
WasteTime19
    .byte $80
WasteTime18
    .byte $80
WasteTime17
    .byte $80
WasteTime16
    .byte $80
WasteTime15
    .byte $04
WasteTime14
    nop
WasteTime12
    rts