Jump to content

Photo

Asymetrical Reflected Playfield


5 replies to this topic

#1 BNE Jeff OFFLINE  

BNE Jeff

    Moonsweeper

  • 286 posts
  • Location:Virginia, USA

Posted Sun Jul 10, 2016 11:46 AM

Good Afternoon,

 

I want to do a reflected asymmetrical playfield where PF2 sometimes appears left of center, sometimes right.  Is that possible or practical?  Should i just try PF1 instead?  Or don't even try reflected asymmetrical?

 

Thanks for the help!



#2 tschak909 OFFLINE  

tschak909

    Stargunner

  • 1,771 posts
  • Location:USA

Posted Sun Jul 10, 2016 12:12 PM

the playfield positions are static, you can't move them left or right, you can only shift the bits.

 

-Thom



#3 SpiceWare OFFLINE  

SpiceWare

    Quadrunner

  • 11,206 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Jul 10, 2016 12:30 PM

I originally used repeated asymmetrical playfields in Stay Frosty, but changed it to reflected asymmetrical to save cycle time and reduce RAM requirements.  You can see that in Part 3 and Part 4 of my SF blog series.  

 

The key thing to note is you must update PF2 for the right side of the screen at exactly cycle 48.  Any sooner or later and the display will be incorrect.



#4 BNE Jeff OFFLINE  

BNE Jeff

    Moonsweeper

  • Topic Starter
  • 286 posts
  • Location:Virginia, USA

Posted Sun Jul 10, 2016 12:33 PM

tschak909....

Appear, not move.  So I'd store either zero or the playfield data right at cycle 38 for the right side.  Most other times for the left.


Edited by BNE Jeff, Sun Jul 10, 2016 12:34 PM.


#5 BNE Jeff OFFLINE  

BNE Jeff

    Moonsweeper

  • Topic Starter
  • 286 posts
  • Location:Virginia, USA

Posted Sun Jul 10, 2016 12:43 PM

I originally used repeated asymmetrical playfields in Stay Frosty, but changed it to reflected asymmetrical to save cycle time and reduce RAM requirements.  You can see that in Part 3 and Part 4 of my SF blog series.  

 

The key thing to note is you must update PF2 for the right side of the screen at exactly cycle 48.  Any sooner or later and the display will be incorrect.

 

OK I'll check those out in a bit.  And correction..  cycle 48. Thanks. So it is done then?  I need consistent lines I suppose.  If I recall from the Collect series, the .byte $2C trick keeps the cycles consistent with the bcs DoDraw branch time right?


Edited by BNE Jeff, Sun Jul 10, 2016 12:44 PM.


#6 SpiceWare OFFLINE  

SpiceWare

    Quadrunner

  • 11,206 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun Jul 10, 2016 12:55 PM

Yes, the STA PF2 must end on cycle 48. I don't have many cycle counts in the early source examples. The final source has them like this:
 
        sta GRP0                      ; 3
        lda (FrostyColorPtr+.SEC*2),y ; 5   8
        sta COLUP0                    ; 3  11
        lda (FireImagePtr+.SEC*2),y   ; 5  16
        sta GRP1                      ; 3  19
        ldx IceData+.SEC*4            ; 3  22
        stx PF1                       ; 3  25
        ldx IceData+.SEC*4+1          ; 3  28
        stx PF2                       ; 3  31
        ldx IceData+.SEC*4+2          ; 3  34
        SLEEP 9                       ; 9  43
        dey                           ; 2  45
        stx PF2                       ; 3  48 <- must be at 48
        ldx IceData+.SEC*4+3          ; 3  51
        stx PF1                       ; 3  54
        lda (FrostyImagePtr+.SEC*2),y ; 5  64
        and (FrostyMaskPtr+.SEC*2),y  ; 5  69
        sta WSYNC                     ; 3  72
 
DoDraw is written so the cycles are exactly the same no matter which path through the code is taken, which makes it very useful for kernels that require precise timing like this.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users