A: A lot of you have been asking me this. I've been playing with the idea of creating a do-it-yourself screen saver kit built around my existing screen saver code. It would be a major undertaking, but it'd be a fun project. Anyway, I'm thinking about it. The idea is to give you a very simple interface for making animations without programming, and you can cut and paste your own bitmaps together using a photo-paint program. Don't hold your breath, though, as this project would take a year if I decide it's practical.
In the meantime, the only way to make a screen saver like mine is to learn to program in either C++ or Visual Basic. The cool thing is, you only need to learn Visual Basic and VB is very easy to learn. If you've dabbled with some programming before, then here's a basic overview of how my screen savers work:
All my screen savers are written in Visual Basic 5.0 (VB5) which is a programming language for Windows 95. Visual Basic is very easy to use, unlike C or C++, and although it does take a lot of time to master, you don't have to master it to come up with something good. Case in point is my screen savers. Trust me, I'm really not that good a programmer - I just have a lot of patience.
How I got started with the screen savers is that I purchased a Visual Basic OCX control called Game-Xponents from Microhelp for $200 at a VBITS programming seminar I attended in 1996. It lets me access the DirectDraw API from VB easily. DirectDraw provides a means to draw graphics to the screen very fast - fast enough for full motion animation. I had originally purchased this control for another project I'm planning, but I attempted the screen saver first because I needed to learn what the software could do and I thought it would be an easy project. Since then, the screen savers have become this time-consuming obsession that's blotted out everything else in my life - well, except for playing Quake on-line :-)
Using DirectDraw graphics works a lot like using BitBlt API graphics calls (if you're familiar with them), except that they're easier because the OCX I purchased makes them all VB methods and events instead of API calls. You could do the same animation work with standard Windows GDI API calls, but Windows draws graphics to the screen very slowly - too slow for the kind of sophisticated animation in a game or in my screen savers. DirectDraw is much faster, and that's why all the new Win95 action games require DirectX to run - they all use DirectDraw or, in some cases, Direct3D. Traditionally, you could only get access to the DirectDraw API via C++ and only through the more arcane method of using API calls. This VB control package I purchased makes it easy to do this from Visual Basic.
The animation programming is actually very simple. To get slightly technical, all that's happening is that I have two DirectDraw surfaces - the Primary surface, which is what's on the screen, and a Buffer surface. Both are the same size as the Windows Desktop. All other bitmaps I'm using such as animation frames, etc. reside on other smaller surfaces. To render a scene I first copy the background to the Buffer, stretching it to whatever size the desktop is (all the scenes are 512 x 384 and stretched to fit the desktop from that size).
Then I have a timing loop that, every tenth of a second, has the Buffer surface copied to the Primary Surface, making it visible on the monitor. All animation bitmaps are copied to the Buffer surface, every tenth of a second before the Buffer gets copied to the Primary (this is called double-buffering). Nothing fancy, unless you're moving something across the screen, then you have to do some masking work so that what's behind the object is still visible around it and gets replaced when the object moves on - all basic animation stuff if you've done any work with BitBlt before.
As you can see, there's not much to the screen savers, really, just simple animation techniques. Once I finished the basic programming code back in the early part of the year, it hasn't changed much since then except for the addition of a few features and some additional error trapping. I built the app around a freeware Win95 screen saver whose source code was made available on a programming forum on Compuserve, so I didn't have to sweat too much about figuring out how the screensaver aspects work (like passwords, preventing ctrl-alt-del from exiting the saver, etc). If you're interested, you can download the source code for this demo screen saver:
Download the Visual Basic 4.0 version
of the JD Saver source code here...
Download the Visual Basic 5.0 version of
the JD Saver source code here...
When adding new scenes, the tedious work is setting up a nice screen shot in the game and taking all the screen shots necessary to have enough to do the animations from. Nothing sophisticated - I just sit there and tap the old F-12 screenshot key from within the game at a nice, steady rate of 10 frames per second (which is the animation speed of Quake) until I've got about 90 - 200 shots of the scene (occasionally more). There's some tricks that help me do this such as the Quake console command HOST_FRAMERATE .003 that slows down the framerate of the game so it's easier to catch the animations, and I make the weapons invisible using R_DRAWVIEWMODEL 0 so I have an unobstructed camera shot. I walk around through maps with NOTARGET enabled so the monsters don't attack me and use NOCLIP to walk through walls.
The screenshots have to include poses of any players I'm using in every conceivable position they have to be in for the scene. I used to do this with a second computer networked to mine and posing the other player accordingly - sometimes I still do when it's easier. However, I also use a shareware Quake 3D modeling program called QME that lets me load any MDL file from Quake into it and pose the model in any of it's animation frames from any view and in any position. Then I can save each frame as a bitmap.
Then comes the tedious work in a photo-paint program to crop out all the smaller parts of the screen shots that actually get animated and paste them together in a sequential series that the program can read back like movie frames - I call them filmstrips. If you open any of the .BMP files in my Unofficial Quake or Hexen Screen Saver's directory you'll see exactly what I'm doing. There's one full screen shot for each scene (all named quakeX.bmp, where X is the number of the scene) and then several files with the smaller animations, usually labled scX_N.bmp, where X is the number of the scene, and N is the animation number. The animation bitmaps look like this example of a torch:
This is the actual filmstrip bitmap of the torch on the right-hand side of the screen in the first scene, "Introduction", in my Unofficial Quake Screen Saver. I used Micrografx Picture Publisher to crop out the parts of the screenshots I need and assemble them into these filmstrips. I prefer Picture Publisher because is has a lot of automation features, but any photo-paint app would do like Corel Photo-Paint, Adobe Photoshop or even the shareware app Paint-Shop Pro. By having the screen saver show each of these 10 frames of the torch, one at a time, repeatedly at 10 frames per second, it creates the illusion of a burning torch like this:
This is exactly the same way that the code in Quake itself does it, but of course Quake itself is a far more sophisticated program than my screen saver, rendering it's scenes in a true 3D spatial context.
This is all pretty tedious to do but a lot of it I've automated thanks to Micrografx Picture Publisher. Once I show it what part of the screenshots I want cropped, it will automatically crop it out of all the screen shots and save them as separate files - then I have to paste them together as the movie strips. Even with Picture Publisher, it was tedious work and took hours to do just one animation - and some scenes have several animations in them. So eventually, I wrote a program to automated most of the work. I call it Filmstrip Maker and it allows me to do what used to take hours in just minutes. I can load all the screen shots into a directory, run Filmstrip Maker, select what part of the image I want to crop out, and what frames I want, and press a button that crops them all out and assembles the filmstrips for me. This makes life a WHOLE lot easier now, especially now that I've started work on a Quake 2 version of the screen saver. Q2's animations generally have 20 - 40 frames in them as opposed to Quake which used only 5 - 15.
Each scene has to have it's own separate filmstrips, with each frame copied to the screen at a framerate of 10 FPS. This is all done by programming, but it's very simple now that the basic screen saver engine has been written. Whether it's a torch, a a monster or a spinning pentagram, all the animations are pasted to the screen in the same way, essentially. I had to write some simple AI scenes for the players so they looked more natural moving around (you'll notice that in earlier scenes, all I had them do was stand there and breath - now they look a lot more realistic). The major programming comes in if I have to move something across the screen - like the gamer in my Unofficial Quake Screen Saver's first scene "Introduction". His run across the screen, occasionally turning towards you and shooting at you is all "hard wired" in programming. It took a couple of weeks of tedious programming to get the run to look good and it was some of the hardest work I've ever done - definitely a labor of love. That's why most of the other scenes are fairly static - when things do move, they move in one place which is far easier to do than moving them across the screen.
If you're interested, and you have VB 4 5 or 6, I have my original copy of the DirectDraw OCX from Microhelp that I used for this project available forsale. The author sent me a new version for my help in resolving some bugs. The controls are no longer available from MicroHelp, as they've gone out of business, but he's distributing them through VideoSoft as VSDirect now, and that's the new version he sent me. There's nothing wrong with the old version except for a few minor bugs, and I have all the updates and patches that brings them up to snuff. With the patches applied, there's no difference between the new DirectDraw OCX and the updated old one, and only one minor difference between the old and new DirectSound OCX which I can document for you and is not a problem anyway. I'm selling it for $40, including shipping, if you're interested (original retail was $200). It comes on a CD full of programming examples including the source code for a fully working game of Asteroids called Roids. Most of my animation code is copied from the modules in this game.
Bob Osorio - Flying Penguin[OFC] 9/6/99
The FlyingPenguin.com
