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.)