Diagonal scrolling - the afterthought, hack and illusion

Background

• Any support for vertical/diagonal scroll was not part of the consideration when designing the original architecture.
• One morning I got an idea which I thought could make it possible to scroll diagonally up or diagonally down for free or nearly for free. I had to try to retrofit it in.
• Very little flexibility for gameplay variations, but presumably +1 on tech.

The grand idea for vertical/diagonal movement

• Building this on top of existing algorithm would only give the illusion of vertical support.
• New tiles coming "from above" or "from below" can only enter the scene at right of screen, at tile column 15 where x ∈ [240, 254].
• Any graphics moving into the screen for all x ∈ [0, 240] would be a static (background) color.
• A vertical movement across 16 pixels would happen in steps by 2 in the same cycle as the horisontal move. Same speed, same cycle. I.e. it happens over 8 frames.
• We use r#23 for this.
• This will expose the area above and below current level in VRAM, so this area should be filled with background color.
• The current algorithm would work as before, we'll "just" do +/-16 px on the source y-pos of the rectangles.
• No additional data requirements.

How it is done

Level data should not use more space, so we "flatten" the level as in the image below, and add a file on the side which holds information about tile positions which either go UP or DOWN. This extra information ends up really small, so that is totally fine memory wise.

My old design notes should explain all of it:

• It shows a viewport into VRAM, where tile line 0 and tile line 12 is now required, and they must contain background color.
• The fundament scroll algorithm never copy into the gray areas for tile column ∈ [1, 14], so this is static.

I did not realize it at first, but now I got 4 corners that I had to constantly clear/fill with either background or border color. That is 16 lines with 8 bytes each. Cost approx for each of these four rectangles: R#14 + 8*(ADDRESS + 8bytes) = 1476/1558 cycles. In the video you can see tile row 0, and you can see some activity in the upper left corner.

Expected limitations

• The vertical movement has the same speed as horizontal, it is maximum 1 tile per 8 frames, rendering it unusable for sudden and hefty vertical gameplay challenges as in Geometry Dash.
• No ability to have tiles coming in at top or bottom for x < 240 is insanely challenging to design good, intriguing levels with.
• The command engine was already fully occupied, so any changes had to come via the CPU.

Other consequences

• Due to flattening, and the fact that the vertical position of a column had to be calculated and tracked ended up sub-par, programming wise. I use a ring buffer for the visible columns on screen to be able to track at where in memory a block actually is. I need that for collision check. What used to be a straight line in memory on the horizontal-only scroll is now like this:

• Collision suddenly becomes more complex and costly. And due to cycle constraints, the code ended up ugly too.
• Changing y-hardscroll affects when the line-interrupt occurs, so this had to be planned for.
• All these new cycles "inflicted on us" ☺️, forced optimizations to be done other places, to be able to get all done with a frame.
• Timed unrolled outs for "blackstrip" and "one-strip" needed logic around the line interrupts to cater for 3 different scenarios.
• I had to spread out the work as much as possible over the frame, as well as over the 8 steps in the cycle. Absolutely surgical work and not very pretty.

Conclusion

Things coming in, in retrospect, typically ends up as a hack. This snazzy little effect probably gave more trouble than it’s worth.

The screen 5 scroll  |  Horizontal scrolling & key concepts  |  Diagonal scrolling - the afterthought, hack and illusion