View Single Post
Old 12 October 2019, 20:36   #1
Registered User

Join Date: Jan 2016
Location: Santa Cruz/US
Posts: 45
Comprehensive guide to Bobs

Hello all. Since there's a new thread about bobs I thought I would wrap up this post that I started a while back.

I've never seen a comprehensive guide on how to create bobs and have them move over a background. For a beginner there are several gotchas and here's my attempt at describing how it works.

In the very simplest form, a bob is just a simple blit of graphics data (source channel A) onto the screen (destination channel D), using minterm $9f0. Many people probably wouldn't call this a bob though, since it isn't moving. The first gotcha is that the destination address can only be a multiple of 16 pixels. In order to place the bob on any x position you need to use the shift blitter operation, and shift the bob up to 15 pixels to the right. You then run into the next gotcha - if you shift data to the right it gets shifted into the left again. To get around that you need to add 16 pixels of blank space at the end of each bob line, i.e. your bob graphics is 16px wider than it normally would be.

Now, if you want a bob with multiple colors you need to do a blit for every bitplane. That can become expensive so you can instead define your screen and bob graphics in interleaved mode, when a single (albeit bigger) blit is enough.

If your screen has a background it gets more complex, since the simple blit will overwrite the background for the bob pixels that are meant to be transparent. You then do what is referred to as a "Cookie-Cutter" blit. For Source A you point to an outline of the bob, which then acts like a mask. Source B is set to the bob graphics, Source C is the background, and Destination D is also the background, and the minterm used is $fca. If you use interleaved mode the mask needs to be duplicated for each bitplane, which is a drawback with the interleaved mode.

To move a bob you need to blit it to the new position, but the problem is that the graphics for the previous position will then still be shown on the screen. If you don't have a background you can simply clear the area of the previous position before blitting to the new position, e.g. using the blitter. But if you have a background you need to instead restore the background of the previous bob position. One way to do this is to use a buffer that stores the previous background for each bob. Here are the steps needed to be done every time you want to move a bob: 1. Restore the background of the previous position by copying from the buffer to the screen. Not necessary if the bob hasn't move yet. 2. Copy the background where you're going to blit into the buffer. 3. Blit the bob using the Cookie-Cutter blit. Note that #1 and #2 can be done with simple A->D blits.

If the background is static you can instead restore the background by keeping a copy of the background graphics in a separate, read-only, buffer. Before you blit the bob to the new position you restore the background of the previous position by copying from the buffer to the screen, using a simple A->D blit.

Finally, if you draw a lot of things on the screen there may not be enough time to do that in one frame. You can then use a double buffering scheme. You essentially have two screens, each stored in a buffer. One that is shown and one that you draw on. Every vertical blank you flip the bitplane pointers to point to the buffer you just drew on, and then you draw on the other one. If you restore the background of each bobs by storing off the previous bob position it gets a little more complex, since you now actually need to use two previous position buffers, one for each screen.

OK, that's what I have so far. If the background scrolls it gets more complicated - I haven't really thought through that yet. And I also know that roondar has an article on "fast bobs" using dual playfields, which I haven't processed yet.

Knocker is offline  
Page generated in 0.04141 seconds with 11 queries