SpaceWar! (VGA Version 3.2)
RossH
Posts: 5,519
I have decided to start a new thread for this version of Spacewar since it is now becoming quite different from Eric Moyer's original version. Eric's is still the definitive TV graphics version, with sound effects and full support for eeprom assets such as background music, whereas this version only supports VGA. It has partial support for sound effects but no support for eeprom assets.
I have included the source and a couple of 32K eeproms with various different VGA configurations. They all use the same high resolution virtual VGA driver. This driver currently doesn't leave enough cogs to load assets from eeprom, or play background music. If I can ever make it efficient enough then I will add support for these back in.
A brief description of the VGA support: The display driver supports resolutions up to 1152x864 in 2 colour mode and up to 800x600 in 4 colour mode. The colours can be any of the 16 standard VGA colours, but the colours currently apply to the whole screen, not to each 'tile'. The display driver has a companion graphics driver that implements most of the normal Parallax bitmapped graphics functions (I had to leave a few out due to lack of space).
The driver is "virtual" because it only uses memory when something is actually drawn on the screen - normally, an 800x600 4 colour screen would require nearly 1Mbit to hold a single screen bitmap (and really we need two so we can double buffer). But on the Propeller we have only 256Kbit total for both program and data. A virtual driver is the solution. While it is complex internally, externally the driver looks quite similar to the existing Parallax drivers, and can be used with relatively minor code changes. You just give the driver as much free RAM as you have, and it manages a virtual bitmap for you. How much you can draw on the resulting screen depends on how much RAM it has. When the driver runs out of bitmap memory things just don't end up on the screen. Fortunately, Spacewar (like most games originally based on vector graphics) only use a small percentage of the screen at any one time, so a virtual driver works perfectly - however, it does currently require 5 cogs to do all the memory management, VGA signal generation and graphics processing!
I got fed up with running out of RAM every time I added some more gameplay elements, so with the latest release I've now included a "RAM recycling" compile time option in both the main program and in all the included drivers (e.g. video, sound, keyboard). When this option is enabled, RAM that is used to hold cog programs is recycled once the cogs are loaded. This technique is not as good as a true dynamic cog loader, but it works well provided you don't need to be able to reload cog programs dynamically. It is easy to add recycling support to other drivers if necessary - it requires only a few lines of SPIN code. This technique leaves your memory map fragmented, but this is acceptable if that memory is going to be used by the virtual VGA driver, because that driver can make effective use of whatever small chunks of RAM you can give it (as additional virtual bitmap space).
The current version is 3.2. I have cleaned up the code a bit more and made it easier to configure - all you need to do is decide on your resolution and colour mode. The program figures out automatically how much RAM it has available for the initial virtual VGA bitmap, and also recycles cog RAM automatically to give you more video bitmap space once the cog programs are loaded. Since RAM recycling has been added, the need to disable individual drivers to free up more RAM is no longer necessary - but I have left in the 'dummy' drivers that make it easier to enable or disable sound and keyboard support just in case (e.g. if you want to run the sound manger on its own cog you still need to disable the keyboard). But you can generally run up to 1152x864 (2 colour) or 800x600 (4 colour) mode now with both sound effects and keyboard support included.
Here is a summary of the new features in the VGA version:
- High resolution VGA support (2 colours up to 1152x864, 4 colours up to 800x600).
- Ships now more complex (reminiscent of the Cinematronics version).
- Added background stars (and an option to 'twinkle' them)
- Ships can now be destroyed by their own missiles.
- Shots now bounce off shields. The bounce direction is slightly random.
- Added a random factor in the "time to live" of each shot.
- Added a hyperspace option - press the gamepad 'down' button, or the keypad 'S'. A ship has a slight chance of being destroyed every time it exits hyperspace.
- Added a ship damage option - ships can now take up to 3 hits to be destroyed. Each hit blows parts off the ship, degrades the ship speed and maneouverability, and increases the chance of being destroyed when using hyperspace. Note that a ship can still be destroyed by a single shot - but only at close range.
- Added a closed universebounce back option - causes ships and missiles to bounce off the the edges of the screen.
- Added a negative gravity option - pushes ships and missiles away from the black hole instead of sucking them in.
- Added a random rock option - up to 2 asteroids will appear at random. Ships are destroyed if they hit an asteroid, but asteroids can be destroyed in turn (by shooting them) if they get in the way. Shields are not effective against asteroids. Also, the random rock option and the negative gravity option do not work well together - the asteroids just tend to congregate in the screen corners and stay there.
- Added support for RAM recycling - allows for more complex gameplay!.
-Added expanded universe option - this makes the universe 25% larger than the screen on each side, allowing you to the option to manoeuvre "behind the scenes"
There is still one known issue - the game sometimes fails to start at all, giving you a screen full of rubbish. This occurs in the maximum resolution modes (1152x864 2 colour, and 800x600 4 colour) and is due to a timing issue with the new VGA driver that I haven't figured out yet. But it usually starts ok if you simply reload it.This issue has now been resolved - it was due to the cog video processor starting up in an indeterminate state - fixed by resetting the video generator scaling and mode on startup.
All the various eeprom versions are now configured exactly the same way - with keyboard and sound support included (with sound running on the same cog as the main game). Eeproms are provided for the following resolutions and colour depths:
1152x864 2 colour
1024x768 2 colour
800x600 4 colour
800x600 2 colour
640x480 4 colour
Feel free to comment or report any problems.
Post Edited (RossH) : 8/3/2008 8:08:26 AM GMT
I have included the source and a couple of 32K eeproms with various different VGA configurations. They all use the same high resolution virtual VGA driver. This driver currently doesn't leave enough cogs to load assets from eeprom, or play background music. If I can ever make it efficient enough then I will add support for these back in.
A brief description of the VGA support: The display driver supports resolutions up to 1152x864 in 2 colour mode and up to 800x600 in 4 colour mode. The colours can be any of the 16 standard VGA colours, but the colours currently apply to the whole screen, not to each 'tile'. The display driver has a companion graphics driver that implements most of the normal Parallax bitmapped graphics functions (I had to leave a few out due to lack of space).
The driver is "virtual" because it only uses memory when something is actually drawn on the screen - normally, an 800x600 4 colour screen would require nearly 1Mbit to hold a single screen bitmap (and really we need two so we can double buffer). But on the Propeller we have only 256Kbit total for both program and data. A virtual driver is the solution. While it is complex internally, externally the driver looks quite similar to the existing Parallax drivers, and can be used with relatively minor code changes. You just give the driver as much free RAM as you have, and it manages a virtual bitmap for you. How much you can draw on the resulting screen depends on how much RAM it has. When the driver runs out of bitmap memory things just don't end up on the screen. Fortunately, Spacewar (like most games originally based on vector graphics) only use a small percentage of the screen at any one time, so a virtual driver works perfectly - however, it does currently require 5 cogs to do all the memory management, VGA signal generation and graphics processing!
I got fed up with running out of RAM every time I added some more gameplay elements, so with the latest release I've now included a "RAM recycling" compile time option in both the main program and in all the included drivers (e.g. video, sound, keyboard). When this option is enabled, RAM that is used to hold cog programs is recycled once the cogs are loaded. This technique is not as good as a true dynamic cog loader, but it works well provided you don't need to be able to reload cog programs dynamically. It is easy to add recycling support to other drivers if necessary - it requires only a few lines of SPIN code. This technique leaves your memory map fragmented, but this is acceptable if that memory is going to be used by the virtual VGA driver, because that driver can make effective use of whatever small chunks of RAM you can give it (as additional virtual bitmap space).
The current version is 3.2. I have cleaned up the code a bit more and made it easier to configure - all you need to do is decide on your resolution and colour mode. The program figures out automatically how much RAM it has available for the initial virtual VGA bitmap, and also recycles cog RAM automatically to give you more video bitmap space once the cog programs are loaded. Since RAM recycling has been added, the need to disable individual drivers to free up more RAM is no longer necessary - but I have left in the 'dummy' drivers that make it easier to enable or disable sound and keyboard support just in case (e.g. if you want to run the sound manger on its own cog you still need to disable the keyboard). But you can generally run up to 1152x864 (2 colour) or 800x600 (4 colour) mode now with both sound effects and keyboard support included.
Here is a summary of the new features in the VGA version:
- High resolution VGA support (2 colours up to 1152x864, 4 colours up to 800x600).
- Ships now more complex (reminiscent of the Cinematronics version).
- Added background stars (and an option to 'twinkle' them)
- Ships can now be destroyed by their own missiles.
- Shots now bounce off shields. The bounce direction is slightly random.
- Added a random factor in the "time to live" of each shot.
- Added a hyperspace option - press the gamepad 'down' button, or the keypad 'S'. A ship has a slight chance of being destroyed every time it exits hyperspace.
- Added a ship damage option - ships can now take up to 3 hits to be destroyed. Each hit blows parts off the ship, degrades the ship speed and maneouverability, and increases the chance of being destroyed when using hyperspace. Note that a ship can still be destroyed by a single shot - but only at close range.
- Added a closed universebounce back option - causes ships and missiles to bounce off the the edges of the screen.
- Added a negative gravity option - pushes ships and missiles away from the black hole instead of sucking them in.
- Added a random rock option - up to 2 asteroids will appear at random. Ships are destroyed if they hit an asteroid, but asteroids can be destroyed in turn (by shooting them) if they get in the way. Shields are not effective against asteroids. Also, the random rock option and the negative gravity option do not work well together - the asteroids just tend to congregate in the screen corners and stay there.
- Added support for RAM recycling - allows for more complex gameplay!.
-Added expanded universe option - this makes the universe 25% larger than the screen on each side, allowing you to the option to manoeuvre "behind the scenes"
There is still one known issue - the game sometimes fails to start at all, giving you a screen full of rubbish. This occurs in the maximum resolution modes (1152x864 2 colour, and 800x600 4 colour) and is due to a timing issue with the new VGA driver that I haven't figured out yet. But it usually starts ok if you simply reload it.This issue has now been resolved - it was due to the cog video processor starting up in an indeterminate state - fixed by resetting the video generator scaling and mode on startup.
All the various eeprom versions are now configured exactly the same way - with keyboard and sound support included (with sound running on the same cog as the main game). Eeproms are provided for the following resolutions and colour depths:
1152x864 2 colour
1024x768 2 colour
800x600 4 colour
800x600 2 colour
640x480 4 colour
Feel free to comment or report any problems.
Post Edited (RossH) : 8/3/2008 8:08:26 AM GMT
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
I may add a few more polishes to it, but all the gameplay options I wanted to include from the Cinematronics version are now done.
I finally found the timing problem that occasionally caused the virtual VGA driver to generate rubbish when started in the higher resolution modes. It was due to the cog video processor starting up in an indeterminate state. I finally got a clue as to what the problem was by looking through Chip Gracey's original high resolution text mode driver, and seeing the tricks he had to pull to synchronize a video signal generated from two cogs.
Also, added in the Cinematronics "expanded universe" option.
A request for assistance ...!
Andre suggested I make a video of the VGA version of Space War! and put it on youtube for Steve Russel (who programmed the original) to see. I'm happy to do so, but I can't get a decent video with the equipment I have. I've tried my old analog video recorder and my web cam, but the results are hopeless - even if I only use 640x480 resolution.
I don't want to put anything online that would show the Hydra in a bad light, so if anyone has facilities for making a short video of the game (either using a good quality digital video camera or - better yet - recording the VGA output directly) I'd appreciate it.
The video would only need to be 30 seconds or so. You could either post it here and I'll put it on youtube, or you could put it straight on youtube and post a link here.
Thanks,
Ross.
I'm thrilled to see you expanding the SpaceWar code! I've been keeping an occasional eye on this forum but I had to stay very focused to complete my Coyote-1 project (www.openstomp.com, which is finally shipping as of Friday) so I haven't allowed myself to bust out the Hydra and give it a try. Now that the Coyote-1 is finally out the door I can't wait to give the new SpaceWar a shot. My Hydra's at the office, but hopefully I can fire it up on Monday night. It sounds like you've done a great job!
It was always the nature of the original SpaceWar that everyone jumped in and tweaked it. I'm surprised no-one messed with this version before now; the paradigm lends itself to so many possibilities.
Looking forward to it,
- Eric
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
What a blast! I love it! Great job!
My HP w2048h display occasionally looses sync a bit when running in the two highest res modes. The image is still visible, but the lines get all fuzzy. I'm going to bring my Hydra home and try it out on some other monitors.
It's really great to see the ships in their original glory! In the original (NTSC) version the resolution wasn't high enough to draw the ships in much detail.
SpaceWar is still my favorite Hydra game because playing against another person makes it so surprising and the physics give it rich emergent behaviors. This game still makes me laugh out loud and shout at the screen more than any other [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
Yes, SpaceWar has always been one of my favorite computer games. I also love the elegant simplicity of vector graphics.
I've also got a VGA version of Michael Park's Hydra BattleZ0ne (another old vector classic) - the graphics look good but the gameplay needs some work - I had to hack it about a bit to save enough cogs to run the virtual VGA driver. I'll post that when I get it in reasonable shape.
As to the picture quality, all LCD monitors tend to look fuzzy when running in a non-native resolution - the images actually look quite good on my old analog CRT. But I suspect the real culprit is that I'm getting close to the edge of how fast a RDLONG/WAITVID loop can push the VGA bits out. Chip Gracey's high resolution driver is text mode only - which means he can build his lines in cog ram and he only has to read from hub ram 8000 times to display a whole hires screen (i.e. once for each character). Doing bitmap graphics means the driver has to read about 32000 RDLONGs to display a hires screen.
I'll have to see if I can make Space War network capable - then I'll challenge you to a duel!
Ross.
Ross,
I was trying to think through a virtual tile map for use with the graphics driver, but it seems you have done all the hard work already
Poking around, it seems like it draws first and fourth quadrant right triangles correctly. Second and third quadrant right triangles are drawn very strangely - as if every other tile-row is reflected about the bounding box (or some other arbitrary line y=c). Anything other than a right triangle is a mix of the two and thus completely distorted.
Any suggestions for getting fill_ working with your sparse tile set?
Thanks,
Jacob
It's been a while since I looked at this code, so I can't give you an answer off the top of my head - but if you post your modified version I'll have a look at it and see if I can spot the problem. I always meant to go back and try and squeeze back in the stuff I had to leave out to make it work.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've attached the modified files. "SHADOW_test2" is a cut-down SpaceWar_Virtual, so the init stuff is all there. "SHADOW_Virtual_graphics..." is also way cut down to isolate the issue, many other functions could fit in. Anyhow, it should draw one triangle in a loop. If you set the vertices:
I: (x, y) (x, y + 100) (x + 100, y)
II: (x, y) (x, y + 100) (x - 100, y)
III: (x, y) (x, y - 100) (x - 100, y)
IV: (x, y) (x, y - 100) (x + 100, y)
for any (x, y) you can see the issue in quadrants II and III. I went over the math/assembly as far as I could by hand, but couldn't find a problem because I run assembly about 100 billion times slower than the Propeller...
Cheers,
Jacob