Vertical Trench experimenting issues.

[Domeshtan]

  Playing around with the idea of trying to do a version of Trench but with vertical scrolling this time. (Never figured out how to get rid of the scanline twitch jumping from the menu into the game on the first.) Anyway, just wondering what is causing the little ship bounce when you are on the far left of the screen. Is it some kind of "align" issue? Also, is it missing a line of VSYNC somehow?

Doubt I would have lasers on this one with the width problem. (Lasers worked better scrolling horizontal. Just turn them on and off.) Also with more layers of depth I'm wondering how playable this could be.

VerticalTrench85AA.zip

[+ZeroPage Homebrew]

Wow, what an incredible perspective, love this redesign of Trench. I'll be including this in tonight's news portion of ZeroPage.

 

- James

[Omegamatrix]

The ship is bouncing because one of the display kernels is updating GRP0 too late, so it is dropped down by one line. 

 

Looking at the code there are two things you could do that will make an immediate impact. First put all of your zeropage ram references into seg.u vars instead of hardcoding them. Use "ds" to designate how many bytes so that you can easily do much more than 1 or 2.

 

       seg.u vars
       ORG $80

frameCounter   ds 1  ; ds = designate space, 1 byte of ram in this case
playerX        ds 1
playerY        ds 1
gameGrid       ds 20  ; 20 bytes of ram

 

The second thing is reducing the multiple kernels for the different playfields. It would be much more managable to make pointers to playfield data you want instead.

 

; load pointers
    ldy shipAltitude        ; Y = 0 to 6
    lda ShipDataPtrLoTab,Y
    sta spritePtr
    lda ShipDataPtrHighTab,Y
    sta spritePtr+1


    ldy screenFrameNumber   ; Y = 0 to 3
    lda Pf0_PtrLoTab,Y
    sta pf0Gfx
    lda Pf0_PtrHighTab,Y
    sta pf0Gfx+1



; data tables
ShipDataPtrLoTab:
    .byte <ShipData
    .byte <ShipData2
    .byte <ShipData3
    .byte <ShipData4
    .byte <ShipData5
    .byte <ShipData6
    .byte <ShipData7
ShipDataPtrLoTab:
    .byte >ShipData
    .byte >ShipData2
    .byte >ShipData3
    .byte >ShipData4
    .byte >ShipData5
    .byte >ShipData6
    .byte >ShipData7


Pf0_PtrLoTab:
    .byte <Frame1PF0
    .byte <Frame2PF0
    .byte <Frame3PF0
    .byte <Frame4PF0
Pf0_PtrHighTab:
    .byte >Frame1PF0
    .byte >Frame2PF0
    .byte >Frame3PF0
    .byte >Frame4PF0

 

Than your kernel becomes:

DrawDaScreen:
    lda (SpritePtr),y
    sta WSYNC
;-------------------
    sta GRP0
    lda (pf0Gfx),y
    sta PF0
    lda (pf1Gfx),y
    sta PF1
    lda (pf2Gfx),y
    sta PF2

    iny
    cpy #140
    bne DrawDaScreen

    sta WSYNC
;-------------------
    lda #0
    sta PF0
    sta PF1
    sta PF2
    sta COLUBK
    sta COLUPF

    sta WSYNC
;------------------
    jmp OScanS

 

 

[Domeshtan]

Thanks for the advice! Hard to break old habits. I'm used to loading stuff directly in. Haven't used pointers much. Well, I'm sure it can be cleaned up much more but got a non-bouncy version now. I used pointers for PF0,PF1,PF2... At first the bounce just shifted right a little. Rearranged the order then the playfield started getting warped. Moved the WSYNC to the top and it's looking pretty good now. (Still got one scanline on the top flashing on and off but the bounce is fixed). Probably why my car in Retro Racing takes a dip down a scanline at times or the playfield swims. Didn't change all the hard coding yet.

VTrench86NoBounce.zip

Edited November 30, 2020 by Domeshtan