| |
serato
Registered: Feb 2021
Posts: 7 |
Release id #242834 : Layers
A few people have asked how the effects in Layers work, so I'll try to explain here in 2 parts.
Pt.1 The Big Scroller
This part has the appearance of smooth scrolling large vector letters. Without the background pattern it would be even more convincing, but really the large text is built from character tiles. Of course the really innovative effect is the full screen +/- 7° rotation at 50fps.
Full Screen Rotation
For small angles a rotation can be approximated by combining horizontal and vertical skews. For efficiency I limit myself to skewing whole character columns and rows, and for visual smoothness limit the step to 1 pixel per 8 pixel character row/column. 1 pixel per 8 = maximum rotation of arctan(1/8) = 7.125°. Being 40 characters wide the maximum vertical skew needed will be 40 pixels, or 5 characters' worth. Similarly 25 rows demands 25 pixels of horizontal skew.
So now the problem is how to accomplish the skews. The VIC has 8 pixel hardware scrolling, and because the raster is scanned from top to bottom I can update the horizontal scroll value for each character row. When I need to shift more than 8 pixels I can horizontally offset the characters in the screen matrix.
This leaves the problem of vertical skew, which I accomplish by pre-rendering all 8 vertical shifts into separate entries in the character set. Each screen character can be viewed as a small portal. When a column is shifted the portal partially overlaps two source tiles. So each "portal" is uniquely defined by the two tiles it overlaps above and below. Because the 8 vertical shifts consumes 8 character definitions, there is only room for 256/8 = 32 unique "portals" in the character set. The large scroll text is drawn using just 15 tiles, and carefully designed to use no more than 32 of the 225 possible above/below combinations.
Rendering the Matrix
The source matrix contains all the portal values stored x8, ie %xxxxx000. As each new column is about to scroll into view I make 8 copies of it OR'd with 0..7 which are cached while the column is on screen.
Constructing an image starts with calculating the horizontal and vertical skew values with a simple line algorithm. These are split into the fine part (mod 8) and coarse part (div 8).
A fairly short section of speed code copies (LDA $,y / STA $,x) a row of matrix values onto the screen, looping up to 7 times to draw 7 screen rows (ie y index 0..7, x index 0, 40 ... 200, 240). This block is duplicated 4 times to cover all 25 rows. Each frame all the LDA's in the speed code are updated with the coarse and fine vertical offsets into the cached matrix values. To accomodate horizontal shifts of >8 pixels, the the x index of each row has the coarse x offset added.
The "Parallax" Background
The main scroll loop moves the screen left at 3px / frame, and the parallax effect is achieved by shifting the background tile 2px / frame to the right, leaving a net shift of 1px / frame. This results in 4 shifts, so 4 sets of the entire character set are pre-baked and then cycled per frame. |
|
| |
serato
Registered: Feb 2021
Posts: 7 |
Pt.2 The 4 Layer Parallax
The principle for how this works is simple, but the devil is in the details of the timing and reducing the workload sufficiently to get all the work done in the cycles available.
Back 2 layers
This part uses an x-expanded 7 x 6 sprite blanket for the first two layers. The two layers are OR'd together as the images are blitted to the sprite data. The farthest layer only changes every 8 pixel rows, so only every 8th row is stored, but pre-shifted 8 times to speed up the blitting. Even then it takes 3 frames to get all the work done. The layers are moving at 1px and 0.5px per frame, which creates a net offset of 1 lores (expanded) pixel every 4 frames.
Front 2 layers
The front two layers are moving at 2 and 4 px/frame and are built in character mode. A conceptually similar approach is used of pre-rendering "portals" that slide over two horizontally adjacent background layer tiles. This time there are only 4 offsets to accomodate, and since the offset is fixed for the whole frame then it can be baked into the character set, so there are 4 character sets.
Layer Design
The background layer is composed of just 6 tiles, but they occur in most combinations (30 of the 36 possible). The front layer is composed of 13 tiles, but only 8 of these have any opacity, the other 5 being completely opaque.
The Character Set
The possible combinations of front tile and back "portal" that needs to be rendered is 30 x 8 + 5. These are arranged in 32 sets of 8, ie the character value %rrrrrfff contains the combination of the semi-transparent tile f and the background portal r. The two source matrixes are stored as %11111fff and %rrrrr111 and then AND'd together to determine which character to render to the screen matrix. The 5 fully opaque front tiles are held in characters %00000fff, as the portal number 0 is not used and the 0's AND out the background.
Rendering and Timing
It takes nearly a full frame to render the screen matrix. The offset between the two layers reaches a full character width after 4 frames, but in that time the front layer should move 16 pixels. The VIC hardware does only provide 8 pixels of shift, so this should require re-writing the screen matrix every 2 frames. But we already know that blitting the back 2 layers consumes 3 of every 4 frames, so it can't be done in the time available. This is where I employed a very nice trick: 1 character of VSP offset. This effectively grants 16 pixels of hardware scroll, and allows the matrix to only update once every 4 frames, slotting in nicely with the blitting of the back 2 layers.
Other Sprite Use
The front layer extends into the top border, using 5 x-expanded sprites that are placed dynamically and scrolled in unison with the characters. There is also an unexpanded multicolour 14-sprite text scroller. Along with the 42-sprite blanket that makes for 61 sprites. |
| |
Burglar
Registered: Dec 2004
Posts: 1051 |
thanks! thats a terrific detailed explanation, and you left the aha!-moment till near the end, haha :) |
| |
Raistlin
Registered: Mar 2007
Posts: 575 |
Wow, great write-up Serato! Awesome effect. |
| |
Stone
Registered: Oct 2006
Posts: 170 |
Great write-up! We had a similar setup on the Scrollwars intro, although there the code was super simple. The real hard work was done by PAL in creating 2 distinct tilesets where each layer had to fit in the 5/3 bit addressable range. |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
WOW! This is the extra cream on top of the already outstanding release! Thank <3 you for this detailed write-up, Serato! |
| |
CreaMD
Registered: Dec 2001
Posts: 3036 |
Awesome engineering. I wonder if someone else will ever try to replicate / build upon this idea. |
| |
PAL
Registered: Mar 2009
Posts: 270 |
Because Serato is a splendid and just nice dude he put this explanation out here and he even never took his own credits for the way he actually nailed it to function every frame in realtime, THE NEVER DONE BEFORE... because he is a superiour coder and a lovely person... Lets have fun... the c64 have much more to offer than just movie like demos... coderporn coming up... |
| |
Oswald
Registered: Apr 2002
Posts: 5029 |
I have a question, sprites can only be shown by VICII behind 10 and 11 pixels, yet the char layer seems to be 4 coloured ?
topmost layer has 4 colors, so the transparent layer of it is a 5th "color" ? maybe you use d800 for the extra color. |
| |
Jammer
Registered: Nov 2002
Posts: 1293 |
I thought about exact same thing today but my guess is PAL used the same gray for %01 as background sprites do? Screen has 4 colours total. BTW, pay attention to front layer's highlights what happens in there - freeze frame might help ;) |
| |
papapower
Registered: Aug 2021
Posts: 6 |
Great explanation, thanks |
... 2 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
