C64 Demo - Layers (Finnish Gold - 2024) - PAL 50fps

Single load (!) Commodore 64 Scene-Demo at X-2024: #2.
• C64 Demo - 13:37 (Fai...
• C64 Demo - Layers (Fi...
• C64 Demo - Das Boot (...
• C64 Demo - Sofa So Goo...
• C64 Demo - Get in the ...
---
C64 Demo Competition at X'2024

[@Kleiner82-tf8bz]

i'm a Finnish Gold member and when i saw Serato made this effect with 4 great layers my jaw dropped to the floor. amazing work!!

[@robertleeluben]

We are not worthy! Holy hell that's amazing.

[@LordmonkeyTRM]

Jaw dropping when the final layer was added

[@Asphodellife]

Indeed

[@balazsszegedy9913]

Unbelivable!

[@ingolf17]

The illusion is perfect ;)

[@rwxdesigns]

Very nice effect.

[@Asphodellife]

Indeed. Nice music too.

[@uriituw]

Quite remarkable.

[@Asphodellife]

indeed

[@cybernit3]

Wow impressive for the C64; do they use sprites for that parallax scrolling? On the Amiga you had sprite and dual playfields so it was easier.

[@Asphodellife]

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.
----
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.
serato

[@cybernit3]

@@Asphodellife Wow, thank you for explaining all this, I didn't expect this. I just thought it used rasterline sprite trickery, but there is more to it.

[@Elbas_Tardo]

@@Asphodellife Muchas gracias por las explicacion tecnica. ♥♥

[@Elbas_Tardo]

@@cybernit3 Hay muchos ejemplos donde se usa cambio de caracter que cada uno tiene su marco de animacion, asi que una animacion de 8X8 puede tener 8 diferentes, (en el video creo que son solo 4X8 multicolor), como poner por orden A B C D E F H I en la misma posicion que se repite, seria como un minivideo y las letras son los fotogramas. Como en esta demo hay que hacer mas cosas a la vez , hay que ajustar los tiempos muy bien, es todo un arte en una maquina tan limitada.

[@christianjacobi4277]

Endgeil

[@Asphodellife]

Total

[@matthiasmarx7334]

This ist NOT REAL! Muliple layer srolling?!? I cannot imagine how coding that fast code for that senior 8bit chipset. Without sounds lacking. I CANT BELIEVE!!!

[@Asphodellife]

Yeah, It's quite something!

[@serato_fig]

[@Asphodellife]

Yes (or 68 'blocks' in disk terms); extremely small.