C64 games mostly use the character mode in which the screen has a resolution of 40x25 characters of 8x8 ("hires") or 4x8 ("lores"; lores was most common as it allowed 2 colours plus the background colour per 4x8 character). There were exceptions, like e.g. Elite, or slow games (e.g. strategy or adventure games - the Lord of the Rings text adventure used a split screen setup using the raster interrupt to show a bitmap image on the top that was painfully slowly rendered with a tiny polygon count).
To do scrolling with the character mode you'd normally use a register to tell the graphics chip to hide 8/4 pixels on each side. You can then set the x-position and/or y-position of the viewport within that slightly reduced "window". When you've scrolled the maximum amount in one direction, the simplest approach is to wait for the vertical blank interrupt and then you copy just the 2K or less that makes up the characters on screen and whatever portion of the color attributes you need to copy. If you don't use the full height of the screen, or keep colours the same on parts of the screen, you can drastically cut the amount you copy. (Though apparently this Mario port uses VSP, which avoids the copying, but has stability problems)
Add to this that you could very precisely time things on the C64 as you can set the raster interrupt to a specific line, and the cycle count of everything on the C64 was painstakingly documented (EDIT: Though certainly not by Commodore, other than relatively high level details), and if you wanted to you could start processing the game loop while the screen was still being updated as long as you took care to ensure any rendering did not outpace the graphics rendering (if in doubt, you can check and optionally reset the raster interrupt to trigger again later on screen).
For the characters you'd use hardware sprites (most common) or you certainly could use characters "blitted" onto the screen, with the risk of making things jerky and requiring careful design as there's no way to blend against anything but the screen background colour. This was rarely done, but it happened. Barbarian II [1] at least uses that technique for at least some characters in-game, allowing bigger entities on screen (another common technique to get bigger objects is to use multiple sprites for a single in-game character). I found that out to my surprise as a child while stopping the game (which unusually for Barbarian II worked without clearing the screen) which left characters on screen representing players, not just sprites and background. Another notable one is Skyfox [2] - a 3D game where the "3D" consists of character blobs existing in multiple different sizes.
If you needed more than 8 sprites, you could use the raster interrupt to render more by resetting sprite registers after a sprite was rendered (with the caveat you could never have more than 8 on a given raster line).
To do scrolling with the character mode you'd normally use a register to tell the graphics chip to hide 8/4 pixels on each side. You can then set the x-position and/or y-position of the viewport within that slightly reduced "window". When you've scrolled the maximum amount in one direction, the simplest approach is to wait for the vertical blank interrupt and then you copy just the 2K or less that makes up the characters on screen and whatever portion of the color attributes you need to copy. If you don't use the full height of the screen, or keep colours the same on parts of the screen, you can drastically cut the amount you copy. (Though apparently this Mario port uses VSP, which avoids the copying, but has stability problems)
Add to this that you could very precisely time things on the C64 as you can set the raster interrupt to a specific line, and the cycle count of everything on the C64 was painstakingly documented (EDIT: Though certainly not by Commodore, other than relatively high level details), and if you wanted to you could start processing the game loop while the screen was still being updated as long as you took care to ensure any rendering did not outpace the graphics rendering (if in doubt, you can check and optionally reset the raster interrupt to trigger again later on screen).
For the characters you'd use hardware sprites (most common) or you certainly could use characters "blitted" onto the screen, with the risk of making things jerky and requiring careful design as there's no way to blend against anything but the screen background colour. This was rarely done, but it happened. Barbarian II [1] at least uses that technique for at least some characters in-game, allowing bigger entities on screen (another common technique to get bigger objects is to use multiple sprites for a single in-game character). I found that out to my surprise as a child while stopping the game (which unusually for Barbarian II worked without clearing the screen) which left characters on screen representing players, not just sprites and background. Another notable one is Skyfox [2] - a 3D game where the "3D" consists of character blobs existing in multiple different sizes.
If you needed more than 8 sprites, you could use the raster interrupt to render more by resetting sprite registers after a sprite was rendered (with the caveat you could never have more than 8 on a given raster line).
[1] https://www.youtube.com/watch?v=fdEZuK8PqLg
[2] https://www.youtube.com/watch?v=SurusNWvDmw