Contents  Introduction  Rotation Solution  The Sound Module  One Big Headache  Screen Transitions  Putting More Pieces  Together  Until Next Time  Printable version     The Series  Part 1  Part 2  Part 3  Part 4  Part 5  Part 6

Screen Transitions

Screen Transitions are things that are usually fun to write. Of course, most anything would be fun after playing with DirectSound. The screen transition is often one of the most important things in a game. If you have a lot of places where the view/screen completely changes, then a transition is typically needed in order to smooth things out. You do not want the user to just be "jarred" to the next scene. To the user, a transition is like riding in a Lexus, while having none is like riding an old Pan-head << inside motorcycle joke >>.

I have taken an interesting approach with the screen transitions in this game. I decided there would be one main interface function. This function, intelligently called Transition(), is responsible for selecting a screen transition, at random, and calling it. This provides some break from the monotony of calling the same one over and over again. Of course, I have only provided one simple transition ( with 2 options ), it is your job to write more. All transitions require the surface you want to transition "from" on the primary buffer, and the surface you want to transition "to" on the back buffer.

Here is the code for the interface function:

The Transition() function grabs a random number by using the same method as our random shape generator, obtaining the time. This is not the optimum method, and we will be replacing it with a true random number generator later on. But, for now, it will have to do. The proper transition is then made based on the time, you can play with the parameters if you wish. I just selected a couple that didn't seem to take away too much of the screen each iteration.

That is all that is there for the management function. It just keeps things random. You can still call a transition directly, I just thought it was more interesting to do it like this. Besides, on a large project, after 4-6 months of looking at the same transitions, you would probably be insane.

Now, we can look at the actual screen transition: Wipe_Trans(). This routine allows us to perform either a vertical (top to bottom) or horizontal (left to right) transition taking away a width that is passed in each time. So, have a look at the code before we continue.

Notice, the first thing we do is setup the source and destination rectangles. We are going to be working with "strips" of the bitmap. So, I am going to walk you through exactly what happens when the routine is called.

Pretend the user passed in a 7 for the "strip_width" parameter and they want a horizontal transition. The first section finds out if the strip's width can go evenly into the screen width. If the strip can go in evenly, then it sets the length to be equal to the width. However, if it can't, then the remainder is placed in the width. The reason we place the remainder in, is that the strip is going to have that little strip left over when we finish. Example: with a 7 and a screen width of 640 you will have 91 sections of 7 and a section of 3 left over. So, for the first strip we would store a 3 for the width. From here on note: You would do the exact same thing, except for the height/top/bottom, if you were doing a vertical wipe.

Next, we blit that small 3 pixel strip over from the back buffer onto the primary buffer. With that out of the way we can get setup to do blits with a 7-pixel width. The way we setup is by moving the right-hand side of the rectangle over to the left-hand side. Then, we add the strip_width, in this case 7, to the left-hand side to obtain the new right-hand side. So, for our example, the left coordinate of the rectangles would now have a 3, and the right coordinate would now have a 10. We need this adjustment since our loop is only going to work with 7-pixel strips in the bitmap, instead of an increasing portion of the bitmap.

We are now ready to delve into our loop. The first thing we do, aside from getting the starting time, is blit the current strip (this is why we had to setup the rectangles out of the loop). Then, we check the right hand side and bottom of our source rectangle is still inside the limits of our screen. If it has met the extents, then we break from the loop since we are finished. If we haven't yet reached the edges, then we adjust the rectangles. To adjust the rectangles, we add the strip_width to both the left and right of our source and destination rectangles. By adding to both sides we are able to blit in strips of 7-pixels. But, if we only added to the right-hand side we would blit in pixels of 7, 14, 21, etc. Which, needless to say, is much, much slower than the way we are doing it. Finally, we synchronize the time to our desired rate and keep doing the loop until we are finished.

There isn't very much to the routine, but it should give you a starting point in making screen transitions. Here are some suggestions in case you are lacking in creativity. Make a modified wipe that would have a bunch of strips at intervals grow to meet each other, like something you would see with a pair of blinds in your house. Design a transition that zooms in to a single pixel, then zooms out to the new picture. Create a circular wipe, or even a spiral one. There are many good articles out there on demo effects and I suggest reading some of them if you find this stuff interesting. Finally, if you are really desperate for an idea, just go and play a game and see how their transitions work. Mimicry is one of the first steps in learning.

At any rate, everything in our modules is complete. We now have everything that we need to pretty up the game. So, in the next section, we will tie everything into that nice little bow, just as we always do.

Next : Putting More Pieces Together