Orbit

UPDATED. New Blogger hosted movie of the Solar Wars sun orbiting.



Thanks Blogger! ;)

Modern or Classical Styling?

As you can see the graphics are coming along nicely! Well actually these aren't real screen shots (suprise!) but on the left is a real life solar power station in Spain, and on the right a standard radio telescope. I need a giant solar reflector to emit my game lasers, so I think I might use one of these as the basis. Clearly it will be in vectors, and therefore very rudimentary, so whilst I prefer the image on the left the one on the right might be more recognisable (and more animation compatible.) Please leave a comment to vote for the left or right images or suggest any other images/concepts that I can consider.

Day 6 - Sunrise!

It's been longer than I'd prefer, but I just grabbed another hour on the Vectrex. If you recall the next step was to add multiple lasers. Thankfully everything was implemented in structures, so I just added list wrappers around the structures and all seems in order. The pic shows two parallel lasers. I need to check out the memory constraints and extend the segment lengths, but I'm hoping we'll be good for up to 12 ideally. (Day time pics get background reflections, so I've blacked parts out to avoid distraction.)

Now it's time to start adding some context and game play. I tend to find sprites help with this, so it's time to do a little drawing. Since the game is called Solar Wars what better start than the sun! Of course this is a Vectrex so Vectors are the order of the day. It's not easy shading with Vectors, so I had to be a little cunning. I had thought I would need a lot of frames for this, but it turned out only 4 gave a nice effect. Bonus! Currently the sun in rendered in RAM, but when I have a moment, I'll run the data through my PC to get the ROM trails (to conserve precious RAM)
You can see the cycle line and the 033 look positively dull in comparison to the Sun! Oh by the way the sun also orbits the screen, but for this photo I froze it. Maybe I'll take a pic or two tonight when it's darker, and easier to take the shots.

At the last moment I think I discovered a bug with the second laser collision detection, so maybe it's time to evolve the CD a little more. I'll improve the resolution and iron out any bugs in that area.

Day 5 - 2 mins very well spent!

Yes!!! Cooking on gas today! Literally spent 2 mins on this, (spent more time on the photos!) Even better I saved a byte on storage. As you can see the dark matter has cleared off and the beams travel as intended. The left pic shows a beam entering from top right, hits reflectors (numbered spiralling clockwise inward from bottom left) 4,3,2,1,4 in turn. (and yes I like using the same reflector twice.) Pic on the right is a little more complex. Beam hits (4,3,2,4,1,3,) Nice. (OK, I admit I'm chuffed! From now on we should be set. Not sure when I'll do the finer collision detection, it's no biggie. Next step will either be some sprites or a second beam. Have to see what mood I'm in. I doubt it will be long until my next session. (Thanks to J.K. Rowling's latest cash cow.)

And the hero of the day is the small dot you see in the top right of the second pic. This enabled me to realise what the bug was. It shows the screen edge detection was correct all along. (Drowning man, at the time.) So armed with this knowledge I was able to see I was only plotting the total number of segments that the last reflection required to hit the edge of the screen. Muppet! Thankfully a problem identified is a problem solved.

Actually I did spend more than 2 mins, I spent another few mins adding the ability to move each reflector. Remember we had selection and rotation in Day 4, so I added moving if B3 is held down and J1 tweaked. Beam direction has now shifted to J2.

Snuck a new pic in.. (Dark with ISO400)

Compiled code size 5266 bytes

Day 4 - Is the earth flat or doughnut shaped?

A few hours this evening. Nice to be back in 8 bit land. No interlude yet, it was a busy week at work with little time for side interests, so tonight's work was spent on the main game. You may remember Day 3 was a bit of a mess, so I rewound a little and added got things working a lot more simply this time. I'm still using the coarse collision detection as that's just tidying up which we can save until later. For the moment it's all about getting a 2nd generation reflection.. (beam enters facing left from top right.)

Success! ..But.. I get multiple reflections now, but strangely the beam stops prematurely. I have code to determine when the beam hits the edge of the screen, but somehow it also seems to hit something at other times. Either I've discover a dark matter detector, my world is a torus, or there's a mysterious bug in my code. I suspect the latter at the moment, but I'll update you. Most evidence seems to suggest it's when I cross the centre axis, i.e. as my "sign" changes. I'm using an ADDD with a BVS check which I need to ponder on whether it's the right choice. Usually naughtiness when you start bending signed and unsigned usage and checks (tut.) No doubt the solution will dawn on me shortly. Once this beam reliably hits the edge of the screen (or a consumer) I'll be moving on to improving the object handling. Oh that reminds me, you might have noticed a change to the layout. I added a 4th object (all 4 are now reflectors.) I removed the auto spin feature of the 2nd object and added an object select feature to allow me to rotate the reflectors independently for debugging (or maybe a more lasting reason..) You'll also note that one of the boxes appears brighter, this indicates which is selected for rotation (cycled with B1 & B2.)

Compiled code size 5182 bytes

Day 3 - A Stolen Moment

Hmm, a 45 spare mins so I thought I'd do a little Vectrexing. It's never a good idea to spend a short period on the Vectrex IMHO, it takes a while to remember where I'm at and if I rush it, then I tend to go in the wrong direction. I'd say lesson learnt, but maybe this blog will record otherwise! Anyway at least it was fun. My pics tonight simply show some bugs, (one rather spectacular) resulting from tonight's dabbling. I have the concept of a Beam, having many segments, and many child beams. Segments in turn have many invisible test segments, but that's not important here (yet). Tonight I got a little carried away and created a new child for each reflection. I think on reflection (no pun intended, honest) that this might be unnecessary. I need to keep track of by absolute and relative positions, and my local origin. I think this might be better achieved using temporary variables and keeping the number of child beams to a minimum. If I use too many child beams, then it kinda defeats the object and it will both increase the memory I use and reduce the drawing speed when I choose to render the segments of each beam.

This pic is why I Vectrex.

So my next step will be to revisit my code between Day 2 and Day 3, and replicate the functionality whilst keeping my child beams to a minimum. I figure with the nature of my plots, I can aim for about 10 segments (possibly including 4 reflections before I need consider a beam will be "full" and a new child will be forced. This permits Vectrex Beam recalibration and will reduce wobble. Check out this second pic. I grabbed the camera as quick as I could as the screen was frying! You never get bugs so beautifully illustrated on any other games console! (and this is with a very low brightness setting and beam insensity set to $3F; about 25%.)

Not sure when the next session will be, as there may be an interlude as I try a new idea I've (just) had. I'll document that as I do it too, although I am sure I'll be back to continue this project within 7 days.

Day 2

Another day, and so soon, I'm blessed!
Last time I promised a little more visual output and the day has delivered. Still just over-engineered lines at this point, but much progress.
Today I was reminded of the triangle of Vectrex programming:

ROM Vs RAM Vs CPU (Speed)

You can pretty much do things in an infinite number of ways, but the quest is always to find the balance. Today my trig tables were in ROM, my rotated co-ordinates were in RAM and CPU did fairly well out of the deal (although I did a lot of 16 bit arithmetic rather than 8bit.)

So here's some photos of the day's progress:


First off, I was pretty comfy with the line we had on day one, so I wanted to introduce some obstacles. These boxes surround enlarged lines (my simple obstacles) The boxes are just for reference and will disappear later. The lines are also drawn at the navigation scale rather than the efficient fine detail scale they will eventually be drawn at. But they look nice and the geometry works for angle angle in vegrees.





Next a rather clumsy attempt at lo-res collision detection. I spent a little bit too much time on this, and eventually I decided that this method was too processor intensive and not accurate enough. Coarse collision detection is great, but it should never be less than generous!

Also if you look closely you will see the long line is in fact made of 3 shorter ones, this is because I wanted to draw them at a reasonable scale as very long lines can take an age to draw on the vectrex and look blurry. This way, I can keep sharpness without too much compromise. Each line is also sampled about 20 times en route to ensure it doesn't hit anything or fall off the screen. If a line matures to full length then it is drawn and the fractional checking disappears.

This shows a zoom on the second pass collision detection. The box is now very small, less than 1cm. The dot can be steered (for debug purposes) into the hi-res collision rectangle. When it "collides" the dot blinks (the photo won't show that! :) The blured effect is because the line is rotating at about 0.5Hz to test all collision eventualities. I had a little fuss making sure my bottom left didn't become my top right, but eventually I sorted that out. :)
I'm not using this hi-res rectangular collision detection yet, but I will as a second pass. The dots that trace the line we saw on day one, will be used as a third pass collision and will provide extremely accurate collision detection (CD) to make sure everything looks nice.



The final fruits of the day! An incident beam matching a very coarse collision detection and "bouncing" off at the correct angle. Not using the finer CD as mentioned, and note the box for debug purposes, in shows nicely why the CD thinks a collision has occurred. The beam and the obstacle may both be rotated on the joystick for debugging. I'm pleased with this solution, currently it looks very simple, but the engine under the hood will scale considerably (at least that's the intent.) I notice with a grimace that if the reflection strikes a second obstacle the Vectrex hangs; something for another day, but I'm confident it will be a minor tweak. After all the prep on the straight lines the bouncing angle was only 4 additional lines of code which fitted in nicely.

Compiled code size 5000 bytes

(Happens to be a round number by fluke! Note this is already 20% bigger than Star Sling's 4096 bytes, I guess you can see how the each of the 3 resources complete (ROM/RAM/CPU) Star Sling was imperative to be a fun, two player game with analogue controls that fitted in 4096 bytes. This game I will allow to go to the full 32K if necessary, but I will stick the the standard 880 bytes of RAM. At the moment, I suspect the constraint of this game will be the CPU, there are a lot of calculations to do depending on player events, so managing that will be interesting.)

Start coding!

Right, enough theory let's get typing! I've set up my trig tables for later and confirmed the algorithm for the bouncing light. Now I need to tie it together in Vectrex speak! As I said before this can be tricky since even simple maths can get tough without fractions or dividing..

However, setting an angle and drawing a vector is trivial, so that happened very quickly and was more a question of remembering my compiler flags! The line was simple, but as is often the case the collision detection might prove tricky. What I needed to do was to draw a line, but to know exactly where each point was along that line. So I did a lot more maths to determine how to work out each 'y' for each 'x', generally its easy to trot along the hypotenuse but a little more effort to pop along a single axis. Anyway I got that in place and now you can see a very unimpressive line with some dots next to it. (What you can't see is the line rotated when the joystick is moved. Also the dots are deliberately shifted to to the right so the are clearly visible, yet still aligned.) These are drawn to show I "know" each dot along the line. In a later version I may go back to my sin/cos pairs but in this example I tried the slightly more tricky tan based method in case I need it later. (As I type this the sin/cos seems to fit the requirement once, more.. I guess we'll see over time.)

This is one of the things about Vectrex coding, some things are really easy and some things are more challenging and there is often a fine line between the two. In this case I was really pleased with my dots, even though they won't be seen in the final game and are just for behind the scenes calculations. Any also they look inferior to a line which is easy to draw! :)

Not sure when my next chance to code will be (hopefully soon), but I'm sure there will be a lot more visual results at that time, since must of the planning (for this stage) is now done.

Compiled code size 3814bytes

Day 1 - Power up!

Having been away from Vectrex for 8 months, I thought it might be time to fire up the little beast and see what happens. So this morning I cleared my computer room, plugged in my Vectrex dev PC, rewired everything up and crossed my fingers. I ran into a few difficulties first this setup was much less elaborate than last years arrangement, for one I was only planning on using 1 monitor. In an amazingly inconvenient turn the EPROM simulaor software insisted on only "displaying" on the second monitor position, (which wasn't present any more) no amount of display setup config would stop it whizzing off the start bar and out of the screen! Eventually I managed to find the keyboard shortcut to move a window without the mouse. Alt-space, down, enter (eventually.) Not a pleasant start! Second problem was the EPROM simulator wasn't recognised by the vectrex, just constant Minestorm! Thankfully this was easily solved, I unplugged the sim and plugged my second one in instead. I'm assuming it was just a bad combination of Vectrex and cart edge, hopefully all these snags are behind me now!

More prep

OK, I've done some sketches and I've figured out how I want things to work and the math(s) behind it. Now the hard bit is to bend the math so that it fits Vectrex hardware. I guess I should point out what makes things tricky.
1 No floating point numbers (no fractions or numbers between 0 and 1)
2 No trigonometric functions
3 No divide! (although you can write your own)

My solutions.
1 I use two bytes for my numbers, I guess you could call them the ones and 1/256s columns (as opposed to 1s and 0.1s). I have my own routines that deal with signing, adding and multiplying these numbers. Multiplying fractions it especially useful when we get to (2)
2 I use pre-calculated lookup tables (normally produced in MS Excel) these lookups map angles in Vegrees (256 vegrees in a circle) to my byte fractions in 1/256s
3 Simple integer division I do manually with subtraction. Non integer division I try to avoid or multiply by reciprocals.

Since I use lookups for my trig I need to decide which ones to use. Normally Sin and Cos are all I need, and these tend to be in 2 bytes form. SSSS used only a 1 byte Arctan table. I figure the new game will need Sin, Cos and Tan. So I add to my existing Sin and Cos tables using Excel spreadsheet exported as CSV.

I figure it's about time I powered up the Vectrex to start coding!

Low tech and high tech

Remember I've still not gone near my Vectrex yet, and there's more yet to come before I do! I bet this one will comes as a shock.. I need to test the basic maths behind my game, it with involve reflection and as every schoolboy knows with regards to a reflection "the angle of incidence = the angle of reflection" - but I wasn't sure what this meant with regards to the maths in practice..

A few more scribbles and I had a theory, basically I wanted to know it terms of "absolute angles" (compass bearings) what angle a reflection came off at. My pen and paper scribbling came up with
r=2s-b
(where r is the angle of reflection, s is the reflective surface angle and b is the incident beam angle.) I thought it was right but wanted to test it. It's times like this I yearn for the convenient simplicity of an 8-bit microcomputer with integrated BASIC and simple video display commands, like a BBC Micro, sadly times have moved so I reached for the 2007 equivalent.. C# on the Xbox 360! :)

Actually the 360 this is a mixed blessing, for all the time I save with native floating point and trig support, I lose again turning off all the fancy 3D and the textures etc! Anyway about an hour later I had my test (I know an hour's a long time, but C# and the 360 are all new to me!) I took a photo or two:

The red beam is incident, the pink is reflection and the yellow is the reflective surface. The joystick spins the reflective surface and confirms my math to be correct.. I'm ready for the next step..

The ground work..

I've had an idea for a new game, I won't give all the details yet, you'll just have to see it evolve from my efforts here. So like most Vectrex projects it began with a pad and paper and a lot of thinking! I always try to consider the technical demands of the core engine in advance. Bells and whistles can come later, so its normally trying to get some maths working, and more often than not some trigonometry..

A new vectrex game - blogged!

As stated below, I've decided to write a new game for launch at Eurocon 2007, and for the first time I'm going to write a blog of the experience! I hope you'll enjoy this, if you do, please drop me a comment! I'm happy answer any questions posed as comments , they make even shape the game! l do reserve the right to "tease" you a little on the overall game design since it will be revealed incrementally as the game takes shape..

You're about to see the whole development process from Vectorzoa's perspective. It may not be the definitive way to write a game, but it's my way. (Remember I do have a day job, so this game is written in stolen moments.)

Here goes...