Duality ZF is an upcoming dual play 2D shooter (shoot'em up / shmup) for the Xbox 360, PlayStation 3, and PC.

Release date: temporarily delayed.

My Graphics Technology Project is the development of a revolutionary computer graphics technology. I have placed one hundred percent of my effort into this project for over four years. My brother, Matthew Doucette, has joined my effort.

However, it has been placed on hold to pursue the Duality ZF project. Thus we are uncertain as to when we will return to this project to finalize it.

Domain Hacks Suggest is an analysis of 580,500 words and short phrases from Grady Ward's Moby Word list (also available at Project Gutenburg). The result is 301,808 domain hacks. This was my first programming exercise in Python.

Screen Shot:

xona.com/domainhacks/suggest

AntiSpam Mailto (previously named Email Address Encryptor) is an email address encryptor / obfuscator program. It will encrypt the 'mailto:' HTML code that contains your clickable email address with JavaScript. This allows you to publish a fully functional email address link on your website that is invisible to the majority of spammer's harvesters.

Full description: xona.com/antispammailto

Screen Shot:

ZoomView is a real time desktop magnifier program for Microsoft Windows. It enlarges the visible screen area centered on the current mouse position, so you can take a closer look.

Full description: xona.com/zoomview

Screen Shot:

Full Tilt is a 3D sprite-based racing game (Out-Run tribute) designed and created for my final year project (COMP 4983) at Acadia University. The project was finished in a period of ten weeks. This time span includes the proposal, design, implementation and testing of the final product, as well as the documentation.

I chose to program Full Tilt because I have been an avid Out-Run fan since the game showed up in the arcades in 1986. It is popular enough that it is still found in arcades today, over a decade after its release. Classic arcade titles such as Out-Run have always seemed to avoid the PC scene, and when they did show up, the arcade feel was gone. You will notice some of the pictures are the exact images borrowed from the original Out-Run game ROM (most of them slightly modified), and the rest were drawn by myself or created with my programs. For example, the car was rendered by a gouraud shading program I created, using a design created by a mathematical formula that I threw together in a couple of hours. I also could not help throwing in an image of Crowell Tower, my place of residence during my four years at Acadia University.

I designed and programmed a GW-BASIC version of the simple scan-line road engine that these classic arcade racing games used when I was in grade VIII, and decided to call my yet-to-be-made game Full Tilt. Although the engine was coded again from scratch, the engine used in Full Tilt is the same original design. It was chosen because of its speed and simplicity.

The purpose of the project was to showcase my abilities to create a 3D game. It should be noted that this code is all original and self-taught. This includes all algorithms, high-level language, assembly language... everything.

This project showcases the following:

• Sub-Pixel Accurate, Sub-Texel Sprite Drawing.
• Correct 3D Perspective (Out-Run cheated on this to reduce the number of sprites drawn)
• Compiled Sprites
• High-Resolution Timer handling
• Frame Rate Consistency
• Memory Management
• Palette Management
• Keyboard Handling
• Joystick Handling
• Collision Detection
• Limited Car Physics Model

The game has no music or sound effects, as it was not part of the original schedule. I regret that I did not have extra time to program this then, and that I do not have time for it now. As for other details, a few minor things are missing, such as smoke from squealing tires, dirt spinning up from off-roading, and other similar effects that would add more to the game. I would like to eventually port this game over to a fully blown arcade game using hardware accelerated graphics.

The project was never meant to be a true or accurate simulation of a real car, although it incorporates many of the physics required - such as aerodynamics, drag force, acceleration, braking, traction, etc. Such things as centripetal force, weight transfer, and an accurate model of rotational inertia in real 3D were left out due to time constraints, and due to the fact the game was only meant to be a classic arcade game.

My best time is 5:19.283 with a score of 94,450,468 points. You get approximately 48,000,000 points for traveling the full distance of the game (if you do it fast) plus 1,000,000 points per second left on the clock. This was not a perfect run, so it is possible to beat. In fact, on another occasion, I got a time of 5:25.something in which I crashed on the first lap. The remaining laps were run as perfectly as I could ever accomplish. My first lap time was 1:04.something, but it is possible to do it in 56.something, meaning I could have run the first lap 7 seconds quicker. This means that a complete run of 5:17.something is possible.

The program should run on a 386+ processor with an FPU, but a Pentium processor is recommended. It was coded on a 200 MHz AMD-K6, and runs near frame rate during most of the game on this machine.

Note: The game requires EMS memory. The game comes with a .PIF (program information file) file that is already configured to allow the game to use EMS memory for a Windows XP system. Please refer to the README.TXT file to see how this .PIF file was created. For Windows 9X systems, the README.TXT file gives information on how to configure your system to allow use of EMS, if the .PIF file does not work.

Space Harrier tribute is a 3D arcade shoot 'em up (shmup) game. Although the engine has been partially started, it is still in the design stages. The game version number is just that of the software engine itself. The game currently runs in all standard and tweaked VGA modes. It runs 65-70+ frames per second in 320x200 and 25-30 frames per second in 640x400 on an AMD K6-200 (Pentium-133 equivalent), with 250 on-screen bullets firing at 160+ shots / second. (7 shots/fire @ 23.3 fires/second).

320x200 Screen Shots:

640x400 Screen Shots:

There are no downloads available at this time.

The sprites in the engine-testing screen shots are all low resolution, borrowed from Space Harrier II and Super Thunder Blade ROMs, both for the Sega Genesis / Mega Drive. The final game (if ever completed) will run on most 3D accelerated cards, and will run at a hefty frame rate, even on non-accelerated (software) machines. This means 30 frames per second minimum, in software. It will run at the monitor refresh rate (as smooth as the hardware allows - 60 to 70 frames per second) on all accelerated machines, and will approach this on non-accelerated machines. It will be the pure smooth and fast arcade shooter that has been absent from the PC scene forever. The vision is a three dimensional Thunder Force 2 (for the Sega Genesis / Mega Drive). The goal is to replicate the pure arcade action feel.

Arkanoid '97 is a game that was never totally completed. This demo is just the engine itself. The only incentive I had to program it to begin with was that the game is an addictive game, and most tributes are poorly and incorrectly programmed, which hurts the game's true appeal.

The game was programmed in 360x360 mode X for its 70 Hz frame rate, and its relatively high resolution. It uses 16.16 fixed point for extremely accurate calculations of ball angle and speed. The balls are all drawn with pixel-perfect anti-aliasing with the textured background in real-time. It is impossible to improve the image quality without increasing resolution or colors because the anti-aliasing is already perfect. (Today's 3D accelerated graphics cards that support anti-aliasing cannot perform pixel-perfect anti-aliasing.) The program uses double buffering to its full potential to allow the game to run at 70 frames per second with 75 balls bouncing around the screen on a 486 class machine.

My version is the first version of this game I have ever seen to use proper physics during the collision of a circular ball with a 90° corner (including the original arcade, Arkanoid, and the original classic, Break-Out). The ball can collide with the corner at any angle, and at any point on the ball. I have seen lots of tributes, and it seems to be that the consensus is that Arkanoid is considered a fairly simple game to create. This is because the only collision detection ever programmed into the tributes are collisions at horizontal and vertical walls (simple negation of X velocity and Y velocity accomplishes this), and sometimes even a 45° wall (accomplished by swapping X and Y and negation). Yet, this makes for a boring and often extremely annoying game. You can just imagine the repetitious patterns that are created from this. Also, half of the tributes (as well as the original arcade) sometimes cannot detect that two adjacent blocks form a smooth surface, and not two 90° corners which the ball may arbitrarily hit. This is poor programming, indeed.

I may complete and release a commercial product of this engine demo to prove that this game actually has great potential to be an addictive game.

Mode-X Screen Shots (360x480, 360x360):

Download: Arkanoid '97 Non-Playable Demo (198KB)

There are 256 balls in the demo version. The program is compiled with TMT Pascal. The 360x360 video mode will work on any 100% register compatible VGA card. I do not hold any responsibility for the program destroying your video card because it can not handle the tweaked mode. On most of today's monitors, this mode does not fill up the entire screen, but usually appears in a letter-box format. This is not what is intended. Please resize the screen to fill up the monitor space, as all other screen modes do. On most of today's monitors, this is done electronically, and it will save these settings the next time you run a program that uses this particular mode. The reason I chose this mode is because, at the time, it was the highest resolution mode with double buffering (i.e. enough space to store, work and display two different screens of information) that I had access to.

Spring Theory is a real time physics simulation of springs. It has gravity and friction incorporated into the engine. This program is truly amazing - you will have to see it in motion to appreciate its accuracy. Please note that object collisions with themselves are not implemented - therefore two separate sections of the same object may travel through each other. Press F1 during the demo for help on controls.

Each time an object is displayed, it is given a random amount of energy (press SPACE to reset the object with new random energy), therefore it will fall and flop around in a different way every time. You can control the friction in real time, which also affects the object in dramatic ways. For instance, in the second picture below, the object is stuck in this position, since the friction is holding it against the wall, and on the floor. If you were to reduce friction, the object will flop to the floor.

Screen Shots:

Download: Spring Theory (17KB)

This should run on any 386+ machine. However, it has been recompiled for today's faster computers. You will need at least a 200 MHz machine to see the animation at the desired 70 frames per second for most objects. Watch for my next version of this program in full 3D.

SI'97 was originally programmed in one day (no kidding) as a result of a boring day at work. It had been a project that I have wanted to do since I have been in grade III, and I have finally set aside some time to create it.

After I showed a few people the game, they kept throwing ideas at me, and every once in a while I would take a half-hour out of the day to program one of them. Because of this, I have implemented lots of ideas and features, and the game has had a ridiculous amount of beta-testing.

The game is surprisingly addictive; any fan of the original game will surely enjoy it. I believe especially that those who think the classics and tributes could have increased excitement will find it to be a refreshing change.

Some Features:

• Fast customizable controls (you chose your keys for every game) / joystick support.
• Up to 4-player co-operative simultaneous play.
• Multiple incremental power ups:
  • More bullets on-screen at once.
  • Protection Shields.
  • Spread Fire.
  • Invincibility Shields (can be used to protect more than one player - interesting).
  • Rapid Fire (bullets travel faster).
  • Auto Fire (Auto-repeat fire up to 35 fires/second).
  • Shoot-Thru Shields.
  • Etc.
• Icon Showers that offer occasional bursts of power ups.
• Ability to steal men from other players when your game is over, which is recorded.
• Ability to return stolen men (automatically achieved when player receives a new man).
• Extended Play feature that allows a player, whose game is over, to continue. This occurs when you gain another man from either a score increase due to your final bullets killing one or more enemies, or a returned man from a player who borrowed it.
• Proper scoring:
  • Each player receives the percentage of the total he/she contributes to killing each enemy, as well as for the bonus points he/she contributes to completing a wave. This prevents weaker players from hiding behind shields while gaining huge bonus points for waves completed in levels they would otherwise not reach. They only receive the percentage they contributed to the destruction of each wave.
  • Proper percentage of scored points are sent to those players who you have borrowed men from (Example 1: If you borrowed the same amount of men as you have used from your own supply, you, and the person you borrowed the men from, each receive 50% of what you score. Example 2: If you borrow twice as many men from player 1 as from player 2, player 1 will receive twice as many of your points as player 2 will. Example 3: If you have used 3 of your men, and borrowed 1 man from 3 other players, you will receive 50% of what you score, and the other 3 players will receive an even split of the remaining 50%).
• High Score table stores every game played with numerous statistics including score, levels completed, game time, fastest level time, number of bullets fired, number of hits, percentage hits, number of enemies killed, number of men used, borrowed, and lent, number of pauses, number of pauses per minute (an indication of cheating), number of bullets destroyed with invincibility shield, number of points lost or gained due to borrowed or lent men, time / date of play, number of simultaneous players, even the current ranking and percentage rank of the time of play (so you can see an older high score that used to be the highest score), etc.
• The High Score file is encrypted to deter hackers from entering in fake scores.
• On-Screen statistics:
  • Contribution Bar during multi-player (to answer the question of who is pulling their own weight).
  • How many men you have, you have used, and borrowed.
  • The current level (Grandmother, Normal, or Insane) of play, to deter people from always choosing Grandmother level and stating otherwise.
• Fairness judgment when more than one player tries to receive the same power up (to combat against players who try to steal them all for him/herself).
• Pixel perfect accuracy during all collision detection (most new players die by moving around too much. If a bullet is just going to scratch the edge of your ship, you are in no danger, and you need not move).
• Player bullets match the color of their ship, since good players don't look at their ship to know where they are, but at the stream of bullets it shoots. With different colored bullets, multiple players can play easily without being confused about which stream of bullets is their own.
• There are more, but I can not think of anything else at this time.

The musical score was composed by Matthew Doucette, and the sounds effects were ripped out of a data file from Epic MegaGames' Jazz JackRabbit.

Screen Shots:

The original graphics were quite sub-par, as I ran out of time by the end of the day to draw enemies for the game. Thus, the game originally used the system font in ROM for the enemies, which varied from system to system. Now, it still uses the same text drawing procedure, but it uses an 8x14 text font which was created using an old font-drawing program (on this same page) of mine to allow a few frames of animation. Enjoy!

Download: SI'97 v5.0 (304KB)

The game was programmed on a 486-66 MHz machine, and thus it was designed to run at or near full frame rate (70 fps) on a 486 class machine. A few minor improvements have been made since then on a 200 MHz machine, which have not been tested on the older 486, and therefore the game may now run a little slower. To ensure a consistently smooth frame rate of 70 fps, I would recommend a 200+ MHz system.

The game's sound system is CapaPlay, which unfortunately only supports the Gravis UltraSound (GUS) sound card. The game runs without sound, but you will miss the stereo effects and soundtrack that add a lot to the game. Please note that if you do have a GUS, the sound system will not work properly if ULTRAMID (a program that comes with the Gravis UltraSound) has been run. This is a bug in the sound system, not in my code.

Voxel Terrain is a full 3D photo-realistic terrain rendering engine. The technology was developed independently in two week's time. The code is 100% original and self taught. The detail level can be fully adjusted at each level of distance for any resolution. This is limited only by memory capacity and CPU speed. It currently runs under any Mode-X resolution. There is a lot of room for improvement. I have a ton of original ideas and additions that could be made to this engine.

VOXEL TECHNOLOGY
WITNESS THE POWER OF A 486 CLASS MACHINE:
320x400 Mode-X Screen Shots (scaled to 640x480):

The program runs on a 386+ machine. It does not run in virtual environments. This means a DOS shell from Windows will not work. You need to run the demo from DOS, booting the computer with HIMEM.SYS and without EMM386. If you are running Windows 9X, you can simply restart your computer in MS-DOS mode. You will have to REM out the EMM386 line in your CONFIG.SYS file, if it exists. If you are running Windows ME, you will need to set the application's properties to automatically reboot in DOS mode with the appropriate start up information. Do this by right-clicking on the application, and select 'Properties'. Click on the 'Program' tab. Click the 'Advanced' button. Check 'MS-DOS mode'. Select 'Specify a new MS-DOS configuration'. Place the line: "Device=C:\WINDOWS\Himem.Sys" under CONFIG.SYS, and erase all other lines. Erase all lines in AUTOEXEC.BAT. The program will now run in the proper MS-DOS settings by rebooting the computer when you attempt to run the program.

The program uses triple buffering in Mode-X for shear-free animation. It is known that some video cards do not perform well in Mode-X. I have tested this program on a 400 MHz machine, and it barely performed better than my AMD K6-200 MHz machine (only by a few frames/second). This is not the fault of the my code, but the fault of the video card not being 100% register compatible VGA.

The image map was borrowed from a demo scene production, HeartQuake by Iguana - third place winner of Assembly '94. They made this easy by leaving the image map data in memory after their demo halts execution. They told me that they borrowed it in the same manner from a video game. It was probably the original Comanche: Maximum Overkill by NovaLogic, although I have never seen it. August 2006 Update: I ran Comanche 2 via DOSBox, and confirmed that this terrain exists in at least this version. June 2007 Update: Here is a YouTube video of Comanche: Maximum Overkill showing this map.

GUI is a Turbo Pascal Graphical User Interface unit created in early 1995. The GUI's main purpose was to aid in the programming two image creation utilities. These two project were a sprite editor, and a tile editor / level design program. The GUI would take care of the interfacing details, and allow the editor programs to be programmed with more focus. Unfortunately, these did not get past the design and partial implementation stages.

The file box example below shows some of the features of the GUI unit.

Screen Shot:

Download: File Box GUI (31KB)

The program will run on a 386+ processor.

MakeFont is a bit-mapped Font Designer Utility. It was created so that I could change the default 8x16 DOS font, and also create my own fonts for my graphics programs. (You will notice that it uses the File Box sample [on this same page], which was created later. This addition to the MakeFont program was completed in a matter of minutes.)

Screen Shots:

Download: MakeFont (183KB)

The ZIP file comes with a bunch of sample font files, and a REDEFINE.EXE program to change the current DOS font with another 8x16 font.

Express Directory (XDIR) is a DOS directory navigation utility used to replace the DOS command 'CD'. Apparently, it is similar to NCD (Norton Change Directory), which I have never had the pleasure to experiment with. XDIR allows you to change to any directory on your system without typing complete paths. It is obsolete, as it does not work with Windows 95's long filenames, nor does it accept path lengths greater than 66 characters - the DOS limit. Back in the DOS days, though, this utility was very useful.

Once the program is run, a batch file call XD.BAT is created with the information of your system's entire directory structure. The next time you wish to change the current directory to 'abcdef', regardless of where your current location is, or how deep into a directory tree 'abcdef' is located, simply type:
XD abcdef
and XDIR will take you there instantly.

The idea of such a program was conceived by Michael J. Mullen in 1993. He originally coded the program and named it XDIR after EXpress DIRectory. XD was used as the command name since it also signified the program's name, as well as being very similar to 'CD' on the keyboard. He coded the program in a very elegant way using the DOS 'CHKDSK' command, if you can believe that.

However using 'CHKDSK' was very slow. I took and recoded the program almost from scratch to perform the directory structure scan much faster. It is by no means anywhere near as fast nor as efficient as it could be, however. It should have been coded with the directory structure stored in a data file, which could be updated in real-time as the directory structure changes (rather than re-running XDIR every time a directory is created or removed, which is required if you wish to access these new directories). I believe this should have been integrated into the DOS operation system, itself. It could still be built into the Windows operation system, even though directory navigation is not as important anymore.

Download: Express Directory v3.13 (16KB)

Note: This program may not handle DOS directories created from within Windows 9X that create a full directory path over 66 characters in length (the old DOS limit).

Also, please excuse program's 'personality'; it was never intended to be released, and it essentially was a project on my own time to help me learn to program Turbo Pascal. This is the second Turbo Pascal program I had ever created, the first being a text-mode tribute of Sega's Columns puzzle game.

Anti-Gravity Simulation was a simple program that uses my gravity formula in reverse to make all particles push all other particles away. It was created very quickly, and the first thing that I thought about was that it would make a very cool screen saver. I have yet to implement this as a screen saver.

Screen Shot:

Download: Anti-Gravity Simulation (16KB)

Please note that this is a very old DOS program made in a matter of minutes, and does not attempt to adjust the simulation to fit your computer's power. The program automatically attempts to synchronize with the monitor's refresh rate of 70 Hz. If your computer can handle this, no matter what its speed, then the program will slow down the animation to fit your monitor's refreshing for a silky smooth animation. However, If too many objects are drawn at once which requires too many calculations for your computer to handle, then the animation may take over 1/70th of a second to calculate each individual frame, and the program will start missing the retrace on every frame. The effective frame rate of the program will then drop to 35 fps or lower.

Algebra Computer Program was a program I decided to create for the local science fair. I was interested in programming a computer project to demonstrate my computer skills, but I had to find a topic which could be implemented into a program. Mathematics came to mind very quickly. This idea first struck me the year before, but I did not follow through with the plan. After that science fair, a pair of students won some award with a computer program. The professor who was encouraging me to enter all along said, "That could have been you." So, I made a conscience decision to enter it in the fair next year.

The program was coded in GW-BASIC v3.20 on my Tandy 1000 SX (originally an 8088, upgraded to a 286 with 640 KB of RAM), 2 - 3¼ inch floppies and no hard drive. This was not exactly top-of-the-line equipment. 386 class machines running at 33 MHz were out at this time, hard drives were standard equipment, and I recall a fellow student having 11 Megs of RAM at the time. We had a little laugh about what kind of program would ever require 11 megabytes of memory.

The purpose of the project was to aid the teaching of algebra to students. It has several chapters which teach certain algebra skills, using algebra tiles when appropriate. Algebra tiles were recommended to be used in schools by top mathematics professors at the time. The program also tests and corrects students' answers on all topics covered.

The program was designed from the start to allow more chapters to easily be added. This is done simply by creating a new .BAS (GW-BASIC source code) file for it. The main program automatically locates and loads any .BAS chapter files found in the same directory that pass the legitimacy test (the .BAS filenames are not arbitrary; they must contain encrypted information so that the program knows they are legitimate additions. This helps prevent people from modifying the program without consent). This is about as easy as it gets to upgrade / update a computer program.

It won 1^st prize in the Seniors category in the local Science Fair. This is not a particularly great achievement - I was the only one in the Seniors category. It does not really mean much to win a race when you are the only participant, does it? It also received The IBM Regional Computer Technology Award and won me the opportunity to attend the Sixth Annual Alcan-Huggins High School Science Seminar held at Acadia University.

Now that I think about it, there was something very peculiar about that day... 300 students from junior high (grades VII, VIII and IX) entered the fair that year, and only one high school student, me (simply because I missed out the previous year), entered it... I am not trying to imply anything, but here are a few facts:

1. The Science Fair was being held inside the high school, during the day on a regular school day.
   
2. No student in the entire high school knew about it until the day it was held. I found out from the local newspaper the day before and scrambled that night to finish the project!

Screen Shots:

Download: Algebra Computer Program v2.1 (87KB)

Please note that the program's delay function (used to return the user to the title screen after a little while) runs too quickly on today's fast computers. It used to last a few minutes on my 8 MHz 286, but waits only a few seconds on my 750 MHz Athlon, and even slower on fast machines. Also, the computation of the CPU speed on today's machine creates many problems. Thus, the program is unusable on today's machines. Please use DOSBox to run the program. This will give you a close resemblance of the original experience.

The ZIP file comes with GW-BASIC 3.20, and a batch file called ALGEBRA.BAT. Run the batch file to run the program. This should run on any PC compatible machine. The font was ripped out of King's Quest IV, from Sierra On-Line. It was the only variable width font I had access to, at the time. I added the shadows to make it easier to read. There was originally an option to turn off text shadowing to speed up font drawing on slower computers!

Gravity Simulation is a simulation of Sir Isaac Newton's Law of Universal Gravitation using the planets in our solar system. It was created for the personal satisfaction of 'seeing' Newton's Laws at work (or, rather, to see if they actually do work). The simulation uses data of the planets (mass, speed, and position - found in an encyclopedia) to set up initial conditions. Once the simulation starts, the planets travel in their expected orbits with absolutely no control imposed on them.

The simulation was originally programmed in isometric 3D, using correct 3D gravity calculations, showing 'shadows' of the planets on a 2D plane; but this was hard to visualize. Since the solar system is relatively flat, the extra 3D code was removed, and the simulation now runs faster with more accuracy. The program uses simple Euler integration for its calculations.

Since the solar system is rather boring, I threw in another star (which I have named Star X) with a mass identical to that of our Sun (I have been jokingly referred to as a mad scientist for setting this situation up, but it is really rather interesting). Using a random initial position and velocity of the star, it just so happened that this particular trajectory is perfect for the capturing of our Earth!

You can create your own simulations by editing the .SIM files with a text editor, as they are merely text files themselves. The file format is explained within the .SIM file. I have included 3 .SIM files:

1. SolarSys.SIM - The Solar System - The Sun, 9 Planet's, and Earth's Moon.
2. EarthSun.SIM - The Earth - Sun System - The Sun and the Earth.
3. StarX.SIM - Same as SolarSys.SIM, except with an additional star the mass of the Sun.

If you create any interesting simulation files, you may send them to me via email at , and I will post them on this website. Please maintain the same file format as in my examples. This will give people a chance to understand what your simulation is about.

Screen Shots:
(Type in the gravity4 starx.sim at the command line to see the simulation.)

	Simulation centered on the Sun - Entire Solar System View The cast: Sun (yellow), Mercury (blue), Venus (green), Earth (cyan), Mars (red), Jupiter (purple), Saturn (brown), Uranus (gray), Neptune (blue), Pluto (green). All the planets are orbiting the Sun as normal. Star X (cyan) approaches from the bottom-left; Its gravitational presence is greater felt by the inner planets than the outer planets, pulling them away. This is noticeable by observing Pluto (green).
	Simulation centered on the Sun - Closer Look #1 Jupiter's (purple) and Mars' (red) orbits are starting to be affected by Star X.
	Simulation centered on the Sun - Closer Look #2 Jupiter (purple) gets slingshot around Star X. Mars (red) is a little off course, as the inner part of the solar system is begin pulled away from it. Star X is pulling Earth (cyan) away from its orbit, as they near each other.
	Simulation centered on the Sun - Closer Look #3 Star X starts to leave the scene in the upper-left, taking Earth (cyan) along with it. It is not evident unless watching the simulation centered on Star X, but Mars (red) was actually slight shot around the Sun and Star X at the same time, despite the fact that it remains distant from them both. It has gained a huge velocity from this.
	Simulation centered on the Sun - Zoomed Out Star X (cyan) leaves the solar system with Earth (also cyan) tagging along. The Earth is actually orbiting Star X at this point. Jupiter (purple) has gone back in a almost circular orbit around the sun. Saturn (brown) got a little close to the star, and got slingshot around. Mars (red) appears to be taking a vacation, moving off of the bottom of the screen. It was ejected at high speed, potentially becoming a rogue planet (similar to a runaway star.)
	Simulation centered on the Sun - Zoomed Out Further Star X (cyan) continues to leave with Earth (also cyan), also slingshooting Uranus (gray), Neptune (blue) and Pluto (green) (off the left side of the picture). Jupiter (purple) is back in a regular orbit around the Sun (the smaller purple circle in the center of the picture).
	Simulation centered on Star X - Close Look From Star X's perspective (remember that all motion in the universe is relative), the Sun (brown), Mercury (blue), Venus (green), Earth (cyan), and Mars (red) approach Star X from the top-right. They get slingshot around to the bottom-right of the screen, and Earth gets stolen away (it remains in a constant orbit - the cyan circle at the center of the screen).
	Simulation centered on Star X - Further Look #1 After 450 years, Uranus (grey) is also captured by Star X. It is making its approach for its second orbit (center right). Star X has also captured Pluto (green - bottom right). You can see it coming back after it sling shot around Star X.
	Simulation centered on Star X - Further Look #2 After 1,469 years, Neptune (blue) has returned, meaning it, also, was captured by Star X. You can see that Uranus (grey) and Pluto (green) have made many orbits in this time.
	Simulation centered on Star X - Further Look #3 After 2,951 years, Neptune (blue) has passed around Star X for a second time. Saturn (Brown) has yet to reappear. Perhaps the Sun has acquired it back, or perhaps its orbit is larger than 2951 years. If you watch the simulation yourself, Mars (red) was sling shot around the Sun and Star X at the same time. It gained enough velocity (by stealing a slight amount of both stars' energy) that it has escaped the gravity of both stars and will never return. It is now a rogue planet (similar to a runaway star.)

Download: Gravity Simulation (41KB)

The program should run on a 286+ machine. It was created in a day as a simple simulation. I apologize for the bad user interface. It was posted here for download just for your sake of curiosity, and as an example that I can program a real-time physics simulation. Please type /? as a parameter to find out about command line parameters.