Showing posts with label broadphase. Show all posts
Showing posts with label broadphase. Show all posts

Sunday, July 6, 2008

Audio, some refinements, and this week's to-do list

I've spent the past week messing around with the sort and sweep algorithm some more. The main problem, in my case, is that I need to do a good bit of reading on the IComparer class, because I really don't understand it. As it is, if there are multiple objects with the same X coordinates, it isn't necessarily including them all in the appropriate lists of interfering objects. Take, for example, the picture at the top. If we're checking interference with the rabbey (the little brown rabbit monkey thing standing on the question mark block), we look at everything in between his leftmost and rightmost points. In this case, two grass blocks, a mountain, and a question mark box. That'll work, and that's all fine.

If, however, the rabbey is on a stack of ten boxes, all of which have the same position along the X axis, and the rabbey happens to be at exactly the left- or right-most point of said stack of boxes, some funky things start to happen. This is because when we're sorting the list, we SHOULD be putting the rabbey's left coordinates at the beginning of any string of identical coordinates, and the right ones should go at the end of any string of coordinates identical to those. In other words, the rabbey (in this case) should be the very beginning and the very end of any items who might interfere with it.

In my implementation, however, this isn't the case. the list is sorted, but no particular creedence is given to the order of multiple cases of identical coordinates. My short term fix is to test three or four extra objects to the left and right of the object in question, but this is a stop-gap solution and is probably the worst way to handle it. I'll be researching IComparers in order to find a better way. I shouldn't have to sort the list multiple times per update (as that would be prohibitively expensive, CPU-wise), and I think I can just search for certain values in the list. That should hopefully be kind of easy.

The main additions I've made in the past couple of days have been audio (all music and effects copyright My Awesome Talentedness, 2008). A friend of mine is going to do some music for me, and I'm really looking forward to that. I'll mess around with the sounds a bit as well, but it's not a high priority for me at the moment. At this point the voice acting is no worse than Symphony of the Night, and that was one of the best games ever made.

I've also done some minor tweaks here and there, mainly standardizing the blocks' sizes (so they'll all match up, duh), and tweaking a few things in the update cycle (the most noticeable of which being that the enemies don't move unless they're pretty close to being onscreen).

In addition to the aforementioned sort and sweep fixes, I'd like to add some enemies, some block types, and blocks that pop out powerups in the coming week. I also need to add a way to finish a level, load into the next one, stuff like that. Finally, I think it's really time that I implement a game state management system, even if it's hard as hell to do it. I need to be able to pause, have some menus, get a game over, and stuff like that. It won't be fun. But it has to be done. We'll see how it goes.

Videos:
Youtube
High-res download (720p) (recommended)

Sunday, June 29, 2008

Sort+sweep detection: FINALLY



Okay, so I'm super happy that I've gotten the sort/sweep implementation more or less working for my collision detection. It took me a good long while, but it's working now, and the performance increase is noticeable.

My previous collision detection did the following:
Make a list of everything.
Go through each item on the list.
Test it for collisions with everything.

It's very easy to do and very inefficient. The new algorithm does the following:
Make a list of everything.
Make a new list of the beginning and ending positions on the X axis of each item and sort this list by these X positions.
Go through each item on the list.
Test it for collisions with any objects whose X position is between the start and end positions of this object in the second list.

That's a poor way of putting it. Here's a much better explanation. It even has pictures.

So anyway, it turns a really simple but time consuming problem into a somewhat complicated but much faster problem. I still haven't addressed the major issue for XBox, the mid-game creation of objects, and that will be one of my next major goals. Nevertheless, on my laptop it can go up to 1024 sprites (the most I'm supported at the current time) with virtually no hits to the performance. The video posted is a good deal slower due to the screenshot software.

Also, I don't think I've posted a video since I've made a few changes to the interface. I changed the screen size to 720p, so it's a big taller and a lot longer. I've moved things around a little to account for overscan on my HDTV. Finally, I've made the lives and the score displays a good deal bigger. I think it looks pretty.

Video: Extincathon sort sweep collision detection