3

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?

Improve this question
2
  • 2
    I'll throw out that I think The Sentinel does all its 3d calculations during the several seconds of blanking and after that you're just doing a 2d scroll of 2d data. That's why weird barrel distortions abound. Alas I have no idea how the 2d scrolling is achieved on a C64 so I can't be any help there.
    – Tommy
    Feb 7, 2020 at 15:14
  • this question is somewhat related to this one What techniques were used to reduce the required re-rendering in 3D programs? From the look The sentinel used Freescape engine or something similar at least on ZX (but I might be wrong it even is not listed in the page ...) ... analyzing that technique might give you answer you seek
    – Spektre
    Feb 7, 2020 at 16:54

1 Answer 1

Reset to default
3

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .