What exactly makes up a screen in a typical C64 game?

Question

I'm trying to figure out the basics of C64 game development past BASIC, and I could use some advice on something very basic, but important: What is all that stuff on the screen actually, and how to draw it?

Take a look at Katakis/Denaris:

There are at least 9 different things on the screen:

1. The Score bar, with different fonts
2. The ship itself
3. A satellite attached to the ship, detachable
4. Secondary Weapon Projectiles
5. Primary Weapon Projectiles
6. Moving objects (can be enemy ships)
7. The Status bar, featuring an image of the ship, the number of lives and three sections that can fill
8. The primary weapon charge bar, can fill to the end
9. A scrolling starfield in the background
10. (not numbered on the screen) Solid objects like rocks or metal walls that are part of the background

The C64 only supports 8 sprites per horizontal scan line, so I don't think that everything in the middle of the screen can be a sprite? I would assume that anything requiring a collision would be a sprite (since I can get hardware collision detection with sprites), but even then I quickly hit the limit of 8 sprites. Also, my weapons can fire much more than one projectile - my ship, the satellite and 6 bullets would already be 8 sprites on a row (look at about 50 seconds into the video).

Also, which graphics mode would a game like this use? The Programming Handbook lists Bit Map Mode which essentially modifies screen memory directly. Is this the mode I should usually be working in? How would I compose all the non-sprite elements together to get them on screen?

A lot of the stuff in the score and status bar is static ("Area: 01" or the "frame"), so I guess I'll just populate them once when the level starts. Things that need updating - the score, the charge bars at the bottom - would be updated by filling the screen memory with black and then drawing the new score every frame?

Or do I have to draw the entire screen on every frame?

Answer 1

On c64 you can "multiplex" sprites. After they're drawn, you move them to new place and re-use them. Most objects in the middle are likely multiplexed sprites. In c64 it's very easy to use more than 8 sprites as long as they are not occupying same horizontal scanlines. Besides that you can actually make software sprites using font graphics if needed (projectiles atleast in this case).

2, 3, 6. Those are likely to be sprites.

4, 5, 9. Those are likely to be character graphics (8x8 pixel) software "sprites"

Game would use not bitmap mode, it would require too much moving of a memory (unless you do some VIC chip tricks...). Used mode would be character graphics mode.

What you need to draw would depend. In this case, if you look closely enough, there's certain size (x * y pixel) pattern stars are repeated so basically you'd update character memory of those fonts to emulate scrolling of starfield.

Score/status you populate on start, and then update them when needed.

You would have to update sprites and their position each frame. You would also update projectiles. Also you would update that x * y pixel starfield pattern.

Answer 2

I read an article some time ago in the german C64 Magazine. The bullets are characters that act as sprites as someone already pointed out. Ship and enemies are sprites.

Levels are made of characters also but with a twist. Since the levels are so huge, and memory is precious, Trenz wrote his own set of tools to group characters into modules.

So he can use bigger modules and compose those. Also he would use certain patch-modules to get the intersection of modules nice and clean.

All in all its a kind of compression, where levels are described building blocks instead of char by char.

Also you might noticed that in Katakis some levels have parallax backgrounds.

That is made by having a pattern to fill the background, mostly made of 2x2 or 3x3 characters, and animating it (bit-shifting) against the direction of scrolling. E.g. the level scrolls 2 pixels to the left, the background-pattern is scrolled 1 pixel to the right, hence it appears to be scrolled at a slower pace.

Hope that helps

One more thing you can actually see the single modules and such here https://archive.org/details/64er_1989_10/page/n27 scroll to page 24