EPTThis Week
Hello again TeamLiquid! Welcome back to my blog about the development of The Adventures of Sam the Pirate, the 2D platformer I'm creating as the final game project for my Bachelor of Software Engineering degree. Last week I talked about the progress I'd made, and talked a bit about performance issues again. This week I'll be talking about the fixes I've made to the physics, and talking about performance again. Also finally got around to adding a couple of debug console commands, namely loading a level from file and toggling physics debugging rendering on and off.
Fixed Physics
I managed to successfully improve the movement, and fix a couple of physics bugs this week. At the start of the week, I had been a little worried about managing to fix it by the end of the week, when the last alpha milestone is due, but it was successfully done by the end of Wednesday. Having it fixed by then has allowed me to relax a little for the last couple of days, and take care of some smaller things, as I don't want to work on anything major in case I irrevocably break things before the milestone.
Most of the fixing for the physics came from adjusting what happened in collision reactions. The SDL function I'm using to detect collision between two rectangles returns another rectangle that contains the position, width, and height of the intersection. Originally I had been using this to determine how far to correct the players position, as I already knew what direction the player was, whether it be left/right, or above/below. Now, the players position is corrected by a fixed amount, with this amount being determined by the size of the tile, and the size of the players sprite.
When I first started writing the physics code, each physics actor had a single flag for whether or not they had collided with another actor. I changed this to having separate flags for vertical and horizontal collisions, and then wondered why I had ever done it with the single flag in the first place, as two made much more sense given that the physics is based around rectangles. So if the player is above/below a tile, that is a vertical collision, to the left/right is a horizontal collision. I also adjusted the collision response in such a way that on a vertical collision, when the players position is corrected, they are still colliding, but only just. Visibly they player does not look like he is colliding with anything. Both of these changes allowed me to fix the jittering, as that was being caused by the player colliding, being moved up, not colliding anymore and being forced down by gravity, colliding again, moving up again, etc. Now, as long as the player stands on a platform, they are always in state of vertically colliding and so gravity will not take effect.
There are still a few bugs, but they are relatively minor and not particularly game breaking. The first involves trying to run into a wall, you get the same kind of jittering on the player that used to happen when the player was on a platform, but more pronounced. The second involves corner tiles, depending on how you hit the corner tile, you could end up inside it, or teleported to the top of it. If you end up inside it you can still move out of it however, so a player wouldn't get stuck. These are all fixable, and will be fixed at some point.
The third bug, might end up remaining unfixed as a feature. When the player falls, say they ran off the edge of a platform, they can jump while in mid air. You can't double jump in Sam the Pirate, so while a jumping animation is being run hitting jump again will not do anything. However hitting a tile from below changes the players animation to a running animation, so it's possible to chain jumps for some distance, as long as you're hitting the bottom of a tile. This bug/feature has also made me realise I don't have a falling animation, although maybe the jump animation that plays while you're in the air is also a falling animation, in which case fixing this bug/feature will disable being able to jump while falling. Maybe I could fix it and keep this effect, as it could be interesting. You can see it in the new gameplay video below:
What do you guys think? Fix or keep jumping while falling?
Performance
I tested the game on my laptop at home again, this time I managed to get around 20 fps when in debug mode, which is a nice improvement. Still not 100% sure what I did to improve this, but it must have something to do with the changes I've made in the physics code I guess? I dunno. I did play around with some of the code in the physics, what order things were being processed etc, so that must be where it came from.
I've also possibly come up with a method of rendering all the static tiles in the level at once, rather than individually like I currently am. I haven't been too sure how to do this in SDL until now, but I think that I can probably render each static tile into an SDL surface, generate an SDL texture from this surface, and then use that texture to render into the main rendering surface. This would certainly save a lot of time on the rendering side, but would increase the initial load time for a level.
At some point soon, I should also look at doing some profiling, and finding out where the bottleneck actually is. Right now I think it is the rendering, but it could also be on the processing side, as there are quite a large number of tiles. I need to start timing things and finding out how long each takes.
What's next?
Over the next week, I'll look at changing the static tile rendering as I mentioned earlier, and work on the editor further, as it's the next important piece of the puzzle I need. The next step for the editor is being able to place other level elements, like enemies and moving platforms etc. I've also got a demonstration on Monday to the schools games faculty, but I feel pretty good about that as I think I'm mostly on track.
Keep up to date!
Be sure to follow me on Twitter, and like the Facebook page to stay up to date on future content and blog posts when they happen. If you have any questions don't hesitate to ask, either through Twitter or Facebook!
