Jump to content

Photo

Vertical Scrolling


6 replies to this topic

#1 vidak OFFLINE  

vidak

    Star Raider

  • 90 posts
  • Location:Sydney, Australia

Posted Thu Jul 13, 2017 5:26 AM

Yo! I'm working on my first homebrew game, and I've been following the excellent tutorials made by SpiceWare, Kirk Israel and others. (Are there more?? I feel like I want to construct a database to centralize all the tutorials)

I want to make a game where a character runs vertically up the screen on a scrolling playfield. I can find a couple of examples in batari BASIC (one interesting one from 2009), but I want to use assembly.

Following SpiceWare, I can construct asymmetric playfields, and I know how to count scanlines and machine cycles.

If BASIC is the best language to effect vertical scrolling, I'll use BASIC!

(As an aside, there are so many amazing resources for learning 6502 assembly online. My favourite is a video series by a man named John Dale on YouTube. His channel name is Oldskool Coder.

In many ways assembly language is easier than BASIC because it's just plugging data into registers with a whole load of branches and tricks.)

#2 Jinroh ONLINE  

Jinroh

    Dragonstomper

  • 540 posts
  • Catgirl Maid Lover

Posted Thu Jul 13, 2017 6:47 AM

Either one should be fine for vertical scrolling.

 

This site has some basic continuous scrolling code you can check out in ASM since you already have one in BASIC it should be easy enough to figure out.

http://khryssun.free...mming_code.html

 

Basically you're drawing your PF down the screen line by line as usual, but you increment/decrement the address at which you start so it appears to scroll so you kind of have a 'floating window' to put it visually in your head into the vertical PF data you have laid out.

 

Start offset determines the top of your 'floating window' within the PFData so that you can render anywhere within your pfdata sliding up/down.

 

pfdata:

   .bytes blah blah blah <------- Frame 0 start offset

   .bytes blah blah blah <------- Frame 1 start Offset

   .bytes blah blah blah <------- Frame...

   .bytes blah blah blah

   .bytes blah blah blah

   .bytes blah blah blah

   .bytes blah blah blah

   .bytes blah blah blah

   .bytes blah blah blah

   .bytes blah blah blah

 

I'm still waking up so I hope that makes sense, it's pretty easy for vertical scrolling. You could also set it up to use virtual blocks so each PFData line represents a 1xN block of pixels to make your PF make up of bricks or something, like I do with my game Carrot Kingdom.

 

That way you could have a larger seeming PF without having to store nearly as much data.

 

Hope that helps to get you rolling along! :)



#3 vidak OFFLINE  

vidak

    Star Raider

  • Topic Starter
  • 90 posts
  • Location:Sydney, Australia

Posted Sat Jul 15, 2017 6:14 AM

Thanks so much for your reply!

What do you mean by virtual blocks - that I don't understand!

#4 SpiceWare OFFLINE  

SpiceWare

    Quadrunner

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

Posted Sun Jul 16, 2017 10:21 AM

You can do some experiments in Collect for vertical scrolling. It'll be chunky scrolling though. In the Kernel section look for this bit of code:

    ; The Arena is drawn using what is known as a 2 line kernel, or 2LK for
    ; short. Basically the code is designed so that the TIA register updates are
    ; spread out over 2 scanlines instead of one.  TIA has a feature for the
    ; player objects, as well as the ball, called Vertical Delay which allows
    ; the objects to still start on any scanline even though they are only
    ; updated every-other scanline.  Vertical Delay is controlled by the TIA
    ; registers VDELP0, VDELP1 and VDELBL.
    ;
    ; ArenaLoop:
    ;       line 1 - updates player1, missile1, playfield
    ;       line 2 - updates player0, missile0, ball
    ;       if not at bottom, goto ArenaLoop
        
        lda #0              ; 2  2
        sta PF0             ; 3  5
        sta PF1             ; 3  8
        sta PF2             ; 3 11
        lda ArenaColor      ; 3 14        
        sta COLUPF          ; 3 17
        lda Variation       ; 3 20
        lsr                 ; 2 22 - which Arena to show
        tay                 ; 2 24 - set for index
        ldx ArenaOffset,y   ; 4 28 - set X for which arena to draw
        stx ArenaIndex      ; 3 31 - save it for Kernal use
        lda ArenaPF0,x      ; 4 35 - reflect and priority for playfield
        and #%00000111      ; 2 37 - get the lower 3 bits for CTRLPF
        ora #%00110000      ; 2 39 - set ball to display as 8x pixel 

 
The value that ends up in ArenaIndex is what controls which Arena to display. Based on the table at ArenaOffset the 2 values used are 0 or 22. If, instead, you vary the value over time from 0,1,...,21,22 you'll end up with a scrolling playfield.

For grins, I made a quick revision to Collect so that the 2nd joystick will scroll the playfield (so don't try playing a 2 player game). Search for SCROLL in the source to find all the changes. If testing in Stella use keys Y and Y for the 2nd joystick's up and down.

Attached File  Collect Scrolling.zip   62.23KB   8 downloads



#5 nanochess OFFLINE  

nanochess

    River Patroller

  • 4,700 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Sun Jul 16, 2017 1:14 PM

Some games that use vertical scrolling are Sky Jinks, River Raid and Strategy-X, I would suggest go get the games and test them.

 

The algorithm is basically some like this: (with map being basically a course drew in squared paper)

 

1. Put a starting pointer to map. (where you put your reference for playfield graphics)

2. Start kernel.

3. Load map into playfield graphics for each line.

4. End kernel.

5. Pointer to map, decrease by 1 (if scrolling upward) or increase by 1 (if scrolling down)

6. Goto to 2

 

I would foresee a simple optimization like using mirrored playfield in order to update only the 3 PF registers and using a single byte in map pointing to a table where to load the PF registers.

 

So each line in your map would use one byte and you could make very long maps.



#6 tschak909 OFFLINE  

tschak909

    Stargunner

  • 1,749 posts
  • Location:USA

Posted Sun Jul 16, 2017 1:53 PM

Vertical scrolling is DEFINITELY a lot easier to implement than horizontal scrolling on the VCS (The VCS engineers never intended for the playfield to be built from RAM!, so the fact that the playfield bits are like a serpentine was inconsequential).

 

Depending on your kernel, you're basically adding or subtracting scanlines while also shifting where you're pulling your playfield data.

 

-Thom 



#7 vidak OFFLINE  

vidak

    Star Raider

  • Topic Starter
  • 90 posts
  • Location:Sydney, Australia

Posted Mon Jul 17, 2017 5:43 AM

Thanks so much for all your help! This is so much more help than I could have expected!

I started looking through Thomas Jentzsch's decompile of River Raid yesterday. I was surprised at how little ROM data Carol Shaw used in setting up the entire map. I'm going to copy the idea of controlled randomness into setting up my scrolling playfield.

The difference between the 80s and now though is that ROM is much cheaper, and I may just construct an entire playfield in ROM and make a 16KB or 32KB game with bank switching.

All of what everyone has said has made perfect sense, and it's always awesome to have the legendary SpiceWare comment on your thread :)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users