Am I done yet?

I have now added some basic gameplay keyboard routines and a sample collision detection routine. I stress these are samples and need to be adapted for whatever game you might end up writing.

So what do GAMEPLAY keyboard routines look like? Well it doesn't scan the full keyboard for a start - that takes ages. You basically list the keys you want and it'll scan for them and set a BIT somewhere for you to check in the gamecode. This means you do minimal keyboard reading and spend all your valuable CPU time doing game stuff.

And how about the collision code? Well it's basically the same as I had in Blood Money, and have in XeO3. If you imagine 2 spheres colliding, to work out if they've hit, you subtract the centers and get the distance between them, then add the radii together and if the total of the radii is larger than the distance between the centers, they've hit. I do basiaclly the same thing but with squares. Each sprite has a center point and I subtract them (one at a time - no Square roots here!), then I add the two X widths (from the center) and compare with the distances between the X centers. If the 2 widths are greater than the to centers subtracted, then we've hot on X, if so we do the same with Y. For a little more speed, the X centers are divided by 2 so we can get rid of the significant bit of X - one less thing to worry about. SO! The current setup consists of:

16 sprite bouncing around with 3 compile time sorting options.

1 player sprite being controlled by the joystick (in either port)

A gameplay keyboard routine

Some basic collision detection.

And there you have it. If theres nothing else I'll start doing a little game of some sort or other and when thats done, I'll release it. Not that I really need to do a game though, but it'll give others time to ask for additions while I'm doing it...