Commodore 64 sprites vs background mystery

[maiki]

Hi, is there any C64 guru who knows how the games like Fist II or Platoon handle the sprites vs background appearance?

 

As far as I know, normally on C64 you can either bring sprites in front of graphics or behind it. BUT Fist II for example does BOTH of them at one time... just see this video how the guys hide behind rocks but still appear in front of background. This is not normally possible on VIC chip, and C64 has no multiple playfields either.

 

I was just wondering what kind of trick is that...

 

Fist II C64 sprites vs background/foreground

[Rybags]

You can dynamically switch priority, such as if the player moves near a certain object, although the complexities there make it a bit impractical, ie you'd need to assure there won't be anything that should be behind appearing in front.

You could switch priority part way down the screen, I'd guess Platoon might well do that.

 

Or, you can hide the sprite behind another sprite which acts as part of the background.

Pretty sure Last Ninja does the same.

 

You could do both the above. You could even go so far as applying a background mask to the sprite data to AND out stuff you don't want seen, although that's a lot of number crunching to achieve what might be easily doable with the hardware anyway.

 

Some of the early, buggy '64s were good for detecting stuff like that (the ones that had the unwanted sparkles that appears around sprites).

Edited April 25, 2009 by Rybags

[maiki]

You can dynamically switch priority.

Or, you can hide the sprite behind another sprite which acts as part of the background.

 

 

I don't get it, how one can change priorities so that the sprite is both behind rock and in front of the background. Also, the huge amount of pixels used for the rocks in Fist II is hardly sprite graphics...

[Jetboot Jack]

Last Ninja uses masks to punch holes in sprites, allowing a simulation of isometric masking- the sprites are in front of everything, but the masks make it appear as if foreground objects are actually in front of sprites when they are not...

 

Platoon looks like a simple horizontal split to change/control priority...

 

sTeVE

[maiki]

Platoon looks like a simple horizontal split to change/control priority...

 

sTeVE

 

 

so you say that the code selects when the sprite is hidden or not during the scanline (horizontal position)?

[Jetboot Jack]

As to Fist 2 - I think this explains it (from codebase 64):

 

Multicolor text mode

 

(You'd generally set this up with: $d011=$1b, $d016=216)

 

This mode allows for displaying four-colored characters at the cost of horizontal resolution. If bit 3 of the corresponding $d800 color is zero, the character is displayed as in standard text mode with only the colors 0-7 available for the foreground. If bit 3 of the corresponding $d800 color is 1, each two adjacent bits of the dot matrix form one pixel. By this means, the resolution of a character of reduced to 4×8 (the pixels are twice as wide, so the total width of the characters doesn't change).

 

It is interesting that not only the bit combination “00” but also “01” is regarded as “background” for the sprite priority and collision detection.

 

Platoon - an interrupt makes the priority change at a fixed vertical position on the screen - combined with the above would give you platoon's effect I imagine...

 

[maiki]

I think I am getting the Platoon trick... simply track a portion of the sprite and if any bush is there, hide it

 

Well that describes how multicolor mode works... but it doesn't say anything about sprites vs background priorities... the question is, if the fighters in Fist 2 are hardware or software sprites of course... but it can be similar to Platoon...

[landgraf]

It is interesting that not only the bit combination “00” but also “01” is regarded as “background” for the sprite priority and collision detection.

 

That feature is used for the caves in Fist II. The fighters are hardwaresprites with sprite to background priority set to background, the walls that appear in front of the fighters use bit combinations 10 and 11, while the background walls and the floor use 00 and 01. Sprites will always appear on top of the latter two bitcombos, regardless of the state of the sprite to background priority.

[Jetboot Jack]

maiki said "Well that describes how multicolor mode works... but it doesn't say anything about sprites vs background priorities"

 

Yes it does - and I quote "It is interesting that not only the bit combination “00” but also “01” is regarded as “background” for the sprite priority and collision detection"

 

So in MC mode pixels of 00 AND pixels of 01 bits are BEHIND all sprites - hence the 2 color graphics behind the Fist 2 characters when they themselves are behind the 2 color cave walls

 

sTeVE

[maiki]

OK. So, in order to have something in front and something in the back, you have to use MC mode, right?

 

 

What is 00,01,10,11 bit?

 

Is that the color code for the pixels? You set the priorities by color design?

[Jetboot Jack]

From what I read it appears it is MC mode that allows this feature on the C64

 

And yes each char in MC mode is 4 pixels wide on screen, but is actually a full 8bit wide character in memory - so each bit pair represents one pixel 00, 01, 10, 11 and there are 4 possible colors...

 

sTeVE

[Video]

Multi color allows for up to four colors per sprite, but at half the width. I've never seen the game in question, but it may be that the 64 could push enough sprites to simply overlay some er "background" as sprites. Though you can assign different colors to have priority or give it to the sprite, it's really fun when you give a back background object priority over sprites while front background objects give priority to sprites, makes for some interesting effects, I think Relm of Impossibiility did this.

[johncl]

Old thread, but I just wanted to point out that indeed the C64 has a multicolor character mode where each pixel is paired with the next one effectively making chars 4x8 resolution but at double width. Which is why you see those wide pixels on many C64 games. The same thing goes for sprites. And essentially its was not a bad thing on a bad PAL/NTSC composite signal where you wouldnt be able to see the pixels that well defined anyway in the horizontal resolution.

 

Furthermore as people have pointed out the special sprite to background priority was one of the nice features of the C64 but it had a fun little "quirk" in that both bit pairs 00 (background) and 01 (multicolor 1) was considered background, so that the sprite would be in front of these in all cases even when you set the sprite to be behind "chars". While some would "palmface" at this design constraint, games like Fist II used this to its fullest enabling the sprite to move in a charset environment with a somewhat detailed 2-colour foreground and 2-colour background imagery.

 

However a disadvantage was that multicolour char mode had a nasty limitation, you could only use the lower 0-7 colours as character color (bit pairs 11) as the colour set for that particular character defined whether the char was in multicolor mode or standard highres. So your normally 16 char colour option was reduced to the first 8 as the 4th bit in the char colour memory decides if its multicolor or not. Its a bit tricky to understand from writing, but essentially when you set the char colour to e.g. light blue, the actual char colour would be standard blue for the bit pairs 11 in the char data. For multicolor 1 and 2 as well as the background you could select any of the 16 colours.

 

To make matters even worse, many of the good colours were in the upper indexes 8-15: brown, light red (pink/skin colour), dark brown, 3 greys, light blue and light green. That meant if you wanted to e.g. use all 3 greys in your multicolor charset you would have to set background to dark gray, mc1 to grey and mc2 to light grey. You were then limited to the lower 8 index bog standard colours for the char colour (black,white,red,cyan,purple,green,blue,yellow).

 

Many like to bash the muted pallette of the C64, but in my opinion one of the strengths of the C64 pallette is the many greys and "earthly colours" which makes it ideal for many games featuring some kind of nature. The nice skin colours help a bit too naturally. Save the bright colours are for spectrums and Las Vegas.

 

Anyway, you can imagine the interesting challenges a C64 graphics artist is often facing when selecting colours! Lets say your game needs some trees, ah wonderful, we have two browns and two greens. Splendid! Hey wait a minute, hmmm... both browns and light greens are in the upper indexes... Dang. Ok so we need to reserve both MC1 and MC2 as well as BG for these three colours and we can use the standard green as char colour. Voila a pretty tree! Hmm, but the whole background of the game is now either light green, brown or dark brown. Oh oh I want a green grassy floor with dirt underneath, no problemo, colours are all ready to be used. Oh and I want a blue sky using both blues!... Hmmm... one blue is char colour, but the light blue is upper index colour! And my green tree cant use green char colour on the chars that are also partly sky. Dang!

 

This is where the artist and coder has to come up with trickery to enable more colours "in the mix", and it is possible to change both MC1, MC2 as well as BG for every scanline if you so wish with some raster code. In our example, we could use the light green on the edges of the foliage of the tree with holes in them to let the blue shine through (as we have changed our char colour for those tiles from green to blue). Additionally we could change the light green MC colour to a light blue when the trunk begins to use the light blue for a sky gradient at the horizon, and then swap it back to light green when the ground begins. Now if you want rolling hills in your background scenery you would have to use char colour green on those tiles and save the light green details for when the sky is finished. Many tricks are possible with some smart use of char colour and changing them on the fly during the drawing. For C64 enthusiasts, pause the games you play and try to figure out what colours are used where for BG, MC1 and MC2 as well as char colour. Sometimes you will be surprised at what they chose. Some games have a black background, and you might immediately think, they have set the background to black, but what they often do is use char colour black and the real background colour shines through the "holes" drawn in the chars whenever needed. In most cases this is because the game required the use of 3 upper index colours.

 

In many cases you have to make sacrifices and e.g drop one colour so that you have more freedom with the char colour to add detail. In some cases you resort to sprites for some missing details although that will again limit your use of sprites on top of the scene since there are maximum 8 on any one horizontal scanline (you can multiplex and reuse sprites on different scanline locations with some limitations). Additionally, the sprites also has a nasty limit, their multicolour indexes are shared between all sprites (much like chars but the registers are different so you can have other colours for sprites multicolours). But you are at least free to use all 16 colors as the sprite colour. Again, you can change sprite colours at any raster to get more colours here as well if the sprites are spread vertically (for SMC1 and SMC2 colours at least). Atari 2600 programmers know all about changing colours for every raster so it shouldn't be a surprise this trick is often used on the C64 too.

 

The multicolour char and sprite modes are important features of why the C64 became so popular as it enabled a rich visual style at a time where home computers often had single colour chars and a small pallette (the Atari 2600 being an exception on the palette selection naturally, although very limiting in every other aspect of graphics). But it comes with a price as you have seen, and for the C64 graphics coder it often becomes a challenge to find the best tricks to enable as much use of the 16 colour palette as possible, much like an Atari 2600 coders challenge to squeeze as much out of every rasterline the code sets up. Both equally fun for a seasoned programmer.

Edited December 30, 2011 by johncl

[oky2000]

On 12/30/2011 at 10:50 AM, johncl said:

....as people have pointed out the special sprite to background priority was one of the nice features of the C64 but it had a fun little "quirk" in that both bit pairs 00 (background) and 01 (multicolor 1) was considered background, so that the sprite would be in front of these in all cases even when you set the sprite to be behind "chars". While some would "palmface" at this design constraint, games like Fist II used this to its fullest enabling the sprite to move in a charset environment with a somewhat detailed 2-colour foreground and 2-colour background imagery.

 

However a disadvantage was that multicolour char mode had a nasty limitation, you could only use the lower 0-7 colours as character color (bit pairs 11) as the colour set for that particular character defined whether the char was in multicolor mode or standard highres. So your normally 16 char colour option was reduced to the first 8 as the 4th bit in the char colour memory decides if its multicolor or not. Its a bit tricky to understand from writing, but essentially when you set the char colour to e.g. light blue, the actual char colour would be standard blue for the bit pairs 11 in the char data. For multicolor 1 and 2 as well as the background you could select any of the 16 colours.

 

The 2 colours = background, 2 colours = foreground is very useful. If you were to do a conversion of Konami's Chequered Flag arcade you would do the green and light green of trees as bit colours 10 and 11 but the road tarmac and shadows of the treetops on the road as colours 00 and 01 you get the effect of the car sprite driving on the road and over the shadows BUT driving under the tree tops for no CPU time at all. This is a feature few used properly, you have to fully understand how the VIC-II works to do the best of the best games.

 

The switching between hi-res and multicolor mode in a 16 pixel wide area is not a disadvantage either, if you are drawing in an area that is only two colours anyway say on the ground in a Zelda type top down scrolling RPG you can choose to go hi-res in that character block. This is also another unique advantage.

 

There is also extended background mode too, which with careful design you can get the benefits of 8kb hi-res bitmap modes (i.e. change both foreground and background colours every 8x8 pixel area) but only have to modify a 1kb screen. If you want to do Smurf Rescue from Colecovision this is the mode you would have to do, with raster splits for status displays back to regular text mode with 256 character combinations. The limitation of EBC mode being you can only specify character 0 to 63 to put on the screen. 64 used designed graphic characters for an actual game window is perfectly fine for some games. Delta only uses the non sprite pixels for the starfield alone, the rest of the display is a pure VCS style race the beam sprites everywhere (inc borders) type tech demo...with a free bullet hell rock hard shmup thrown in for free. If you can do everything Delta does with sprites and then max out the VIC-II non sprite pixel hardware you get games like Enforcer - Full Metal Blaster, which is easily as good as the best Famicom (Crysis Force) or SMS (R-Type?) shmups.  

 

In the right hands you get games like Law of the West which had visuals that could only be replicated on EGA or Atari ST due to the sheer size of sprite pixels with independent palette and all the niceties of the C64 palette being fully used for foreground/background every 8x8 pixels in 320x200 mode. 

 

Pain in the ass bitmap mode for doing games like Elite or Rescue on Fractalus (which is poorly coded by the n00b who wrote that C64 Shamus game as his 'experience') Demo coders have doubled the framerate on 4 colour multicolor fractal game engines already.