The Sentinel (aka The Sentry) on Commodore 64 - why was scrolling so fast?

Question

On the Commodore 64 3D games which use one of the bitmap screen modes were notoriously slow.

However watching a gameplay video of The Sentinel will show that in the first-person view, looking around is very fast. Conversely, when the player moves to another square the screen blanks for several seconds while calculating the new scene.

Why is looking around so fast? Does the hardware scroll work with the bitmap screen modes too? If so, what is the mechanism for adding the new pixels at the edges when it involves 3D calculations as opposed to a row of characters?

Answer 1

In The Sentinel, you cannot move the camera around, only rotate it. The lack of movement is compensated by the ability to teleport.

The camera projection is specifically chosen to eliminate any kind of parallax effect for camera rotation. This means to rotate the camera, existing screen content can easily be scrolled "out", and only newly visible landscape needs to be rendered.

In contrast, when teleporting, a full frame needs to be rendered. I haven't checked, but I expect the teleport to take considerably longer to render then a scroll step.

As a side-effect of the projection, straight lines are rendered as curved.

The absence of movement as a conceptual limitation is quite unique for a game of that era, so its rather unlikely the game is based on any exisiting engine.

Answer 2

There are two essential elements to programming such smooth scrolling on the C64:

1. Use C64 hardware scrolling, which can move the screen in single pixel increments, but only for 8 pixels.
2. Use double buffering to scroll the back buffer by 8 pixels during the time that hardware scrolling is doing the front buffer.

Since hardware scrolling and screen swapping are fast, there are a lot of cycles available over 8 frames to do the "chunky" 8 pixels worth of software scrolling. This can be done in all VIC-II graphics modes. You do have to deal with some extra complication if using color RAM, since that can't really be double buffered. One common technique is to update the color RAM during the raster by "chasing the beam" so that those color updates don't become visible until the next frame.

In the case of The Sentinel, it is apparent that the off-screen elements are too complicated to be computed in real-time while also smooth scrolling the screen plus implementing some game logic. So the long delay between scenes is probably used to compute the off-screen areas and use these pre-computed pixels for the course software scrolling. And blanking the screen during computation speeds things up a little since it eliminates VIC-II "bad lines" that normally steal CPU cycles. Farther performance could be gained if the game detected running on a C128 and also switched the CPU to 2MHz during screen blanking.