GTD: Number Three
I KEEP TINKERING and tinkering with this two-sprite flicker engine.
I'm not real enamored with it, but I'm having fun playing with it. I haven't drastically changed the kernel; despite my bold words, I haven't been able to make it work.
But I was able to figure out a quick sorting method that does work with the flicker engine. It isn't perfect, but objects don't disappear and it is slightly better than a 1-sprite flicker engine. The sort returns results like this:
For 3 objects:
123132123
For 4 objects:
1234134214231234etc.
In all cases, the first two objects are shown, only. So the highest object is shown on all frames and the following objects are rotated, once per frame.
It's a little more complicated than that, but that's the basic effect. And the sort is fairly fast, almost as fast as the flicker sort.The sorting algorithm is as follows:
1. Does this sprite have the same Y-value as the next sprite (in the list)? If so, swap them and move to the next sprite in the list, returning to 1.
2. Does the previous sprite overlap the the next sprite? If so, swap this sprite and the next sprite, move to the next sprite and return to 1.
As Manuel noted, and I was expecting, processing all these sprites (flicker-sorting, moving, etc.) takes a *lot* of time. Too much time, actually. So I split things over two frames. The current 2FP (2-frame program ) goes a li'l something like this:
Move Sprites
Display
Flickersort
Display
repeat.
The next big step (BIG!) will be adding collision detection. A complete, brute force collision detection routine would take too long; impossibly long. To test each sprite (my engine supports 22 currently) against every other sprite to see if they overlap and have collided - ! Yeesh! What is that, 22! comparisons? Ouchie.
I wasn't sure exactly how I was going to solve that problem, then it came to me: if I assume that the flickersort will have the sprites in rough order (if not now then perhaps soon, anyway!), then I can just test each sprite against the sprites that are near it in the list. And since I only need to test collisions between the player's ship and enemies and the player's bullets and enemies (but not bullet-to-bullet and not enemy-to-enemy), that will cut things down to a (hopefully) manageable level. So the final 2FP will look like this:
Move Sprites
Display
Flickersort
Check Collisions
Display
With other assorted game logic fit into the cracks. At least that's the hope.Anyway, here's the demo without collisions working: ss.bin (See below!)Hit SELECT to change weapons.
Screenshot:
EDIT: Got collisions working! Screen jumps rarely, I think. Flicker also becomes a bit intolerable, but that can probably be cleaned up somewhat by tweaking what happens when objects collide. ss.bin
5 Comments
Recommended Comments