Area536 :: Rebooted

Aug 30, 2023 - 3 minute read - C64 gamedev

Leisure Suit Larry for C64

Back in 1987 Sierra OnLine released an adventure game that shaped a significant part of my “gaming upbringing”. Leisure Suit Larry may not have been very appropriate for my 10 year-old self but it was fun! Walk the guy around a city and try to get him to do all sorts of things in order to finally win the game. The game came out on the IBM PC, which is also what I played it on. Later on, I saw the very bad Amiga port and at some point I wondered why it never came out for the C64. Looking for a hobby project, I decided to bite off a lot more than I can chew and started porting the game.

Early screenshot of the game on the C64

Some research into the technical aspects of the game and its development history showed that the game was released on platforms that had at least 128KB of RAM. That tells me something about the reasons why it was never released on the C64, which has only half of that plus a bunch of other relevant limitations.

AGI game engine versus 64KB of RAM

Sierra OnLine ran a business churning out numerous graphical adventure games, which is why they had a business interest in releasing as many similar games as possible on as many platforms as possible. The early versions of King’s Quest, Space Quest and Police Quest all use versions of the Adventure Game Interpreter (AGI) engine.

The AGI engine was originally developed for 16-bit platforms and, only later, backported to a small number of 8-bit platforms that had the memory and the graphics capability to support the engine.

I quickly realized that porting Larry to the C64 would mean dropping AGI. The engine is an abstraction layer that makes it easier for Sierra’s developers to focus on creating the actual game rather than deal with the technicalities of the underlying computer. Trying to run such an engine on a computer that has half the RAM of Sierra’s minimum target spec would be quite fruitless indeed.

Hand-crafted Assembly code ensures the least overhead compared to trying to build an interpreter into the C64 that needs to indirectly drive the game. This is a viable path in this case because I’m not Sierra OnLine in the 1980’s and I don’t need to make money off my efforts to feed my family.

AGI versus the VIC-II

The way AGI draws graphics to the screen is also not compatible with the way the C64 deals with full-screen graphics. AGI draws vector graphics into an off-screen buffer and, when done, blits the result onto the visible screen. That’s not something the C64 has the memory for. The VIC-II can only address 16KB of RAM at the same time to begin with, and bitmapped graphics are constructed in such a way that blitting them into the screen is not a viable strategy.

Instead, every frame of the screen needs to change display modes two times as it is being drawn to the screen. As it happens, it’s impossible to write text onto a C64 screen while it is displaying multicolor bitmap graphics. It’s either text, or a nice bitmap. Not both of them at the same time. So for AGI to work, the screen needs to start in text mode to display the white score bar at the top. It then switches to bitmap mode to display the game’s scene background before switching back to text mode for the text input line and/or the dialogue windows.

This trick is accomplished by switching the VIC-II chip’s mode at exact positions on the screen through the use of the display’s raster beam interrupt. It works quite nicely, but the AGI engine as very definitely not built with such trickery in mind.