Search the Community
Showing results for tags 'Sprite Multiplexing'.
Found 4 results
GTD STANDS FOR Goofy Tech Demo, by the way. So I wasn't real satisfied with the way things looked yesterday; so I decided to give up using the sprites for the player's bullets, and use the missiles instead. This means no crazy weird shapes/colors for bullets, plus it also means no background starfield. But, you can actually see your bullets, which I think is a little bit more important. Plus I figure I can use sprites for special weapons that move slower and might be easier to see. So, changes: -Using M0 and M1 for player bullets, each flickered at 30 Hz (when necessary) for 4 bullets on screen at once. To my surprise, happily, four bullets, at the speed they are moving, is plenty to fill the screen. -Collisions between bullets and enemies are working, though sometimes bullets appear to pass through enemies. I think it is sometimes because I need to jigger the horizontal comparison between bullet and enemy and sometimes it is because the bullets are moving 4-pixels at a time and possibly jump right over enemies without ever hitting them. -Collisions between the player's ship and enemies are working; currently it just kills the enemies. -Sometimes the screen jumps a bit; I assume because the collision detection routine takes too long. ss.bin Screenshot:
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
INITIALLY I WAS PRETTY disappointed with the goofy tech demo I wrote (see previous post). It was pretty tricky, and a fair amount of work, to get the kernel working. And in the end, it didn't look much better than if I had just multiplexed a single sprite! But I kept playing around with it and I think it might be useful afterall. Maybe. Here's a possible way...look at this demo. At first, a mild-mannered, kinda-weak-looking Demon Attack clone: But you hit the fire button and then! Demon Attack On Steroids! daos.bin EDIT: And you could probably work a halfway decent 1942 (or similar) port out of this engine. EDIT II: New binary; flicker improved somewhat. Turn P0 and P1 on and off to see the difference between this one and the other ROM. daos.bin EDIT III: New DAOS binary. This one, at least, couldn't be done without a sprite multi-plexor. IMO doesn't look real great, but oh well. daos.bin
HERE'S SOMETHING I've been working on...can't decide if I like it or not. r1k.bin Screenshot. Background color is different in screenshot. EDIT: New version attached. Has 24 sprites instead of the 16 previously. Also added more boundary checking and changed the movement routine. r1k.bin New screenshot. For some reason Stella hates this binary...??? Runs fine in z26 at a (95%) constant 262 scanlines, so I don't know what's up. I think it has something to do with the RIOT timer.EDIT II: New version attached, that works with Stella. Will eventually crash. Still 24 sprites (I think that's the limit of RAM) but some are different now. r1k.bin And screenshot: