[stella] Progress on my multi-sprte game...

[Robert "A." Colbert <colbertb@xxxxxxxxxxxx>]

Hi,
	Well, I figure it is about time to post the latest source code to my multi-sprite engine.  The code still needs a LOT of optimization.  You will notice that I have cut the number of sprites down from previous versions.  The way it is now, the code to move and schedule all 5 copies of player 0 fits in the VBLANK.  This leaves the entire overscan for game logic.  That may not sound like a lot, but when you realize that you don't have to worry about sprite movement, it is plenty.  I figure that if I run out of cycles in the VBLANK, I can duplex the code there to effectively double the cycles available.

	This version has 5 multi-color copies of player 0, each with a different size, shape and speed.  It also has 1 copy of player 1, and 1 copy of missle 1.  In addition, it has PF1's value set different every-other line.  This isn't very useful right now, and I need to optimize my drawing kernel to allow me to load at least 1 background register with useful values.

	I just eliminated a nasty bug that sometimes caused a sprite to mysteriously disappear.  It turns out that when I modified my code to allow for variable height sprites, I neglected to modify a portion of the conflict detection routine.  At any rate, that is fixed.

	While the demo is running, you can hold the joystick to the right to stop all copies of player 0 and see how the flickering looks for any given situation.

	Any suggestions on the code are welcome,  I will not be offended, guaranteed!  One note though, you may notice repetition, or worse, in my sort routine I don't check to see if the items are sorted prematurely.  Well, I did this on purpose, let me explain:  As far as the repetition goes, sometimes it is better to repeat a section of code in a time-critical area, eliminating a branch eliminates 3 cycles!  With the sort routine, I previously used a flag to determine if any swaps were used in the last run through the list of sprites.  Well, in most environments, this is o.k.  Of course the 2600 is a bird of a different feather.  I came to a very enlightening realization that with the 2600, you need to assume that every routine will execute the WORST-CASE SCENARIO every time, so checking for better than that actually is a waste of time!  If you do check for better than worst-case, you may be in for a surprise later when conditions are such that the worst-case occurs, or worse yet - two of your routines encounter the worst-case in the same frame...

	Sorry to babble on...

					Bob

Wanna write a game for the Atari 2600?
Check out http://www.novia.net/~rcolbert

Attachment: multi.s
Description: Binary data